Tuesday, 2019-09-03

*** mmethot has joined #openstack-nova00:40
*** ccamacho has quit IRC00:42
*** markvoelker has joined #openstack-nova00:46
*** markvoelker has quit IRC00:51
*** xek has quit IRC01:13
*** bbowen has joined #openstack-nova01:16
*** threestrands has joined #openstack-nova01:37
*** hongbin has joined #openstack-nova01:44
*** larainema has joined #openstack-nova02:12
openstackgerritTakashi NATSUME proposed openstack/nova stable/stein: Remove descriptions of nonexistent hacking rules  https://review.opendev.org/67969502:15
*** gbarros has quit IRC02:16
openstackgerritBrin Zhang proposed openstack/nova master: Add delete_on_termination to volume-attach API  https://review.opendev.org/67313302:18
*** Tianhao_Hu has joined #openstack-nova02:23
*** takashin has joined #openstack-nova02:26
*** Tianhao_Hu has left #openstack-nova02:35
*** mtanino has joined #openstack-nova02:36
*** gbarros has joined #openstack-nova02:39
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Use Claims to update numa-related XML on the source  https://review.opendev.org/63522902:42
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460602:42
openstackgerritArtom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration  https://review.opendev.org/64002102:42
openstackgerritArtom Lifshitz proposed openstack/nova master: DNM: extra logging  https://review.opendev.org/67968102:42
openstackgerritArtom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration  https://review.opendev.org/67259502:42
*** gbarros has quit IRC03:22
*** mkrai has joined #openstack-nova03:23
*** hongbin has quit IRC03:26
*** hongbin has joined #openstack-nova03:28
*** sapd1_x has joined #openstack-nova03:37
*** mtanino has quit IRC03:45
*** mkrai has quit IRC03:48
*** mkrai has joined #openstack-nova03:49
openstackgerritTakashi NATSUME proposed openstack/python-novaclient master: Add a check for --config-drive option on nova boot  https://review.opendev.org/65368303:51
*** takashin has left #openstack-nova03:53
*** mvkr has joined #openstack-nova04:14
*** jaosorior has quit IRC04:24
*** jaosorior has joined #openstack-nova04:25
*** hongbin has quit IRC04:29
*** hongbin has joined #openstack-nova04:49
*** hongbin has quit IRC04:49
*** Luzi has joined #openstack-nova04:59
*** udesale has joined #openstack-nova04:59
*** mkrai has quit IRC05:03
*** mkrai has joined #openstack-nova05:03
*** Garyx has quit IRC05:07
*** Garyx has joined #openstack-nova05:09
*** ratailor has joined #openstack-nova05:21
*** jaosorior has quit IRC05:22
*** sapd1_x has quit IRC05:30
*** ivve has joined #openstack-nova05:35
*** ratailor_ has joined #openstack-nova05:37
*** prometheanfire has quit IRC05:39
*** ratailor has quit IRC05:40
*** ratailor__ has joined #openstack-nova05:40
*** ratailor_ has quit IRC05:43
*** shilpasd has joined #openstack-nova06:03
*** xek has joined #openstack-nova06:11
openstackgerritLuyao Zhong proposed openstack/nova master: db: Add resources column in instance_extra table  https://review.opendev.org/67844706:21
openstackgerritLuyao Zhong proposed openstack/nova master: object: Introduce Resource and ResouceList objs  https://review.opendev.org/67844806:21
openstackgerritLuyao Zhong proposed openstack/nova master: Add resources dict into _Provider  https://review.opendev.org/67844906:21
openstackgerritLuyao Zhong proposed openstack/nova master: Retrieve the allocations early  https://review.opendev.org/67845006:21
openstackgerritLuyao Zhong proposed openstack/nova master: Claim resources in resource tracker  https://review.opendev.org/67845206:21
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver discovering PMEM namespaces  https://review.opendev.org/67845306:21
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: report VPMEM resources by provider tree  https://review.opendev.org/67845406:21
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup  https://review.opendev.org/67845506:21
openstackgerritLuyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec  https://review.opendev.org/67845606:21
openstackgerritLuyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces  https://review.opendev.org/67964006:21
openstackgerritLuyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory  https://review.opendev.org/67847006:21
*** sapd1_x has joined #openstack-nova06:22
*** mkrai has quit IRC06:31
*** sapd1_x has quit IRC06:32
*** ccamacho has joined #openstack-nova06:33
*** jaosorior has joined #openstack-nova06:39
*** mkrai has joined #openstack-nova06:39
*** aloga has joined #openstack-nova06:55
*** tridde has quit IRC07:00
*** pcaruana has joined #openstack-nova07:06
*** tesseract has joined #openstack-nova07:06
*** trident has joined #openstack-nova07:09
*** slaweq has joined #openstack-nova07:09
*** damien_r has joined #openstack-nova07:15
*** damien_r has left #openstack-nova07:17
*** damien_r has joined #openstack-nova07:18
*** threestrands has quit IRC07:18
*** rcernin has quit IRC07:23
*** kaisers has joined #openstack-nova07:24
*** luksky has joined #openstack-nova07:40
*** maciejjozefczyk has joined #openstack-nova07:41
*** priteau has joined #openstack-nova07:47
*** tkajinam has quit IRC08:02
*** ratailor has joined #openstack-nova08:05
*** ratailor__ has quit IRC08:07
*** xek has quit IRC08:10
*** xek has joined #openstack-nova08:10
*** ociuhandu has joined #openstack-nova08:14
*** jaosorior has quit IRC08:29
stephenfinalex_xu: Could you look at https://review.opendev.org/#/c/678861/ and https://review.opendev.org/#/c/678902/ ?08:32
*** ralonsoh has joined #openstack-nova08:37
*** derekh has joined #openstack-nova08:38
*** tesseract has quit IRC08:40
*** ociuhandu has quit IRC08:43
*** jaosorior has joined #openstack-nova08:59
*** rcernin has joined #openstack-nova08:59
*** avolkov has joined #openstack-nova09:06
*** kaliya has joined #openstack-nova09:08
*** kaliya has quit IRC09:09
yaawangstephenfin: Hi, cloud you review https://review.opendev.org/#/c/670298/ and https://review.opendev.org/#/c/670299/ and https://review.opendev.org/#/c/670300/ :)09:11
*** cdent has joined #openstack-nova09:17
*** slaweq has quit IRC09:22
*** slaweq has joined #openstack-nova09:23
*** brinzhang_ has joined #openstack-nova09:24
*** brinzhang_ has quit IRC09:25
*** brinzhang_ has joined #openstack-nova09:25
*** brinzhang has quit IRC09:27
*** dtantsur|afk is now known as dtantsur09:42
*** tkajinam has joined #openstack-nova09:48
*** ianw has quit IRC10:00
*** jaosorior has quit IRC10:05
*** ianw has joined #openstack-nova10:08
*** artom has joined #openstack-nova10:13
luyaostephenfin: Could you help review the rest of the patch series if you have time?  :) https://review.opendev.org/#/q/topic:bp/virtual-persistent-memory+(status:open+)10:14
*** tkajinam has quit IRC10:18
cdentis 'nova-grenade-multinode' not working the latest "gate's not happy"?10:22
cdentor is it just me10:23
*** ianw has quit IRC10:27
gibicdent: could you link the failing job?10:27
cdentgibi: https://review.opendev.org/#/c/679627/ https://zuul.opendev.org/t/openstack/build/af05b1eaef0047a6a2f2f466e93b5ac510:28
*** ianw has joined #openstack-nova10:28
*** ianw has quit IRC10:28
cdentI've seen that few different times this morning, as I'm trying to catch up. haven't dug into it yet (still trying to catch up)10:29
*** ianw has joined #openstack-nova10:29
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Simplify 'fakelibvirt.HostInfo' object  https://review.opendev.org/67886110:30
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Start checking compute usage in functional tests  https://review.opendev.org/67890210:30
openstackgerritStephen Finucane proposed openstack/nova master: objects: Rename 'fields' import to 'obj_fields'  https://review.opendev.org/67410310:30
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Fold in argument to '_update_provider_tree_for_vgpu'  https://review.opendev.org/67672910:30
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement  https://review.opendev.org/67179310:30
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available'  https://review.opendev.org/67269310:30
openstackgerritStephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs  https://review.opendev.org/67180010:30
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait  https://review.opendev.org/67557110:30
openstackgerritStephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta  https://review.opendev.org/67180110:30
openstackgerritStephen Finucane proposed openstack/nova master: Add reshaper for PCPU  https://review.opendev.org/67489510:30
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Always enable the NUMATopologyFilter  https://review.opendev.org/67974510:30
stephenfinalex_xu: Added resize tests to https://review.opendev.org/671801 as promised10:32
gibicdent: did you found the exact failure in the logs? is it https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/logs_27/679627/2/check/nova-grenade-multinode/af05b1e/logs/error.txt.gz ? or I10:32
gibior I'm on a wrong track10:32
*** ianw has quit IRC10:34
*** ianw has joined #openstack-nova10:36
cdentgibi: yeah, that's the one I saw, while skimming the genade log10:37
*** ociuhandu has joined #openstack-nova10:37
*** ianw_ has joined #openstack-nova10:41
*** ianw_ has quit IRC10:41
*** ianw_ has joined #openstack-nova10:43
*** ianw_ has quit IRC10:44
*** hoonetorg has quit IRC10:44
*** ianw has quit IRC10:44
openstackgerritAdam Spiers proposed openstack/nova master: Make _get_cpu_feature_traits() always return a dict  https://review.opendev.org/67956810:44
*** ianw has joined #openstack-nova10:44
*** xek has quit IRC10:45
*** xek has joined #openstack-nova10:45
*** bbowen has quit IRC10:46
*** ianw has quit IRC10:46
*** ianw has joined #openstack-nova10:50
*** cdent has quit IRC10:50
*** tbachman has quit IRC10:51
*** ianw has quit IRC10:52
*** ianw has joined #openstack-nova10:52
*** hoonetorg has joined #openstack-nova10:57
*** HagunKim has quit IRC10:58
*** dave-mccowan has joined #openstack-nova11:00
*** dave-mccowan has quit IRC11:06
*** luksky has quit IRC11:08
*** markvoelker has joined #openstack-nova11:09
openstackgerritsean mooney proposed openstack/nova master: multi numa nfv testing job  https://review.opendev.org/67965611:13
openstackgerritsean mooney proposed openstack/nova master: [DNM] test migration with pinning  https://review.opendev.org/67975411:13
*** markvoelker has quit IRC11:14
sean-k-mooneyartom: ^ the second patch should get the pinning only case and i also am testign we can spawn with explcit small pages via the alternitive flavor11:15
sean-k-mooneywe are not migrating with the alternive flavor but i guess i could add a third patch to do that11:16
sean-k-mooneye.g. hugepage+pinning+multi-numa+realtime11:16
sean-k-mooneyim going to test that config manually now however11:17
sean-k-mooneyartom: we might also want to invert the depens on relationship in a futre version so your change depnd on the zuul job instead of the other way aroudn11:19
*** nicolasbock has joined #openstack-nova11:19
*** xek has quit IRC11:20
artomsean-k-mooney, we're not migrating with the alt flavor? That sucks, it was kinda the whole point11:20
sean-k-mooneywe migrate with the standard flaovr11:20
sean-k-mooneywe resize to the alt flavor11:20
sean-k-mooneythe standard flavor is multi-numa-128-1-211:21
sean-k-mooneye.g. hugepages and 2 numa nodes11:21
artomOh11:21
artomhttps://review.opendev.org/#/c/679754/1/playbooks/nfv/nfv.yaml@14 is fine anyways11:21
sean-k-mooneythe alt flaovr is the one with pinning and realtime + hugepages11:21
artomIt's what I had in mind11:21
sean-k-mooneyim using the secondary pinned-128-1-2 flavor to do some other testing as a side effect of the job11:22
sean-k-mooneyits unrelated to live migration11:22
sean-k-mooneyi just want to make sure that we can trun on all the things11:22
sean-k-mooneywhich is chacked by the resize tests11:22
*** ociuhandu has quit IRC11:23
*** francoisp has quit IRC11:25
*** cdent has joined #openstack-nova11:26
gibicdent: the bug with grenade + cinder  seems to be already reported an tracked http://status.openstack.org/elastic-recheck/#184035511:28
cdentthe error message is the best ever...11:28
cdentyes, yes it is11:28
sean-k-mooneyi mean its not wrong11:30
*** udesale has quit IRC11:37
*** Garyx has quit IRC11:38
*** Garyx has joined #openstack-nova11:41
*** Garyx has quit IRC11:41
*** Garyx has joined #openstack-nova11:41
*** ociuhandu has joined #openstack-nova11:43
yonglihestephenfin:  Comments addressed.  and thanks.  https://review.opendev.org/#/c/621476/11:43
*** xek has joined #openstack-nova11:48
*** ociuhandu has quit IRC11:48
*** jaosorior has joined #openstack-nova11:51
*** udesale has joined #openstack-nova11:51
*** bbowen has joined #openstack-nova11:51
*** ricolin_ has joined #openstack-nova11:51
*** ociuhandu has joined #openstack-nova11:52
*** ricolin has quit IRC11:54
*** bbowen_ has joined #openstack-nova11:54
*** bbowen has quit IRC11:56
*** dtantsur is now known as dtantsur|brb11:57
sean-k-mooneyyaawang: the vcpu model selection series sure. im just grabing lunch but ill review it after12:01
yaawangsean-k-mooney: thk :)12:14
*** larainema has quit IRC12:15
*** markvoelker has joined #openstack-nova12:18
*** brtknr has joined #openstack-nova12:19
brtknrHi all, any users with experience using fedora-coreos on openstack?12:19
brtknrdo I need to explicitly inject ssh key to the instance?12:20
alex_xustephenfin: cool12:25
*** jistr has quit IRC12:29
*** jistr has joined #openstack-nova12:29
*** jistr has quit IRC12:30
*** ociuhandu has quit IRC12:30
*** ociuhandu has joined #openstack-nova12:30
*** ociuhandu has quit IRC12:31
*** ociuhandu_ has joined #openstack-nova12:31
*** ociuhandu has joined #openstack-nova12:32
*** weshay has joined #openstack-nova12:34
*** tbachman has joined #openstack-nova12:35
stephenfinbauzas: Could you look at https://review.opendev.org/#/c/679745 ?12:36
*** ociuhandu_ has quit IRC12:36
sean-k-mooneybrtknr: fedora core os does not have any password by defualt so if you dont inject ssh keys by selecting a key pair you wont be able to log in12:36
brtknrsean-k-mooney: I selected a keypair when I created my instance but it is not letting me in as core user12:37
openstackgerritSilvan Kaiser proposed openstack/nova stable/stein: Exec systemd-run without --user flag in Quobyte driver  https://review.opendev.org/66070512:37
*** bbowen_ has quit IRC12:37
*** bbowen has joined #openstack-nova12:40
*** jistr has joined #openstack-nova12:40
brtknrsean-k-mooney: default user is core correct?12:40
sean-k-mooneyits would be core or fedora i suspect. i dont actully use fedora core os but i knwo that the cloud images do not have a password set12:41
openstackgerritBhagyashri Shewale proposed openstack/nova master: Ignore root_gb for BFV in simple tenant usage API  https://review.opendev.org/61262612:44
*** cdent has quit IRC12:50
*** nweinber has joined #openstack-nova12:52
bauzasstephenfin: sure12:54
*** redrobot has quit IRC12:55
*** david-lyle has quit IRC13:02
*** dklyle has joined #openstack-nova13:02
*** pcaruana has quit IRC13:03
*** bhagyashris has joined #openstack-nova13:07
*** cdent has joined #openstack-nova13:15
*** ratailor has quit IRC13:15
*** luksky has joined #openstack-nova13:16
*** ociuhandu has quit IRC13:21
*** ociuhandu has joined #openstack-nova13:22
sean-k-mooneyartom:  Live Migration failure: 'NoneType' object has no attribute 'set'13:22
*** xek has quit IRC13:26
sean-k-mooneyill replicate this in the ci job but when the souce host only hase cpu enabled in the first numa node and the dest only in the second numa node it failes with that error13:27
*** tbachman has quit IRC13:27
artomsean-k-mooney, yeah, that's what I expected13:27
artomsean-k-mooney, it's fixed in a local version, need to finish unit tests and push13:27
sean-k-mooneyok im reconfriguring my vcpu_pin_set13:28
sean-k-mooneyand ill continue testing each feature independtly13:28
*** ociuhandu has quit IRC13:28
*** ociuhandu has joined #openstack-nova13:29
donnydsean-k-mooney: Any issues with NUMA I can help with today?13:29
*** mriedem has joined #openstack-nova13:29
sean-k-mooneydonnyd: nope your ci is working fine. we are now testing different edgecases13:30
*** Garyx has quit IRC13:30
sean-k-mooneydonnyd: i might add some new lables in the future e.g. multi-numa and nested-virt so that they are more expclit13:31
sean-k-mooneydonnyd: if you want to replicate the flaovr to a new on i can swap it over to use that13:31
donnydAt some point we should probably create some sensical labels13:31
sean-k-mooneyyep13:32
*** tbachman has joined #openstack-nova13:32
sean-k-mooneyif you can copy the flaovr you create and give it a new name i can add a multi-numa-ubuntu-bionic lable that uses it13:33
* cdent nominates stephenfin for nova ptl13:33
donnydOk, so you want to handle the project config end and I can do the flavor side? correct?13:33
sean-k-mooneywell i dont mind if you do the porject config stuff but im happy to do it too13:34
*** pcaruana has joined #openstack-nova13:34
stephenfincdent: no.13:34
donnydI can take care of it np13:34
sean-k-mooneycdent: he is obvioulsy the next oslo ptl :P13:34
cdentmaybe we should just dissolve things then :)13:35
artomDid efried desist or something?13:35
sean-k-mooneyartom: no he just has not renominated himself13:35
sean-k-mooneyhe has like 9 hours left13:35
sean-k-mooneyno one has nominated for nova13:35
efriedwhat what?13:36
* efried has just arrived13:36
artomWe're grown ups, we can be trusted without an adult, right?13:36
*** redrobot_ has joined #openstack-nova13:36
donnyd8cpu-8GBram-80GBdisk-multi-numa-nested-ubuntu-bionic13:36
donnyd8cpu-16GBram-80GBdisk-multi-numa-nested-ubuntu-bionic13:36
donnydso like those sean-k-mooney13:36
efriedartom: If I've learned anything from doing this, it's that a PTL is not useful for "adulting" the team.13:37
*** redrobot_ is now known as redrobot13:37
efriedRun meetings, ack release patches, organize milestoney things, other paperwork.13:37
artomefried, heh - from the outside looking in, and without wanting to sound pejorative, PTL, at least for nova, looks like a more... secretary-type? job13:38
artomPerhaps admin/organizer would be a better word13:38
efriedjust so13:38
sean-k-mooneydonnyd: they dont need to be that long be sure13:38
sean-k-mooneydonnyd: if thoes are teh flavor you created thats fine13:38
kashyapYeah, "secretary" undermines the actual (unthankful) work involved13:38
sean-k-mooneybut ill proably use the labels to hide some of the details13:38
donnydLOL - ok13:39
donnyd8c-8r-80d-multi-numa-nested-ubuntu-bionic13:39
donnydbetter?13:39
artomkashyap, totally, I'm not downplaying the importance of the work13:39
sean-k-mooneywell i dont mind what the flaovr is called.13:39
kashyapartom: Yeah, yeah.  Just that I am a bit too OCD-ish (working on it) about words :D13:39
artomJust saying that it's thankless, and not very technical (the T in PTL) from a software engineering/development POV13:39
donnyd8c-8r-80d-numa-nested-ubuntu-bionic13:39
sean-k-mooneybut the label i would prefer to jsut be muli-numa-ubuntu-bionic13:39
sean-k-mooneyand that can use the 8c-8r-80d-numa-nested-ubuntu-bionic flavor13:40
donnydwell how would you tell the difference between a 16G label and a 8GB label13:40
sean-k-mooneymulti-numa-ubuntu-bionic and muli-numa-ubuntu-bionic-extend-memory13:40
cdentdonnyd: since you are here, I thought I would just mention "thank you, your VMs are _so_ much faster than the others"13:40
* donnyd accepts gratitude 13:41
efriedartom: that13:41
*** Luzi has quit IRC13:41
sean-k-mooneydonnyd: lets submit a patch and work it out in the reivew13:41
donnydOk, sounds great13:41
efriedI should perhaps remind those present that the PTL need not be a core.13:42
artomPTL-less has happened before, what did other projects (or even Nova) do?13:42
kashyapartom: Oh, totally, on the thanklessness.13:42
artomFor instance, running the meetings pretty much anyone can do, so just set up a rotation of volunteers13:42
artomThe release stuff is more finicky13:42
sean-k-mooneyefried: you sure13:42
sean-k-mooneyefried: i thought that was a requirement13:42
donnydI am also trying to come up with a way to each project team to have a play space, so they dont have to wait on a CI job.. but could do things on the same infra13:42
artomI'd volunteer for the former (checks calendar... right, I can), not so much the latter13:42
artomAt least, not without some guidance13:43
kashyapartom: On "PTL-less", try beating  this dubious "record":13:43
efriedsean-k-mooney: not a requirement. I could go check, but I'm 98% sure.13:43
*** amrith has joined #openstack-nova13:43
kashyapartom: https://brussels-express.eu/fun-fact-belgium-owns-world-record-longest-period-without-government/13:43
artom(Actually, no, the Thursday afternoon meetings are 17:00 my time, can't make it)13:43
kashyap[quote]13:44
kashyap541 days. That’s how long it took Belgian politicians to form an official government after the federal elections of June 13, 2010. It earned Belgium a Guinness World Record for going the longest time with no government13:44
kashyap[/quote]13:44
kashyap:D13:44
efriedartom: Delegating meetings would be totally nbd13:44
*** KeithMnemonic has joined #openstack-nova13:44
efriediirc, melwitt delegated the early ones - I think gibi ran those13:45
donnydJust make all the cores like knights of the round table and just roll responsibilities bi-weekly from core to core13:45
kashyapNBD == No Big Deal (/me could only think of Network Block Device)13:45
*** brinzhang_ has quit IRC13:46
gibiefried, artom: I can chair the EU meetings if needed13:46
kashyapgibi: LOL13:46
kashyapAh, wait - I misread it13:46
*** brinzhang_ has joined #openstack-nova13:46
kashyapgibi: You meant CET/CEST meetings; /me thought you were joking about the current political fiasco :D13:46
donnydkashyap: I was also wondering how networked disks became part of the conversation13:46
*** dtantsur|brb is now known as dtantsur13:46
gibikashyap: sure, CET/CEST is more specific :)13:47
artomDudes, I dunno if that's what you're hinting at, but I'm not nominating myself for PTL. I'd feel like a total imposter.13:47
efriedartom: fake it til you make it.13:47
* efried <== imposter13:47
*** pcaruana has quit IRC13:47
sean-k-mooneyhttps://github.com/openstack/governance/blob/aa8e0ba19723269e1369e274128f801bb43e67c0/reference/charter.rst#candidates-for-ptl-seats i guess you are right13:47
cdentartom: everyone is and always will be an imposter. anyone who says otherwise is not self-aware13:47
kashyapartom: Yes, don't feel it; go for it, if you want to give it try.13:47
artomHardly13:47
kashyapdonnyd: I figured it out from a little tool called `wtf`:13:47
kashyap$> rpm -qf `which wtf`13:47
kashyapbsd-games-2.17-60.fc30.x86_6413:47
artomefried ^^13:47
kashyapdonnyd: It's a tiny (less than 1MB package), and has a acryonym DB13:48
kashyapSo, I just type:13:48
kashyap$> wtf is nbd13:48
kashyapNBD: no big deal13:48
kashyapno big deal13:48
artomI'm also scared of commitment (says the man in an LTR with 2 kids)13:48
artom(Man is a big word...)13:48
kashyapartom: What is LTR?13:48
*** gbarros has joined #openstack-nova13:48
artomlong term relationship13:49
kashyapAah, like that13:49
artomI should clarify, I'm in a relationship *with my spouse*13:49
artomNot with my kids - not in that sense, anyways13:49
efriedI was gonna say, two kids and LTR not married *is* fear of commitment.13:49
*** eharney has joined #openstack-nova13:49
artomHah, maybe13:49
sean-k-mooneyartom: do you get the same tax break for beign in a long term relation and cohabitaing as you do when married13:50
*** tbachman has quit IRC13:51
sean-k-mooneyi know in ireland you do but i dont think that is the case everywhere13:51
artomsean-k-mooney, I think so - Quebec's pretty awesome for common law spouses that way13:51
artomWe file our taxes jointly and everything13:51
sean-k-mooneyya you can do that in ireland too. although we dont have to file taxes unless we are self employed13:52
artomYeah, that stupidity we got from the US13:52
artomProps up an entire fiscal accounting industry13:52
sean-k-mooneyPAYE (pay as you earn) make it way more simple13:53
bauzasoh, it's surely not coming from the US13:53
sean-k-mooneyits not from the uk. we use the PAYE system because they did13:53
artomsean-k-mooney, oh, we have PAYE13:54
donnydsean-k-mooney: How many OS do we want to support with NUMA?13:54
donnydubuntu+centos13:54
artomIt's why there's a massive difference between my gross and net salary13:54
artomBut then there's a whole bunch of possible deductions after the fact13:54
artomRegistered retirement savings plans, daycare/school, etc etc13:54
artomSo they adjust at the end of the year13:55
artom(well, April)13:55
sean-k-mooneydonnyd: ubunut is enough13:55
donnydkk13:55
sean-k-mooneyif you add centos thats fine too13:55
bauzasartom: you wouldn't be surprised with our local tax filings then13:55
artombauzas, eh, I still think Quebec's is more complex13:55
sean-k-mooneydonnyd: we just need 1 flaovr on your end and we can create lables as we need them in project-config13:55
bauzasartom: I personnally doubt that but okay13:56
artomBut... je fais mon bourgeois, I bring all the paperwork to an account, pay her some money, and if I pay her enough money, get some more money back from the govt after13:56
bauzasyeah that's where US and Canadian folks are smarter than us13:56
sean-k-mooneyartom: ya we can file a p12 if we want to for that. but most things are handeled automatically13:57
bauzasfor us, we rather prefer to complain about how complicated our filings are13:57
artombauzas, speaking of complaining, I vividly remember a French woman in the local Ikea13:58
artomYou know that guttural sigh that you guys do? That "hhrrrrooooo"13:58
bauzasand you don't imagine how much are forgetting to ask for a specific incentive they're allowed to13:58
artomDixit woman: "hrrroooo, qu'est ce c'est mal foutu"13:58
bauzasLOL13:58
bhagyashrismriedem: Hi, I would like your insights on https://review.opendev.org/#/c/612626/13:59
bauzasartom: I assume it's a very typical French person that's becoming rare : someone not living close to an Ikea store13:59
bauzasI know those people exist, but I never met them yet13:59
*** pcaruana has joined #openstack-nova13:59
*** cfriesen has joined #openstack-nova14:00
luyaoefried: comments addressed for patch series https://review.opendev.org/#/q/topic:bp/virtual-persistent-memory+(status:open), thanks for reviewing14:00
bauzasand I personnally consider my house as an Ikea showroom14:00
bauzasstephenfin: not sure you saw my comment on https://review.opendev.org/#/c/679745/114:02
sean-k-mooneyefried: so as intersting as ^ is i take it you dont intend to run for PTL again or do you plan to serve for another term14:02
*** Garyx has joined #openstack-nova14:03
bauzasthere is still 24 hours left14:05
bauzas-ish14:05
*** amrith has quit IRC14:05
sean-k-mooneyartom: let me know when you push your local version so  i can test. im still getting the same error with the same vcpu_pin_set on each host14:05
bauzasoh dear no14:05
donnydhttps://www.irccloud.com/pastebin/nh6VDxYb/14:05
bauzasPTL Nominations Aug 27, 2019 23:45 UTC Sep 03, 2019 23:45 UTC14:05
sean-k-mooneybauzas: there are like 9 hours left14:05
donnydhttps://www.irccloud.com/pastebin/1dwaNShp/14:05
bauzaswell, we can afford a PTL designation14:05
donnydsean-k-mooney: ^^^14:06
donnydLMK if those look right to you14:06
stephenfinbauzas: I didn't, but looking at it now I don't think that's we should do that there14:06
sean-k-mooneydonnyd: yep they look fine14:06
stephenfinThat's a much bigger discussion that what that patch is trying to fix (namely, making sure it's enabled for all the libvirt functional tests)14:06
donnydproject config stuff will be up in a minute14:06
*** pcaruana has quit IRC14:07
bauzasstephenfin: I don't disagree, I'm just saying that enabling NUMATopologyFilter on *all* libvirt tests is a massive hammer with little justification14:07
sean-k-mooneydonnyd: cool ping me when you push it.14:07
bauzasstephenfin: so, honestly, that's why the question is more widely like : if we go with enabling the filter for all tests, then why not enabling it by default ?14:07
sean-k-mooneydonnyd: i can proably make the job work on the smaller memory node too or use one of each14:08
bauzasand I know this is a debatable question :)14:08
stephenfinbauzas: It's already enabled for all but two of them, are it _should_ be enabled for one of those two14:08
dansmithartom: so the multi-numa nfv thing is running live migrations with your patches yeah?14:08
efriedsean-k-mooney: I haven't decided yet.14:08
cdentdansmith for ptl!14:09
sean-k-mooneydansmith: yes im using depens on to pull in his patches14:09
stephenfinIt was enabled for all these tests in test_pci_sriov_servers.py and test_numa_servers.py. It should have been enabled for test_rt_servers.py. The only other one is test_reshape.py. I can disable it for that one, if you'd like?14:09
sean-k-mooneydansmith: if you use depends-on in the same repo it create a merge commit assumeing there is not merge conflcits and runs on that14:09
stephenfinor set it explicitly on the other three. Either one is good with me14:09
bauzasstephenfin: uh14:09
dansmithsean-k-mooney: yeah, I see that's mechanically true, but ... you guys have gone through and seen that it's working?14:09
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Use Claims to update numa-related XML on the source  https://review.opendev.org/63522914:09
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460614:09
openstackgerritArtom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration  https://review.opendev.org/64002114:09
openstackgerritArtom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration  https://review.opendev.org/67259514:09
sean-k-mooneydansmith: yes14:10
artomsean-k-mooney, ^^14:10
sean-k-mooneyi have used it in the past14:10
*** pcaruana has joined #openstack-nova14:10
artomdansmith, yeah, huge props to sean-k-mooney for getting it set up (and donnyd's hardware!)14:10
dansmithartom: does it look like it's all working?14:10
donnydhttps://review.opendev.org/67978914:10
donnydI don't think I forgot anything14:10
sean-k-mooneydansmith: hugepages are not fully working yet14:10
artomdansmith, needs to run against the latest PSes, as it found issues with hugepages14:10
dansmithartom: okay cool14:10
bauzasstephenfin: honestly, dunno what to say14:11
bauzasstephenfin: maybe just add a little more explanation in the commit msg and then I'll consider having the option set for all libvirt tests to be good enough14:11
sean-k-mooneyartom: does that patch have the fixes for hugepages. ill test it locally while we wait for ci14:12
donnydcdent: which part of FN do you think is faster. I know disk access should be in orders of magnitude faster from local NVME (in raid0)14:12
*** xek has joined #openstack-nova14:12
sean-k-mooneydamb raid0 i guess  for ci it makes sense14:13
stephenfinbauzas: Sure, lemme do that14:13
*** mkrai has quit IRC14:13
stephenfinefried: yo, any chance you could sign these off for me? https://review.opendev.org/#/c/678902 https://review.opendev.org/#/c/678861 ?14:13
donnydsean-k-mooney: yea if something fails.. it just restarts the job on another hypervisor14:13
donnydso speed is the name of the game for CI...14:13
cdentdonnyd: it does seem like it mostly related to disk speed. Where I see it the most is: a) getting log files from the swift hosted on FN, b) the placement performance are consistently faster there14:13
sean-k-mooneydonnyd: devstack is hugely io bound14:13
*** ociuhandu has quit IRC14:13
efriedstephenfin: looking14:13
stephenfinbauzas: Need any help with https://review.opendev.org/#/c/678902, btw? That's probably the trickiest patch of the series14:14
donnydI would never do that for prod things - but for CI.. go as fast as possible is where I went with it14:14
*** xek_ has joined #openstack-nova14:14
sean-k-mooneydonnyd: well ci is kind of prod.14:14
stephenfinWell, it looks tricky cos it's big. It's not really though14:14
sean-k-mooneydonnyd: but i have no issue with raid0 as long as you dont put your database on it14:14
*** mkrai has joined #openstack-nova14:14
bauzasstephenfin: not sure I understand your question ? Why should I need help on something I reviewed ?14:15
luyaodansmith:  Could you look at https://review.opendev.org/#/c/678448/9 and https://review.opendev.org/#/c/678447/https://review.opendev.org/635229. Thanks.14:15
donnydsean-k-mooney: but if I lose something its not like losing a customers long running instance I can't get back14:15
stephenfinbauzas: Damn, I meant https://review.opendev.org/#/c/671800/14:15
sean-k-mooneydonnyd: ya that is ture14:15
donnydumm.. no.. the controller is setup a little bit more robust14:15
sean-k-mooneydonnyd: the could model however is to keep data in sepereate data volumes that are attached to a stateles instance.14:15
bauzasstephenfin: oh this one is too hairy for now, I'll look at it tomorrow morning :)14:16
stephenfinIf you modify the address bar in Firefox, it doesn't change as you navigate pages until you refresh the page14:16
luyaodansmith: sorry,  they are https://review.opendev.org/#/c/678447/ and https://review.opendev.org/#/c/678448/914:16
sean-k-mooney*cloud model14:16
stephenfinSo you end up copy-pasting the same thing multiple times14:16
stephenfinbauzas: Heh, cool14:16
* bauzas doesn't forget he has to continue working on https://review.opendev.org/#/c/670112/ :(14:17
*** xek has quit IRC14:17
*** ociuhandu has joined #openstack-nova14:17
donnydI need to get HA controllers running, however I have to make a choice between # of instances to run and potential for downtime... Heat is my battle here14:17
donnydI use forced air - NO A/C14:17
stephenfinefried: I know you don't like adding config options without any users, but what about model fields? I feel I should split https://review.opendev.org/#/c/671800/ up so people can focus on the functional changes rather than the noise introduced by the additional field14:17
bauzasoh shit, dadtaxi, yeah14:17
bauzasstephenfin: I'm not worried by the size of the change in question14:18
bauzasanyway, bbiab14:18
donnydIf you think about it - I can push a button and redeploy the whole control plane.. so is two hours of downtime once a year or so worth losing 30 instances in CI14:19
donnydI made my bets on short downtime being more acceptable than losing CI resources14:19
*** mkrai has quit IRC14:19
sean-k-mooneydonnyd: well contoler can run vms too14:19
sean-k-mooneydonnyd: what are you using to deploy14:19
donnydIts custom for my infra14:20
sean-k-mooneyah ok14:20
*** tbachman has joined #openstack-nova14:20
*** udesale has quit IRC14:20
donnydI was using tripleo - but I couldn't get rabbit to act right14:20
sean-k-mooneydonnyd: ya i dont like how tripleo deplfoys rabbit14:21
*** udesale has joined #openstack-nova14:21
sean-k-mooneywell i dont like how tripleo deploys things in general14:21
donnydwell from my perspective there is a performance hit from running in containers - small but noticeable at my scale14:21
sean-k-mooneybut that is another mater14:21
donnydhttps://grafana.fortnebula.com/d/9MMqh8HWk/openstack-utilization?orgId=2&refresh=30s14:22
sean-k-mooneyreally i have nver notticed any performac ehit14:22
donnydYou can see I don't have much left on my controller for VM's14:22
sean-k-mooneyoh you mean from a ram proint of view14:22
luyaoefried: Would you like to test the patches about virtual persistent memory support? I have tested it on real hardware, and I'm preparing another OpenStack with pmems, so you can test on it if you want. I can send you how to access those servers after I set up the env.14:23
donnydYea, memory is short in the controller14:24
efriedluyao: It would be nice if *someone* could do that testing in addition to you, just to get another pair of eyes on it. But I'm not sure I have the time to do it myself.14:24
sean-k-mooneydonnyd: thats becasue heat is partly because of heat14:24
donnydonly has 96G14:24
efriedluyao: sounds like the kind of thing sean-k-mooney would enjoy :P14:24
sean-k-mooneyefried: i dont have pmem servers in my hallway14:25
efriedluyao: But I assume it requires specialized hardware, so needs to be inside Intel's firewall.14:25
efriedyeah.14:25
sean-k-mooneyso i would have to use qemu to fake pmem in a vm and then thest with nested virt14:25
donnydDue to the nature of forced air cooling, I can only do so much in the way of servers that can be turned on at a single point in time14:25
*** cdent has quit IRC14:26
luyaoefried: yes, I will check if others can access the servers14:26
sean-k-mooneyefried: i could proably set that up but not until after i test all the other stuff on my list14:26
luyaosean-k-mooney: you can use a normal file as a fake pmem14:26
sean-k-mooneyluyao: any progress on the intel ci for pmem14:26
sean-k-mooneyluyao: yes so if i spin up a vm with pme via the file backend14:26
sean-k-mooneyi could deploy devstask inside and test "hardware" pmem supprot14:27
*** jaosorior has quit IRC14:27
luyaosean-k-mooney: CI is in good process, they are testing the tempest plugin14:27
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Make scheduler filters customizable  https://review.opendev.org/67974514:27
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Start reporting PCPU inventory to placement  https://review.opendev.org/67179314:27
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: '_get_(v|p)cpu_total' to '_get_(v|p)cpu_available'  https://review.opendev.org/67269314:27
openstackgerritStephen Finucane proposed openstack/nova master: hardware: Differentiate between shared and dedicated CPUs  https://review.opendev.org/67180014:27
openstackgerritStephen Finucane proposed openstack/nova master: libvirt: Start reporting 'HW_CPU_HYPERTHREADING' trait  https://review.opendev.org/67557114:27
openstackgerritStephen Finucane proposed openstack/nova master: Add support for translating CPU policy extra specs, image meta  https://review.opendev.org/67180114:27
sean-k-mooneyare we adding file backed pmem support this cycle to nova14:27
openstackgerritStephen Finucane proposed openstack/nova master: Add reshaper for PCPU  https://review.opendev.org/67489514:27
sean-k-mooneyor jsut hardware pmem14:27
*** Sundar has joined #openstack-nova14:28
efriedluyao: I'm pretty sure there's no reasonable way to get an outsider access to the internal lab. At least not in a reasonable time frame to make it worthwhile.14:28
efriedstephenfin: those two reviews are done14:28
stephenfinta14:29
efriedstephenfin: unused model fields are okay as long as we've got the series baked enough to be pretty sure we're going to use them.14:29
efriedstephenfin: We had a bit of a miscue on vpmem and merged a field we ended up redesigning out, so had to do an ugly migration patch.14:29
artomefried, FWIW, given the amount of (very justifiable, I should say) grief I got over NUMA LM CI, I'd feel betrayed if something else got merged without seeing it run in public CI somewhere14:29
stephenfinbauzas: Have respun https://review.opendev.org/#/c/679745/14:30
efriedartom: heard and understood. Though arguably vpmem (niche specialized hardware) is different from NUMA+LM.14:31
*** rcernin has quit IRC14:32
artomefried, that's also a good point - still, releasing "we support vpmem now!" only to find out it doesn't work because the dev testing it missed a thing (no shade on luyao or you) doesn't look good :)14:33
artomAnyways, just I'm just grumpy. We all know there's a pressing lack of specialized hardware in CI14:33
artomAnd with things going more telco (at least from an RH customers POV), that's only going to get worse14:33
efriedagreed on all counts.14:34
luyaosean-k-mooney: We don't support normal file backend. So there will be  so many details. You can use a part of memory to simulate a pmem device, and specific kernel , libvirt and qemu are needed, so it may take long time to setup.14:34
sean-k-mooneyartom: if we support file backed pmem in nova we can emulate the specialised hardware in ci using file backed pemem on the node pool vms14:34
artomI was in an interesting convo with an RH consultant posted at Bell, our local massive telco14:34
artomThere was some interest on their part to become more than a pure consumer14:34
*** ociuhandu has quit IRC14:34
sean-k-mooneyluyao: ok14:35
artomThis is all very very preliminary, not even sure I should be talking about it, but I'd love it if that kinds of thing a. actually went somewhere and b. was more widespread in the telco world14:35
*** ociuhandu has joined #openstack-nova14:35
*** gbarros has quit IRC14:35
donnydsean-k-mooney: couldn't we attach like an ephemeral disk to the instance and use that as "fake pmem"14:36
sean-k-mooneydonnyd: no at least not the way you suggest14:36
donnydHow about block storage?14:36
sean-k-mooneydonnyd: pmem device are exposed as dimms to the guest kernel14:36
donnydyea I know nothing about how it all works  - /me goes to the corner to be quiet14:37
sean-k-mooneyso attaching block device ephemer or volumes wont present it to the guest correclty14:37
aspierskashyap: you around?14:37
kashyapaspiers: Yep14:37
aspierskashyap: I've split out _guest_machine_type_for_sev(), but ...14:37
sean-k-mooneydonnyd: what we can do is have wemu use a file on the host disk to emulate pmem14:37
kashyap(Although, I need to head out in an hour)14:37
sean-k-mooneydonnyd: libvirt/qemu support that14:37
aspierskashyap: now it occurs to me that this and the caller probably both belong in libvirt.utils14:37
sean-k-mooneydonnyd: nova does not currently14:37
kashyapaspiers: :-)14:37
aspiersdoes that make sense?14:38
kashyapaspiers: I was also thinking something like that, sitting on _guest_machine_type_for_secure_boot() :D14:38
aspiersall the rest of the machine type calculation is already in utils14:38
sean-k-mooneydonnyd: if we had that support we would jsut set some flave extra specls liek we did for numa sutff14:38
aspierskashyap: hell, we could even have machine_types.py14:38
kashyapaspiers: Yeah, I think it does make sense -- keeps all the machine type-related context in the same place.14:38
aspiersutils.py is a random mix of crap anyway14:38
sean-k-mooneydonnyd: pmem emultaion in qemu is really reall new however so even if openstack could do it most deploymes likely would not have a knew enough version14:39
kashyapaspiers: Haha, "utils" is so generic, it's beyond description14:39
*** ociuhandu has quit IRC14:39
kashyapaspiers: More seriously, bearing future work in mind, I _guess_ there will be more special-casing based on machine types.  So a machine_types.py doesn't sound far-fetched to me14:40
kashyap(Thoug, I _was_ serious on "utils" being generic :D)14:40
aspierskashyap: maybe I could do that after this SEV change14:40
kashyapaspiers: Yeah, don't let that bog you down, though.14:41
kashyap(It's a nice-to-have for now; and I'd rather let the "Apply SEV-specific guest config when SEV is required14:42
kashyap" through the finish line.)14:42
aspierskashyap: yeah I'm working on that patch now14:43
*** jaosorior has joined #openstack-nova14:46
*** mlavalle has joined #openstack-nova14:46
*** Garyx has quit IRC14:47
*** gbarros has joined #openstack-nova14:49
sean-k-mooneyartom: http://paste.openstack.org/show/770137/14:51
*** Garyx has joined #openstack-nova14:52
sean-k-mooneyalmost everything is working at this point14:52
sean-k-mooneywhat does not work is the case where the source and dest nodes dont have the same numa nodes available14:53
*** mkrai has joined #openstack-nova14:57
*** francoisp has joined #openstack-nova14:58
openstackgerritBalazs Gibizer proposed openstack/nova master: unit test: do not fill rp mapping for failed re-schedule  https://review.opendev.org/67965315:03
sean-k-mooneyartom: so ya if i use code with the same vcpu pin set on both host so both numa nodes are valid i can live migrate an instance with (pinning, hugepages, sriov, realtime, shared emulator threads) enable all at the same time15:05
sean-k-mooneyill repoduce the failing case in the ci for you now15:06
*** ociuhandu has joined #openstack-nova15:07
brtknri need someone who uses fedora-coreos on openstack to tell me why the --keypair argument doesnt get respected15:08
*** tbachman has quit IRC15:11
*** jaosorior has quit IRC15:11
*** mdbooth_ has joined #openstack-nova15:12
*** luksky has quit IRC15:13
openstackgerritsean mooney proposed openstack/nova master: [DNM] test non overlaping vcpu pin sets.  https://review.opendev.org/67980515:15
*** mdbooth has quit IRC15:15
artomsean-k-mooney, are you using the code I pushed earlier this morning?15:17
sean-k-mooneyyes15:17
sean-k-mooneythat fix everything except this last edgecase15:17
artomYou mean "hugepages: node 1 not found" is till happening?15:17
sean-k-mooneyyes15:17
*** mdbooth_ has quit IRC15:17
openstackgerritsean mooney proposed openstack/nova master: [DNM] test non overlaping vcpu pin sets.  https://review.opendev.org/67980515:19
sean-k-mooneyi for got to disable the other jobs in ^ so now its fixed15:19
openstackgerritMerged openstack/nova master: Add <launchSecurity> and <driver iommu='on' /> to config.py  https://review.opendev.org/63631815:21
artomI'm trying to understand what that error means15:21
openstackgerritsean mooney proposed openstack/nova master: [DNM] test migration with pinning  https://review.opendev.org/67975415:22
sean-k-mooneyartom: by the way the non WIP/DNM patches have the job in the perodic and experimental pipline so you need to use check experimenttal or somthing like that not recheck15:23
sean-k-mooneyartom: ill repoduce it locally again and dump the migration xml15:24
*** cdent has joined #openstack-nova15:25
artomsean-k-mooney, I *think* I'm getting it15:26
artomI'll poke danpb downstream to make sure15:26
sean-k-mooneyok15:27
*** pcaruana has quit IRC15:27
*** mkrai has quit IRC15:30
*** damien_r has quit IRC15:30
*** jaosorior has joined #openstack-nova15:37
*** mdbooth has joined #openstack-nova15:38
*** xek_ has quit IRC15:42
*** amrith__ has joined #openstack-nova15:42
*** ociuhandu has quit IRC15:43
*** ociuhandu has joined #openstack-nova15:44
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Use Claims to update numa-related XML on the source  https://review.opendev.org/63522915:46
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460615:46
openstackgerritArtom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration  https://review.opendev.org/64002115:46
openstackgerritArtom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration  https://review.opendev.org/67259515:46
*** amrith__ has quit IRC15:46
*** ociuhandu has quit IRC15:47
*** udesale has quit IRC15:47
*** ociuhandu has joined #openstack-nova15:47
*** amrith__ has joined #openstack-nova15:47
*** amrith__ has quit IRC15:49
efrieddustinc: Three sdk patches merging; problems on 4 & 5.15:49
*** amrith_ has joined #openstack-nova15:50
*** gbarros has quit IRC15:50
*** beekneemech is now known as bnemec15:51
*** amrith_ has quit IRC15:52
*** amrith_ has joined #openstack-nova15:52
*** amrith_ has quit IRC15:53
*** amrith_ has joined #openstack-nova15:53
*** gbarros has joined #openstack-nova15:58
*** jmlowe has quit IRC15:59
*** tbachman has joined #openstack-nova16:01
openstackgerritMerged openstack/nova master: libvirt: Simplify 'fakelibvirt.HostInfo' object  https://review.opendev.org/67886116:01
openstackgerritMerged openstack/nova master: libvirt: Start checking compute usage in functional tests  https://review.opendev.org/67890216:02
*** macz has joined #openstack-nova16:07
*** gyee has joined #openstack-nova16:12
*** amrith_ has quit IRC16:13
*** BjoernT has joined #openstack-nova16:14
*** dtantsur is now known as dtantsur|afk16:20
donnydsean-k-mooney: Ok FN should have the right stuff to run the NUMA jobs now16:24
donnydhttps://review.opendev.org/#/c/679789/16:24
*** ricolin_ has quit IRC16:25
*** jaosorior has quit IRC16:25
sean-k-mooneydonnyd: cool16:26
sean-k-mooneyill try and swap the jobs over to use those during the week16:26
mriedemgibi: i left comments on https://review.opendev.org/#/c/655113/23 but will withold voting for now16:28
mriedem*withhold16:28
mriedemhttps://review.opendev.org/#/c/679651/ and https://review.opendev.org/#/c/679653/ are pretty simple if another core can hit those - i'm going to have to rebase the cross-cell-resize series and i'd like to wait until after those are merged since they are going to merge conflict me as well16:30
*** ociuhandu_ has joined #openstack-nova16:30
sean-k-mooneydonnyd: are you ok with leaveing the current lable as it is till the end of the week and ill swap over to the new lable at the weekend16:32
donnydMakes no nevermind to me16:32
donnydI can leave it intact until asked to refactor the current jobs16:32
*** ociuhandu has quit IRC16:33
*** ociuhandu_ has quit IRC16:35
*** mdbooth has quit IRC16:44
*** jaosorior has joined #openstack-nova16:54
openstackgerritMerged openstack/nova master: objects: Rename 'fields' import to 'obj_fields'  https://review.opendev.org/67410316:56
openstackgerritMerged openstack/nova master: Nice to have test coverage for If1f465112b8e9b0304b8b5b864b985f72168d839  https://review.opendev.org/67962916:56
openstackgerritMerged openstack/nova master: Remove dead code  https://review.opendev.org/67966816:56
*** bbowen_ has joined #openstack-nova16:59
*** jmlowe has joined #openstack-nova17:00
*** derekh has quit IRC17:00
*** bbowen has quit IRC17:02
*** shilpasd has quit IRC17:02
*** ociuhandu has joined #openstack-nova17:02
*** ociuhandu has quit IRC17:07
sean-k-mooneyartom: https://46b5dc7879590352c3ef-b484a2b89d5d2c358f068133dfb2fa14.ssl.cf5.rackcdn.com/679805/2/experimental/nova-nfv-multi-numa-multinode/b040d28/testr_results.html.gz :) that is for https://review.opendev.org/#/c/679805/217:11
sean-k-mooneyartom: the other two are going to fail due to capasity issue with concurrent tests17:12
artomsean-k-mooney, yeah, I just posted on https://review.opendev.org/#/c/679656/7 summarized the CI success17:12
sean-k-mooneybut they did pass some of the tests17:12
sean-k-mooneyartom: ok cool17:13
artomdansmith, mriedem, if you guys want to take a look ^^ I'd say https://review.opendev.org/#/c/672595/ is ready17:13
artomErr, https://review.opendev.org/#/c/635669/4917:13
artomThe first patch17:13
*** jaosorior has quit IRC17:14
artomSo there's a failure in https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/logs_54/679754/2/experimental/nova-nfv-multi-numa-multinode/7956dad/testr_results.html.gz, but it's because it failed to even create the server17:15
artomThe other live migration tests passed17:16
sean-k-mooneyartom: yep that is due to tempest_concurrency 217:16
*** jaosorior has joined #openstack-nova17:16
*** jaosorior has quit IRC17:18
mriedemartom: the functional test patch is in merge conflict17:22
artommriedem, I know, working on it, it's https://review.opendev.org/67886117:23
*** pcaruana has joined #openstack-nova17:29
*** artom has quit IRC17:31
*** artom has joined #openstack-nova17:31
*** maciejjozefczyk has quit IRC17:31
*** cdent has quit IRC17:38
*** priteau has quit IRC17:43
*** brinzhang has joined #openstack-nova17:45
openstackgerritArtom Lifshitz proposed openstack/nova master: Introduce live_migration_claim()  https://review.opendev.org/63566917:47
openstackgerritArtom Lifshitz proposed openstack/nova master: New objects for NUMA live migration  https://review.opendev.org/63482717:47
openstackgerritArtom Lifshitz proposed openstack/nova master: LM: Use Claims to update numa-related XML on the source  https://review.opendev.org/63522917:47
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460617:47
openstackgerritArtom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration  https://review.opendev.org/64002117:47
openstackgerritArtom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration  https://review.opendev.org/67259517:47
artommriedem, ^^17:47
*** mdbooth has joined #openstack-nova17:48
*** brinzhang_ has quit IRC17:48
efrieddansmith: Would you please have a look at the bottom two patches of https://review.opendev.org/#/c/678447/ when you get a chance? There's still a bit of work to be done up the series, but stephenfin and I are reviewing that. Want to be able to un-hold and send it once it's baked without having to bug you in emergency mode.17:48
openstackgerritMerged openstack/nova master: Use SDK for node.list  https://review.opendev.org/65602717:50
dansmithartom: okay so it's passing everything or still failing legit on something?17:50
mriedemlanding that vpmems series in ~9 days makes me personally uncomfortable17:51
artomdansmith, passing everything as far as I can tell17:51
dansmithefried: yeah, just got off a call, so let me bio break and then I will17:51
dansmithartom: oh okay, sweet17:51
efriedthank you dansmith17:51
*** luksky has joined #openstack-nova17:52
*** markvoelker has quit IRC18:03
openstackgerritMerged openstack/nova master: Use SDK for validating instance and node  https://review.opendev.org/65602818:17
*** mvkr has quit IRC18:18
*** amrith has joined #openstack-nova18:18
*** markvoelker has joined #openstack-nova18:20
*** amrith has quit IRC18:22
*** xek has joined #openstack-nova18:23
*** markvoelker has quit IRC18:24
*** amrith has joined #openstack-nova18:25
openstackgerritMerged openstack/nova master: Use SDK for setting instance id  https://review.opendev.org/65969018:30
*** bbowen__ has joined #openstack-nova18:31
*** bbowen_ has quit IRC18:35
dansmithis FF this thursday?18:37
mriedemnext18:37
dansmithoh okay cool18:39
dansmithartom: since you rebased it's a little hard to tell...can you summarize what you're now doing to indicate that both ends are new enough to do the numa LM?18:41
artomdansmith, https://review.opendev.org/#/c/634606/70/nova/compute/manager.py@648618:42
*** markvoelker has joined #openstack-nova18:43
artomIf the destination got a migration flag from the conductor, it sets the numa_live_migration sentinel to True18:43
artomIt then passes that sentinel (either True or False) to check_can_live_migrate_source18:43
dansmithis that all?18:45
artomThe source compute manager calls the driver's check_can_live_migrate_source - if that driver sets src_supports_numa_live_migration but the numa_live_migration sentinel was False or None, src_supports_numa_live_migration gets removed from migrate_data: https://review.opendev.org/#/c/634606/70/nova/compute/manager.py@656118:45
*** mdbooth has quit IRC18:45
artomWhich would then cause the check at https://review.opendev.org/#/c/634606/70/nova/compute/manager.py@6519 back on the destination to be False18:46
dansmithokay, so we've passed a new thing in conductor->destination, proving the conductor's rpc allows it,18:46
artomExactly18:46
dansmithand then a new thing from destination->source, proving that destination's rpc allows it18:46
artomWell, that's always been the case (conductor -> destination), it was the migration object18:47
dansmithdo we ever make a call from source->destination directly?18:47
artomThe new thing is destination -> source18:47
dansmithlike on rollback?18:47
dansmithif so, I don't think you know that source's config allows the newer version in order to be able to make the newer rollback call right?18:48
* dansmith is trying to reload this all in his head post-long-weekend18:48
artomhttps://review.opendev.org/#/c/634606/70/nova/compute/manager.py@7417 is the source -> destination call on rollback18:48
artomNo, not that18:49
dansmithright, but the source will call to the destination during rollback to make the new drop claim call right?18:49
artomhttps://review.opendev.org/#/c/634606/70/nova/compute/manager.py@7406 is the drop claim call18:50
*** nweinber has quit IRC18:50
artomWhich is entirely new in 5.318:50
*** nweinber has joined #openstack-nova18:50
dansmithright, but I don't think you know whether or not the source can call the destination at 5.3 until you need to rollback and make that call right?18:51
artomIsn't that what the check on https://review.opendev.org/#/c/634606/70/nova/compute/manager.py@7405 does?18:52
artom'dst_numa_info' will not be in migrate_data if conductor, source, or dest is pinned18:52
mriedemif dst_numa_info is in migrate_data which is built up on the dest wouldn't the rollback be safe to assume it can call the drop claim method?18:52
dansmithno, because the source's config is different18:53
dansmiththat's the point of what I was asking above,18:53
dansmithyou're passing a flag from conductor->destination, and if it makes it to dest, you know conductor is allowed to send the new version18:53
dansmithand you pass a flag from dest->source during the check phase, which proves the dest can send the newer version,18:53
*** gyee has quit IRC18:53
dansmithbut if the source hasn't had its config unpinned and restarted, it will be unable to make the drop_claim call during rollback, but you've already claimed on the dest18:54
artomOhh, I see18:55
artomBefore including src_supports_numa_live_migration in migate_data, the sources needs to be sure it can speak 5.318:55
artom*source18:55
dansmithright18:56
artomI don't have ideas besides "try a new dummy 5.3 method in a try/except"18:58
artomWhich is ugly as hell18:58
artomIs there precedent for this kind of thing?18:58
dansmithno, don't do that :)18:59
dansmithmriedem: see what I mean ^ ?18:59
mriedemi feel like the most we've ever done is just checking the compute service versions, but this is more than that yeah? so not only are the source and dest upgraded, but also checking the compute rpcapi client can_send_version is True from source to dest19:00
mriedemso you want check_can_live_migrate_source to check the compute rpcapi client.can_send_version right?19:00
artommriedem, basically yeah19:00
mriedemwith a todo to drop that in U19:00
artomWhenever 6.0 happens19:00
dansmithwell,19:01
dansmithI don't want to call can_send_version from outside rpcapi19:01
artomI'm still fuzzy on the whole compatibility thing, but IIUC all of 5.x needs to be cross-compatible?19:01
dansmithbut something to that effect19:01
*** igordc has joined #openstack-nova19:02
dansmithservice_version isn't really enough here,19:02
dansmithbecause it indicates what that service can receive, but not if the config *allows* sending newer stuff19:02
artomHrmm, source calls pre_live_migration on the dest19:04
artomNo, that's after19:04
mriedemlong after this19:04
artomYeah, thinking out loud, and confused by the 'pre-' prefix19:04
mriedemhttps://docs.openstack.org/nova/latest/reference/live-migration.html19:04
artomYeah, you'd thunk it'd be on my bedroom wall by now19:05
mriedembut instead it's just posters of grimace19:05
artomNah brah, it's Ahnold19:05
*** gyee has joined #openstack-nova19:07
artomdansmith, straight up checking CONF.upgrade_level.compute?19:12
dansmithno.19:12
artomHaha19:12
dansmithbad.19:12
*** mdbooth has joined #openstack-nova19:12
mriedemself.compute_rpcapi.router.client(context).can_send_version or something like that, but abstract it19:14
mriedemdef can_drop_live_migration_claim_at_dest19:15
artomIt's not even that19:15
artomIt's def can_tell_dest_to_drop_calim19:15
*** Sundar has quit IRC19:16
mriedemyeah yeah19:17
mriedemcan_formally_please_to_be_requesting_you_rollback_a_live_migration_dest_claim_thank_you_very_much19:17
artomversion shouldn't leave rpcapi19:17
artomSo it would be something like can_send(method_name)19:18
artomdansmith ^^ acceptable-eesh?19:18
mriedemwhatever, keep it simple since it gets dropped in U19:18
dansmithwell, that only works in this specific case, because most of the time it'll be19:18
dansmithCan send? True...but...19:18
dansmithbut, I guess something like that is the quickets19:18
artomI mean, unless we want to change the whole order, and have the conductor call the source, which then calls check_can_live_migrate_destination19:20
artomSeems like overkill tho19:20
mriedemyou must be crazy19:22
sean-k-mooneyartom: why19:22
sean-k-mooneythe conductor currenlty calls check_can_live_migrate_destination direclty19:23
artomsean-k-mooney, source needs to be sure it can send RPC 5.3 before putting src_supports_numa_live_migration in migrate_data19:23
artomBecaues it calls drop_move_claim on rollback19:23
artomAnd that's new in 5.319:23
sean-k-mooneyok but the souce is called from the dest19:23
sean-k-mooneyso the test can tell the souce right19:24
mriedemsean-k-mooney: read back from this:19:24
mriedem(1:41:27 PM) dansmith: artom: since you rebased it's a little hard to tell...can you summarize what you're now doing to indicate that both ends are new enough to do the numa LM?19:24
artomYes, but the source needs to know *it* can send 5.3 - ie that it's not pinned to 5.2 for example19:24
artomHence this discussion on how do we achieve that without exposing rpcapi internals, or having a dummy method for the source to attempt to call19:24
*** ralonsoh has quit IRC19:25
sean-k-mooneymriedem: ok will do. but  im concerned that if the mechanium we use for sriov livemigration and multipel port binidngs is not enough for numa migriton all 3 feature would be incorect19:25
mriedemi have no idea how well sriov live migration handles rolling upgrades19:26
sean-k-mooneyit handesl exactly as well as multiple portbindings19:26
sean-k-mooneyas we did exeactly the same thing19:26
mriedemchecking the source and dest compute service versions yeah19:27
sean-k-mooneywe have service version checkes here https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L35-L58 and we call them here https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L317-L34419:27
*** gbarros has quit IRC19:27
sean-k-mooneymriedem: yes19:28
artomI think SRIOV was different because it would outright forbid it everything wasn't updated19:28
artomNUMA LM has to work across N/N-1 boundaries19:28
sean-k-mooneyso did the multiple port bindign yes19:28
dansmithwell, that doesn't necessarily mean it's good,19:28
dansmithbut if it didn't have the same amount of rpc involvement as this it would be different19:28
artomDunno about RPC, but actually yeah, they could all have the new service version, but still be pinned when sending19:29
sean-k-mooneythe numa migration should have the same rpc workflow19:29
*** jmlowe has quit IRC19:29
mriedemsriov live migration rolls back the claim on dest here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L749619:30
dansmithit's not the workflow19:30
mriedemwhich the source will call19:30
mriedemso it's not really the same thing artom is dealing with,19:30
mriedemsince artom is calling a new method19:30
dansmithprobably better to just read the scrollback19:30
sean-k-mooneymriedem: ah good point19:30
sean-k-mooneywe dont intoduce new calls jsut now object for sriov19:30
sean-k-mooneyand multiple port bindings19:31
mriedembrinzhang: when it comes to your microversion API changes, you should probably focus on https://review.opendev.org/#/c/673133/ since i think it's closer and less complicated19:33
sean-k-mooneyi have read half the scrollback but dumb question. since the extra complexity comes form trying to support cases other that both host are upgraded to the new version. could we just prevent that. we could add a workaoruds config options to allow people to opt in and state if you set this you need to ensure the correct rpc versions are set.19:38
sean-k-mooneyit wont just magically work but it avoid this issue entirely.19:38
* sean-k-mooney goes back to reading19:38
*** mdbooth_ has joined #openstack-nova19:39
*** amrith has quit IRC19:39
artomsean-k-mooney, no, because in a rolling upgrade we want to allow old computes to be "live-evacuated" to new ones19:40
*** gbarros has joined #openstack-nova19:40
sean-k-mooneyartom: right im saying why dont we not support that19:40
sean-k-mooneybut different question19:40
artomsean-k-mooney, because it's a pretty crucial thing, IMHO :)19:41
sean-k-mooneyif we dont call the cleanup function on rollback19:41
artomAnyways, the complexity comes from thinking about it19:41
artomWhich you need to do regardless19:41
sean-k-mooneywill the RT on the dest clean it up when the migration is rolled back19:41
artomThe code itself is clean-ish19:41
artomsean-k-mooney, yeah, next periodic run19:41
sean-k-mooneyartom: ok so if we did not call the cleanup funtion it would get cleaned up eventually19:42
artomEventually19:42
mriedemcan i get another core to approve this simple refactor https://review.opendev.org/#/c/679651/19:42
*** mdbooth has quit IRC19:42
*** aojea has joined #openstack-nova19:46
*** jmlowe has joined #openstack-nova19:47
mriedemdansmith: btw on https://review.opendev.org/#/c/633293/46 i gave a paste for what it would look like to use the existing prep_resize19:49
mriedemat this point we can defer caring about that series until U i guess19:50
artomdansmith, btw, I have a func test for RPC pinning, and it did find 1 bug. Wonder why it didn't pick up drop_move_claim() raising an RPC version error19:55
dansmithartom: I dunno, probably worth looking though19:56
*** mdbooth_ has quit IRC19:56
artomYep.19:56
dansmithmriedem: okay, sorry I didn't really mean to block everything on that, I just wanted to ponder a bit but I never got anywhere19:56
openstackgerritDustin Cowles proposed openstack/nova master: Provider Config File: Update provider tree with new custom resources  https://review.opendev.org/67652219:57
*** mdbooth has joined #openstack-nova19:59
*** pcaruana has quit IRC20:00
*** bbowen__ has quit IRC20:01
sean-k-mooneyok i think im following what ye are suggesting20:03
sean-k-mooneyi also like mriedem function name but pep8 would hate it20:03
*** nweinber has quit IRC20:11
*** slaweq has quit IRC20:17
openstackgerritArtom Lifshitz proposed openstack/nova master: NUMA live migration support  https://review.opendev.org/63460620:21
openstackgerritArtom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration  https://review.opendev.org/64002120:21
openstackgerritArtom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration  https://review.opendev.org/67259520:21
artomdansmith, mriedem, ^^ and at this point I need to done for a bit, because it's dad taxi and supper time20:21
*** amrith has joined #openstack-nova20:21
artomBut if there's anything I'll try to address it later tonight20:22
sean-k-mooneyaspiers: som of the sev functional test are asserting behavior im not sure is correct or rather is failing when in integrate my image-metadata-prefilter series20:26
sean-k-mooneyaspiers: you seam to be asserting the ablit for the sev support to be removed while the agent is running.20:26
sean-k-mooneythe commen stats that thsi coudl happen as a result of a reconfiguration or kernel downgrade which woul nomally inlvoe the agent being resarted20:27
sean-k-mooneyaspiers: it looks like you are adding the sev tratis to the existing cpu tratis function which i am now cacheing as a property20:28
sean-k-mooneyhttps://review.opendev.org/#/c/666915/15/nova/virt/libvirt/driver.py20:28
sean-k-mooneyi can fix your functional test by reseting the property when you simulate teh restart of the compute service20:29
sean-k-mooneybut i wan to confim that you dont intend this to change outside of an agent restart20:29
*** artom has quit IRC20:30
*** aojea has quit IRC20:35
*** artom has joined #openstack-nova20:36
sean-k-mooneyaspiers: im going to proceed with the assumetion i have interpred the test coorectly based on the comments and you are simulating an agent restart and just reset the chached traits. if you get a chance to review and confim that woudl be good.20:36
*** markvoelker has quit IRC20:45
*** aojea has joined #openstack-nova20:46
*** ociuhandu has joined #openstack-nova20:48
*** trident has quit IRC20:52
*** amrith has quit IRC20:56
*** trident has joined #openstack-nova21:03
*** bbowen has joined #openstack-nova21:09
efriednova FYI https://review.opendev.org/#/c/679862/21:12
dansmith+121:14
*** mdbooth_ has joined #openstack-nova21:15
*** mdbooth has quit IRC21:17
*** ociuhandu has quit IRC21:18
openstackgerritsean mooney proposed openstack/nova master: libvirt: use domain capabilities to get supported device models  https://review.opendev.org/66691521:24
openstackgerritsean mooney proposed openstack/nova master: Add transform_image_metadata request filter  https://review.opendev.org/66577521:24
*** luksky has quit IRC21:27
* mriedem deletes nova PTL candidacy patch21:27
mriedemhar har jk lol21:27
dansmith  heh21:30
*** markvoelker has joined #openstack-nova21:31
*** markvoelker has quit IRC21:35
aspierssean-k-mooney: the comments which explicitly say it's simulating agent restart are correct21:37
aspiershttps://opendev.org/openstack/nova/src/branch/master/nova/tests/functional/libvirt/test_report_cpu_traits.py#L10521:37
aspiershttps://opendev.org/openstack/nova/src/branch/master/nova/tests/functional/libvirt/test_report_cpu_traits.py#L16321:37
aspiersefried: you around? need some quick advice on https://review.opendev.org/#/c/64456521:38
efriedaspiers: ...21:40
aspiersI think https://review.opendev.org/#/c/644565/49/nova/virt/libvirt/driver.py@5089 needs to be added to utils.py instead21:40
aspierssince it turns out that blockinfo.py also needs to call it21:40
aspiersor more precisely, blockinfo.py needs to know the same machine type, and in both cases SEV needs to be taken into account21:41
efriedaspiers: You want my advice for this why?21:41
aspiersWell, just a sanity check that sounds reasonable, because that would mean passing more info into blockinfo.py21:42
aspiersAdding SEV checks to the machine type calculation requires extra info21:42
aspierse.g. the Host object to check whether SEV is supported21:42
aspiersor the sev_enabled variable if already calculated by the caller21:42
efriedAt a glance, I agree it looks weird for a method with this generic a name to need anything sev-specific.21:43
efriedbut I've repeatedly punted on this machine type stuff for a reason.21:43
aspiersThe key case here is when there is no machine type specified in the image21:43
aspiersMaybe I can hassle kashyap about it21:44
efriedyou need to default the machine type differently depending on whether SEV is enabled??21:44
aspiersYes21:44
efriedthat... doesn't sound right21:44
aspiersNormally 'pc' for x86_64, but 'q35' if SEV is enabled21:44
aspiersThat's in the spec21:44
aspiersAhh, actually the spec is out of date on this point21:45
efriedWhat sounds more likely to me is:21:45
efriedIf the machine type is not specified, we default it to X.21:45
efriedX doesn't work for SEV, so if you do that, SEV will be disabled.21:45
efriedSEV requires machine type Y, so if you want to SEV, you have to specify machine type Y as well as {other stuff to get SEV}21:45
aspiersNo, the spec is technically correct21:45
aspiersAFAICS your proposal would have a big (negative) impact on usability of SEV21:46
efriedput another way, the "is SEV enabled" check gets an additional condition for machine type. And the above is how that's reflected in the documentation.21:46
aspiersIt would make it impossible to turn SEV on or off just by choosing a different flavor21:46
aspiersYou'd have to also choose an SEV-specific image to go alongside it21:47
efriedum21:47
efriedyou don't have to do that anyway?21:47
aspiersNo21:47
aspiersYou can have one image which can be used SEV or non-SEV21:47
efriedcan you not specify machine type via flavor?21:47
aspiersI don't think so21:48
aspiershttps://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/utils.py#L54321:49
efriedsorry, but if I'm understanding this correctly, I'm afraid that has to be the right call.21:49
efriedwhat are the reasons you would specify a machine type in your image?21:49
efriedpossibly more importantly, what are the reasons you wouldn't?21:49
aspiersWell, having the choice of SEV is one reason not to21:49
aspiersWell I suppose it could be set to q35 and work non-SEV21:50
efriedand crucially, are we breaking anyone by setting a default different than the default they're expecting?21:50
aspiersThere are different levels of default21:50
aspiersThere's arch-specific defaults hardcoded into nova21:51
aspiersThere's the default per arch in nova.conf21:51
aspiersThere's even a QEMU default, which is changing to q35 at some point21:51
aspiers(hence https://bugs.launchpad.net/nova/+bug/1780138)21:52
openstackLaunchpad bug 1780138 in OpenStack Compute (nova) "Don't assume the guest machine type to be of 'pc'" [Medium,Confirmed] - Assigned to Kashyap Chamarthy (kashyapc)21:52
efriedforgive me for having swapped all of this out, but do we have some flavor/image cross-validation code for this in place?21:52
aspiersThat's what I was in the process of adding21:53
efriedSo if their image explicitly says machine type X and their flavor asks for SEV, we can punt?21:53
aspiersYes, that's what I agreed this morning with kashyap and sean-k-mooney21:53
efriedokay21:53
aspiersI'm adding an InvalidMachineType exception21:53
aspiersas per https://review.opendev.org/#/c/644565/49/nova/virt/libvirt/driver.py@510521:53
efriedand this is one where we're doing a request filtery thing (except no longer in request filter - now it's a RequestSpec loader thing?) to translate/add placement-isms21:54
aspiersNo, that's a different set of checks21:54
efriedyeah, I know, but I mean that's another part of this feature21:54
aspiersIt's part of the same series, yeah21:55
efriedand how many machine types will sev work with?21:55
aspiersjust q3521:55
efriedbeaut21:55
efriedso why don't we do this:21:56
efriedIn the request spec loader thingy, if image meta doesn't specify a machine type, shove one in there.21:56
aspiersI suppose SEV-capable images already need hw_firmware_type=uefi, so adding a requirement for another property isn't terrible21:56
aspiersYeah could do21:56
aspiersSee https://review.opendev.org/#/c/666616/41/doc/source/admin/configuration/hypervisor-kvm.rst@58521:56
efriedthat doesn't affect the image at large, does it? Just our local copy of it?21:56
aspiersI'd add documentation of the extra constraint to that paragraph21:56
aspiersNot sure I understand that question. At large?21:57
efriedI mean if you change RequestSpec.image.properties, it only affects this one request, not the real image.21:57
aspiersIt's somewhat unfortunate because it's not q35 per se which SEV requires, but rather virtio 1.0. But 'pc' only offers virtio 0.9, hence the need for q3521:57
aspiersOh wait, you're suggesting that hw_machine_type=q35 should be added *on the fly*, not to the image via glance API?21:59
aspiersI think that would be really bad, because it would override any hw_machine_type set on the real image, or any default in nova.conf21:59
aspiersThat overriding is what kashyap and sean-k-mooney were objecting to this morning, and I'm inclined to agree with them22:00
efriedokay, I'm happy to accept that that's a bad idea.22:00
efriedso back to this other thing22:00
aspiersalthough this all feels a bit bikesheddy, because I have a hard time imagining that anyone would want to insist on 'pc', given that 'q35' has already been around for 11 years22:00
efriedyou pointed out that there's already a requirement for the uefi thing in the image.22:00
aspiersYep22:00
aspiersSo we could just document an extra requirement for hw_machine_type=q3522:01
efriedis that a property they have to set (to some value) regardless?22:01
efriedor does it also default if you don't set it?22:01
aspiersIt defaults via the code in libvirt/utils.py22:01
aspierswhich looks in nova.conf first, and then falls back to the hardcoded mapping22:01
aspiershttps://opendev.org/openstack/nova/src/branch/master/nova/virt/libvirt/utils.py#L53722:01
aspiersCONF.libvirt.hw_machine_type I mean22:02
efriedo-queso, I don't see the problem with requiring them to set two image props instead of one.22:02
aspiersYeah, that sounds reasonable to me too22:02
efriedwhee22:02
aspiersIt's kind of in the same category as the UEFI requirement anyway22:02
efriedcool22:02
aspiers"virtual hardware requirements"22:02
aspiersOK that was very helpful, thanks a lot!22:03
efriedneat22:04
aspiersBTW your "I don't know enough about libvirt to be helpful" stance just lost all credibility ;-)22:04
aspiersnot that I ever believed it anyway X-D22:04
efriedhah, read the transcript again. It should be even more clear that I know jack about libvirt.22:04
sean-k-mooneyefried: you can set the default machine_type in the nova.conf too22:04
aspierssean-k-mooney: that's what I just said ;-)22:05
sean-k-mooneyefried:so you dont have to set it in the image always22:05
efriedyeah, that ^ sounds like it would be a good option for deployers wishing to enable SEV on their hosts.22:05
efriedcan you do the uefi thing in nova.conf too?22:05
sean-k-mooneyno22:05
efriedbummer22:05
sean-k-mooneyat least not that im aware of22:05
aspiersthat might be a nice feature to add22:05
sean-k-mooneyeventrually we do want to change the defualt machie type to Q35  by the way22:06
aspiersthat would actually be really easy22:06
aspierssean-k-mooney: yeah I mentioned that too22:06
sean-k-mooneyadding the bios/uefi22:06
sean-k-mooneyya it should not be hard22:06
aspierssean-k-mooney: https://bugs.launchpad.net/nova/+bug/178013822:06
openstackLaunchpad bug 1780138 in OpenStack Compute (nova) "Don't assume the guest machine type to be of 'pc'" [Medium,Confirmed] - Assigned to Kashyap Chamarthy (kashyapc)22:06
sean-k-mooneyalthough you do need to have the firmware ectra but i can see people wanting to eventurally mvoe the Q35+uefi only22:07
sean-k-mooneyya we shoudl avoid assumign pc but its also wrong to assume q35 currently22:08
sean-k-mooneywe have a function that returns the correct machine type taking into account the default + config + image22:09
sean-k-mooneyif we dont know what to use we should call that rather then guessing22:09
*** mriedem has quit IRC22:10
sean-k-mooneyaspiers: by the way https://review.opendev.org/#/c/666915/16/nova/tests/functional/libvirt/test_report_cpu_traits.py were the changes i need to make the sev code work with my series22:10
aspierssean-k-mooney: resetting the traits cache makes sense22:11
aspierssean-k-mooney: two questions about resetting domain caps cache22:11
aspiers1. how did my tests pass without that before?22:11
sean-k-mooneytechnically i think you should have always been doing self.compute.driver._host._domain_caps = None in your orginal code22:12
sean-k-mooneyaspiers: i think it should not or it was a race22:12
aspiers2. why not do it on both tests?22:12
aspiersAFAICS it can't be a race because we're only talking about a single thread here22:12
sean-k-mooneythe second test does not modify the capablities but it would be valid to do it for both22:12
openstackgerritMerged openstack/nova master: libvirt: Fold in argument to '_update_provider_tree_for_vgpu'  https://review.opendev.org/67672922:12
sean-k-mooneyaspiers: i ment between fucntional test and the order they execute in22:13
aspiersoh ok the second test doesn't look up caps because it gives up as soon as it sees the kernel parameter file missing22:13
sean-k-mooneyyep22:13
aspiersbut the compute host isn't shared between the tests surely?22:14
sean-k-mooneyit depens on how your mocking.22:14
sean-k-mooneyit should not be but i have seen wierd issue22:14
aspiersstart_compute() is called by each test22:15
aspiersand creates a fresh compute service22:15
sean-k-mooneywhen i ran it under the debugger i found you were not geting to the updated domain caps because of https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L759-L76022:16
aspiersright22:16
aspierser22:17
sean-k-mooneyi dont really know why it passed before but self.compute.driver._host._domain_caps = None seams to fix it22:17
aspiersactually I think it's https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L119122:18
aspiersif the kernel param file is missing, it won't cache any caps22:18
aspiersso when it appears later, it will call the fake getDomCaps API for the first time22:18
sean-k-mooneyno i steped throug it in the debugger22:18
aspiersthat's in the off_on case22:18
sean-k-mooneyit might be becasue of my traits code actully22:19
aspiersin the on_off case, it wouldn't even care what caps were cached when it gets to off22:19
aspiersbut technically I think it's good to reset both caches in both tests22:19
aspiersin case the order of tests ever got changed in the future22:20
sean-k-mooneyim calling this https://review.opendev.org/#/c/666915/16/nova/virt/libvirt/driver.py@683222:20
*** gbarros has quit IRC22:20
aspierssorry, I mean the order of these https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1188-L119322:20
sean-k-mooney sure ill add that22:21
sean-k-mooneyit make it symetic and really we dont want the order of those check to break this22:21
aspiersright22:21
aspiersthat static_traits looks fine to me22:21
aspiersexcept for the blank line after the def ;-)22:22
sean-k-mooneyanyway the change looks sane to you?22:22
aspiersyes22:22
aspiersI didn't review the whole thing yet, but that file does22:22
*** gbarros has joined #openstack-nova22:22
aspiersoh, according to Gerrit I did review the whole thing22:22
aspiersI forgot :)22:22
sean-k-mooneythere is no other change to that form the previous versin22:22
sean-k-mooneyyes22:22
sean-k-mooneya week or so ago22:23
aspiersk22:23
sean-k-mooneyit been wait since and the only change was resolving the merge conflcit with the sev code22:23
aspiersnot since PS922:23
aspiersI hate how this old Gerrit makes it so hard to compare patchsets after rebase22:23
aspiersthat's the #1 thing I want a new Gerrit for22:24
openstackgerritsean mooney proposed openstack/nova master: libvirt: use domain capabilities to get supported device models  https://review.opendev.org/66691522:27
openstackgerritsean mooney proposed openstack/nova master: Add transform_image_metadata request filter  https://review.opendev.org/66577522:27
*** ociuhandu has joined #openstack-nova22:30
*** BjoernT has quit IRC22:33
*** aojea has quit IRC22:34
*** ociuhandu has quit IRC22:35
*** avolkov has quit IRC22:46
*** mgoddard has quit IRC22:47
*** mgoddard has joined #openstack-nova22:47
*** tkajinam has joined #openstack-nova22:55
*** xek has quit IRC23:03
*** rcernin has joined #openstack-nova23:06
*** threestrands has joined #openstack-nova23:26
*** mlavalle has quit IRC23:30
*** macz has quit IRC23:41
*** gbarros has quit IRC23:49
*** HagunKim has joined #openstack-nova23:52

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!