Thursday, 2021-03-04

*** tosky has quit IRC00:11
*** songwenping__ has joined #openstack-nova00:32
*** LinPeiWen has joined #openstack-nova00:39
*** ociuhandu has joined #openstack-nova00:45
*** ociuhandu has quit IRC00:50
*** mlavalle has quit IRC01:14
*** adriant7 has joined #openstack-nova01:23
*** adriant has quit IRC01:25
*** adriant7 is now known as adriant01:25
*** brinzhang_ has joined #openstack-nova01:32
*** brinzhang has quit IRC01:35
*** zzzeek has quit IRC01:38
*** zzzeek has joined #openstack-nova01:39
*** rcernin has joined #openstack-nova01:53
*** Hazelesque has quit IRC02:04
*** xinranwang has joined #openstack-nova02:05
*** Hazelesque has joined #openstack-nova02:14
*** mkrai has joined #openstack-nova02:20
*** pmannidi has quit IRC02:41
openstackgerritYuehuiLei proposed openstack/nova-specs master: Add xena directory for specs  https://review.opendev.org/c/openstack/nova-specs/+/77860402:51
*** hemanth_n has joined #openstack-nova02:51
*** hemanth_n has quit IRC02:53
*** hemanth_n has joined #openstack-nova02:54
*** rcernin has quit IRC03:06
*** spatel has joined #openstack-nova03:08
openstackgerritBrin Zhang proposed openstack/nova master: Add missed accel_uuids for _poll_shelved_instances  https://review.opendev.org/c/openstack/nova/+/77844003:23
*** rcernin has joined #openstack-nova03:24
*** rcernin has quit IRC03:26
*** rcernin has joined #openstack-nova03:27
*** lpetrut has joined #openstack-nova03:27
*** tbachman has quit IRC03:29
*** tbachman has joined #openstack-nova03:30
*** vishalmanchanda has joined #openstack-nova03:34
*** psachin has joined #openstack-nova03:38
*** martinkennelly has quit IRC03:43
*** martinkennelly has joined #openstack-nova03:43
*** jamesdenton has quit IRC03:59
*** jamesdenton has joined #openstack-nova03:59
*** spatel has quit IRC04:00
*** martinkennelly has quit IRC04:18
*** whoami-rajat has joined #openstack-nova04:20
*** Underknowledge has quit IRC04:40
*** Underknowledge has joined #openstack-nova04:40
*** lpetrut has quit IRC04:47
*** ratailor has joined #openstack-nova04:49
*** xinranwang has quit IRC05:05
*** gyee has quit IRC05:20
*** yoctozepto has quit IRC06:00
*** yoctozepto has joined #openstack-nova06:02
*** zzzeek has quit IRC06:03
*** gokhani has joined #openstack-nova06:13
*** zzzeek has joined #openstack-nova06:16
*** zzzeek has quit IRC06:25
*** links has joined #openstack-nova06:27
*** zzzeek has joined #openstack-nova06:43
*** zzzeek has quit IRC06:44
*** zzzeek has joined #openstack-nova06:45
*** songwenping__ has quit IRC06:48
*** songwenping__ has joined #openstack-nova06:49
*** rcernin has quit IRC07:00
*** rcernin has joined #openstack-nova07:14
*** slaweq has joined #openstack-nova07:17
*** lpetrut has joined #openstack-nova07:22
*** takamatsu has joined #openstack-nova07:24
*** rcernin has quit IRC07:30
*** luksky has joined #openstack-nova07:36
*** ralonsoh has joined #openstack-nova07:37
openstackgerritYongli He proposed openstack/nova master: Smartnic support - cyborg drive  https://review.opendev.org/c/openstack/nova/+/77136207:41
*** dklyle has quit IRC07:41
openstackgerritYongli He proposed openstack/nova master: smartnic support  https://review.opendev.org/c/openstack/nova/+/75894407:41
*** hamalq has joined #openstack-nova07:45
*** rcernin has joined #openstack-nova07:55
*** lpetrut has quit IRC07:56
*** belmoreira has joined #openstack-nova07:59
*** rcernin has quit IRC08:00
*** hoonetorg has quit IRC08:03
*** khomesh24 has joined #openstack-nova08:06
*** rpittau|afk is now known as rpittau08:08
*** rcernin has joined #openstack-nova08:12
*** rcernin has quit IRC08:17
*** ociuhandu has joined #openstack-nova08:23
*** andrewbonney has joined #openstack-nova08:25
*** mkrai has quit IRC08:26
*** mkrai has joined #openstack-nova08:27
*** lamt_ has joined #openstack-nova08:29
*** TheJulia_ has joined #openstack-nova08:29
*** flaviof_ has joined #openstack-nova08:29
*** bbezak_ has joined #openstack-nova08:29
*** fyx_ has joined #openstack-nova08:29
*** johnsom_ has joined #openstack-nova08:30
*** cz3_ has joined #openstack-nova08:30
yonglihegibi: hope you have some bandwidth..08:31
*** raorn has joined #openstack-nova08:32
*** mnasiadka_ has joined #openstack-nova08:33
*** rpittau_ has joined #openstack-nova08:33
*** jrollen has joined #openstack-nova08:34
*** tosky has joined #openstack-nova08:36
*** cz3 has quit IRC08:39
*** cz3_ is now known as cz308:39
*** ociuhandu has quit IRC08:40
*** ociuhandu has joined #openstack-nova08:41
*** mnasiadka has quit IRC08:43
*** raorn_ has quit IRC08:43
*** lamt has quit IRC08:43
*** rpittau has quit IRC08:43
*** fyx has quit IRC08:43
*** johnsom has quit IRC08:43
*** TheJulia has quit IRC08:43
*** flaviof has quit IRC08:43
*** bbezak has quit IRC08:43
*** jroll has quit IRC08:43
*** mnasiadka_ is now known as mnasiadka08:43
*** lamt_ is now known as lamt08:43
*** TheJulia_ is now known as TheJulia08:43
*** flaviof_ is now known as flaviof08:43
*** bbezak_ is now known as bbezak08:43
*** johnsom_ is now known as johnsom08:43
*** rpittau_ is now known as rpittau08:43
*** fyx_ is now known as fyx08:43
*** khomesh24 has quit IRC08:44
*** khomesh24 has joined #openstack-nova08:45
*** ociuhandu has quit IRC08:45
*** gryf has quit IRC08:46
*** mkrai has quit IRC08:46
*** ociuhandu has joined #openstack-nova08:46
*** hamalq has quit IRC08:47
*** gryf has joined #openstack-nova08:47
*** lpetrut has joined #openstack-nova08:51
*** ociuhandu has quit IRC08:55
*** hoonetorg has joined #openstack-nova08:55
*** ociuhandu has joined #openstack-nova09:01
*** ociuhandu has quit IRC09:05
*** ociuhandu has joined #openstack-nova09:05
*** derekh has joined #openstack-nova09:07
*** lucasagomes has joined #openstack-nova09:09
*** rcernin has joined #openstack-nova09:13
*** mkrai has joined #openstack-nova09:14
*** rcernin has quit IRC09:17
bauzaslyarwood: morning09:20
* bauzas wonders whether https://040bad29f060e1f76339-88856c79572ad1783ad6e63321e57df6.ssl.cf2.rackcdn.com/761452/11/check/nova-next/fdaaa19/testr_results.html is related to https://bugs.launchpad.net/os-brick/+bug/182000709:20
openstackLaunchpad bug 1820007 in os-brick "Failed to attach encrypted volumes after detach: volume device not found at /dev/disk/by-id" [Undecided,Fix released] - Assigned to Lee Yarwood (lyarwood)09:20
bauzasI'll recheck my change, but given the bug was fixed, I wonder whether it was related09:21
*** martinkennelly has joined #openstack-nova09:22
*** ociuhandu has quit IRC09:24
*** zoharm has joined #openstack-nova09:33
lyarwoodmorning09:33
* lyarwood looks09:33
*** xek has joined #openstack-nova09:34
gibimorning folks09:34
gibistephenfin: do we need https://review.opendev.org/c/openstack/nova/+/765798 for the hypervisor api bp?09:35
stephenfinI think it's a nice-to-have rather than a necessity. gmann did say yesterday that he was going to take over that patch though,09:36
openstackgerritLee Yarwood proposed openstack/nova master: WIP: nova-next: Start testing the 'q35' machine type  https://review.opendev.org/c/openstack/nova/+/70870109:37
lyarwoodweird, just had `error: remote unpack failed: error Missing blob 08f698bbe36d414eca19d0760a5acc3a714c404e` errors trying to push that ^09:37
lyarwoodappears the git gc actually did something for a change and it's fixed after a git fetch -va09:37
*** ociuhandu has joined #openstack-nova09:37
lyarwoodbauzas: looking at that issue now sorry09:37
bauzaslyarwood: no worries at all, rechecked meanwhile09:38
bauzasjust an open question09:38
bauzasand I thought you could be interested in since you worked on the fix09:38
lyarwoodbauzas: yeah this is slightly different09:41
lyarwood43684 Mar 03 20:53:14.002343 ubuntu-focal-limestone-regionone-0023285105 nova-compute[53948]: ERROR oslo_messaging.rpc.server libvirt.libvirtError: internal error: unable to execute QEMU command 'blockdev-add': Could not open '/dev/disk/by-id/scsi-360000000000000000e00000      000010001': Operation not permitted09:41
lyarwoodwe find the device but can't attach it09:41
lyarwoodweird, we even encrypt it09:42
lyarwoodah but through /dev/sda09:42
lyarwoodI hope that's the same device09:43
gibistephenfin: ack, then I will not push hard on that policy patch09:43
bauzaslyarwood: that looks to me a race finding the device, right?09:46
lyarwoodbauzas: no we've found the device fine, /dev/disk/by-id/scsi-360000000000000000e00000000010001 is connected correctly and we even format/encrypt it with LUKSv109:50
lyarwoodbauzas: QEMU just isn't happy with the passphrase we've provided AFAICT09:50
bauzasah09:50
lyarwoodbauzas: the only odd thing is that we format/encrypt /dev/sda09:50
lyarwoodhttps://github.com/openstack/os-brick/blame/bd629a3a4105f7f3f9f35b71350ea3c66f3690e9/os_brick/encryptors/cryptsetup.py#L80-L81 and https://github.com/openstack/os-brick/blob/bd629a3a4105f7f3f9f35b71350ea3c66f3690e9/os_brick/encryptors/luks.py#L97 cause that09:51
lyarwoodbut I've never seen that be a problem before, it should be the same underlying block device09:51
lyarwoodunless theres some weirdness in the block layers and /dev/disk/by-id/scsi-360000000000000000e00000000010001 still doesn't look like it's encrypted by the time QEMU attempts to attach it09:52
*** khomesh24 has quit IRC09:55
stephenfingibi: lyarwood: bauzas: Finishing off the microversion to allow e.g. 'openstack server create --hostname $HOSTNAME ...'. Do we want to allow users to update the hostname?09:56
bauzasstephenfin: spec ?09:56
stephenfinI said in the spec that we would, but all that will change is what's stored on the metadata service unless someone re-runs e.g. cloud-init09:57
stephenfinhttps://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/configurable-instance-hostnames.html09:57
stephenfinSo I'm concerned it might be misleading09:57
bauzasI missed that one or I'm old09:57
*** ociuhandu has quit IRC09:57
stephenfinWell you are old...09:58
stephenfinbut I guess you just missed it :P09:58
bauzasit's coming from the display name issue when users were dumb enough to think that ubuntu20.04 was a valid hostname ?09:58
stephenfinyes09:58
bauzasseriously09:58
stephenfinwell, sort of09:59
* bauzas is desperated by this09:59
stephenfinwe said the idea of tying a display name and hostname together wasn't necessarily that clever09:59
bauzasstephenfin: users can change their instance hostnames without asking nova, right?09:59
bauzasit's just that nova metadata will give you one09:59
bauzasbut you can change it10:00
stephenfinof course, but they'd have to disable cloud-init (or part thereof)10:00
bauzasI'm pretty sure they don't need to do it10:00
bauzasat least in 2013, this wasn't required10:00
bauzasbut now quantum, err neutron, does exist10:01
bauzasbut OK10:02
bauzasstephenfin: let's assume the user wants to change their hostnames on the nova CLI, what's your concern ?10:03
stephenfinI'm trying to find the relevant cloud-init docs. Best I've got is https://cloudinit.readthedocs.io/en/21.1/topics/instancedata.html but that's EC2-specific10:03
stephenfinMy concern is that AFAICT cloud-init only runs once when setting up the instance10:03
stephenfinso providing a way to change the hostname in the metadata service could be misleading, since one would need a service to propagate that change to the instance and I don't know if such a service exists10:04
bauzasstephenfin: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname10:04
bauzasnow I remember10:05
bauzasman, I turned 40 but I forgot I reviewed this one10:05
bauzasand now I see my vote on the change, I remember I approved it by fatigue10:06
lyarwoodbauzas: found it, there's another request to attach a volume that also ends up with that WWN somehow10:08
bauzaslyarwood: hah10:09
bauzasgood catch, hence the conflict10:09
bauzasstephenfin: so, IIRC, you can turn off the hostname management with cloud-init and set it thru any management tool like ansible or puppet10:10
lyarwoodyeah I'm not sure if this is an os-brick or cinder bug tbh10:10
bauzasstephenfin: so, preserve_hostname be True in cloud.cfg and then you can play with /etc/hosts like you want10:11
gibistephenfin: on use case I can imagine for the changing of the hostname is that the instance is do managed by ansible, and the user changed the hostname with that and want to keep the nova view in sync with what is in the instance10:11
bauzasgibi: yeah, honestly I feel bad with my review of the spec10:12
bauzasI just feel I haven't properly reviewed it and eventually gave up with loosely approving it10:12
bauzasbecause I see some operator concerns10:12
lyarwoodah it's a cinder bug, noice.10:14
lyarwoodcaused by us running multiple c-vol backends ><10:14
*** ociuhandu has joined #openstack-nova10:14
lyarwoodfun, I bet this has burnt us for years and no one has noticed10:14
bauzaseeek, haven't seen the time flying and I need to dad taxi, shit.10:15
bauzasmy productivity would dramatically increase in 5 years once my both kids are in college.10:16
bauzas(4 years actually)10:16
stephenfingibi: That's a fair point10:20
stephenfinAight, I'll do that so10:20
* stephenfin respins10:20
*** ociuhandu has quit IRC10:22
lyarwoodbauzas: FWIW https://bugs.launchpad.net/cinder/+bug/191775010:26
openstackLaunchpad bug 1917750 in Cinder "Running parallel iSCSI/LVM c-vol backends is causing random failures in CI" [Undecided,New]10:26
*** ociuhandu has joined #openstack-nova10:30
*** ociuhandu has quit IRC10:30
*** ociuhandu has joined #openstack-nova10:30
*** zzzeek has quit IRC10:35
*** zzzeek has joined #openstack-nova10:35
*** ociuhandu has quit IRC10:36
*** artom has quit IRC10:39
*** jangutter has joined #openstack-nova10:41
*** jangutter has quit IRC10:43
*** jangutter has joined #openstack-nova10:43
*** ociuhandu has joined #openstack-nova10:43
*** jangutter_ has quit IRC10:44
*** martinkennelly has quit IRC10:51
*** k_mouza has joined #openstack-nova10:59
*** rcernin has joined #openstack-nova11:08
*** rcernin has quit IRC11:13
*** artom has joined #openstack-nova11:37
*** jangutter_ has joined #openstack-nova11:42
*** jangutter has quit IRC11:45
openstackgerritMerged openstack/nova master: libvirt: parse alias out from device config  https://review.opendev.org/c/openstack/nova/+/77238411:49
openstackgerritStephen Finucane proposed openstack/nova master: Remove references to 'inst_type'  https://review.opendev.org/c/openstack/nova/+/77854811:52
openstackgerritStephen Finucane proposed openstack/nova master: api: Rename 'parameter_types.hostname' -> 'fqdn'  https://review.opendev.org/c/openstack/nova/+/77854911:52
openstackgerritStephen Finucane proposed openstack/nova master: api: Add support for 'hostname' parameter  https://review.opendev.org/c/openstack/nova/+/77855011:52
*** mkrai has quit IRC11:52
*** legochen has quit IRC11:53
*** tkajinam has quit IRC11:56
*** psachin has quit IRC12:14
*** martinkennelly has joined #openstack-nova12:19
*** ociuhandu has quit IRC12:21
*** rcernin has joined #openstack-nova12:24
openstackgerritMerged openstack/nova master: tests: Poison os.uname  https://review.opendev.org/c/openstack/nova/+/77541512:28
*** rcernin has quit IRC12:29
*** ociuhandu has joined #openstack-nova12:37
*** ratailor has quit IRC12:38
*** ociuhandu has quit IRC12:42
*** rcernin has joined #openstack-nova12:48
*** rcernin has quit IRC12:53
*** ociuhandu has joined #openstack-nova12:53
kashyapCan anyone give this the final ACK (already has a +2), and put it through, please? -- https://review.opendev.org/c/openstack/nova/+/77424012:55
*** ociuhandu has quit IRC12:59
gibistephenfin ^^ please?13:00
stephenfinyup, will look shortly13:00
gibithnks13:01
*** ociuhandu has joined #openstack-nova13:06
openstackgerritMerged openstack/nova stable/ussuri: Fallback to same-cell resize with qos ports  https://review.opendev.org/c/openstack/nova/+/77393213:08
*** nightmare_unreal has joined #openstack-nova13:19
openstackgerritTakashi Kajinami proposed openstack/nova master: WIP: Clean up allocations left by evacuation  https://review.opendev.org/c/openstack/nova/+/77869613:28
*** jangutter has joined #openstack-nova13:34
openstackgerritTakashi Kajinami proposed openstack/nova master: WIP: Clean up allocations left by evacuation  https://review.opendev.org/c/openstack/nova/+/77869613:36
*** jangutter_ has quit IRC13:37
*** jangutter has quit IRC13:43
*** jangutter_ has joined #openstack-nova13:44
*** spatel has joined #openstack-nova13:48
*** derekh has quit IRC13:52
*** derekh has joined #openstack-nova13:52
*** hemanth_n has quit IRC13:55
*** amodi has quit IRC14:04
*** amodi has joined #openstack-nova14:06
gmannstephenfin: yeah, was busy yesterday but I am going to update that today.14:12
*** legochen has joined #openstack-nova14:16
*** jangutter has joined #openstack-nova14:16
*** jangutter_ has quit IRC14:20
*** legochen has quit IRC14:21
*** ociuhandu has quit IRC14:21
*** ociuhandu has joined #openstack-nova14:22
*** ociuhandu has quit IRC14:28
bauzasgibi: thanks for the +2 on RPC API, tbc I did put a -2 on my own change as I think we should only merge it after FF next week14:39
bauzasgibi: I guess you don't have yet a RC1 etherpad ?14:40
bauzasstephenfin: dansmith: although I marked -2 on https://review.opendev.org/c/openstack/nova/+/761452 I'd appreciate a second core review for making sure we can land it when we want14:41
dansmithI know, still pending14:41
openstackgerritLee Yarwood proposed openstack/nova master: nova-next: Start testing the q35 machine type  https://review.opendev.org/c/openstack/nova/+/70870114:42
*** rcernin has joined #openstack-nova14:49
gibibauzas: sure, the RPC bump need to be on hold until FF14:53
gibibauzas: I have the RC etherpad ready :) https://etherpad.opendev.org/p/nova-wallaby-rc-potential14:53
bauzashuzzah, will add it then14:53
*** ociuhandu has joined #openstack-nova14:54
gibithanks14:54
kashyaplyarwood: Ah, thanks for adding to CirrOS itself: https://github.com/cirros-dev/cirros/pull/6514:54
*** rcernin has quit IRC14:54
bauzasgibi: oh, already there, nice (or grenoble)14:54
* bauzas does a local pun14:54
gibi:)14:55
*** ociuhandu has quit IRC14:56
*** ociuhandu has joined #openstack-nova14:57
*** khomesh24 has joined #openstack-nova14:58
*** jmlowe has quit IRC15:06
*** jmlowe has joined #openstack-nova15:08
*** ociuhandu has quit IRC15:13
*** ociuhandu has joined #openstack-nova15:14
*** ociuhandu has quit IRC15:19
*** ociuhandu has joined #openstack-nova15:29
*** __ministry1 has joined #openstack-nova15:29
openstackgerritStephen Finucane proposed openstack/nova master: tests: Remove useless mocks  https://review.opendev.org/c/openstack/nova/+/77873015:33
openstackgerritStephen Finucane proposed openstack/nova master: tests: Remove duplicate policy tests  https://review.opendev.org/c/openstack/nova/+/77873115:33
openstackgerritStephen Finucane proposed openstack/nova master: tests: Speed up 'servers' API tests  https://review.opendev.org/c/openstack/nova/+/77873215:33
*** lpetrut has quit IRC15:36
*** __ministry1 has quit IRC15:37
lyarwoodstephenfin: https://review.opendev.org/c/openstack/nova/+/673790 - any plans to respond to this -1 btw, I'm ready to go through the rest of the series once we've sorted this out.15:41
stephenfinlyarwood: yup, I was going to do a separate FUP15:42
stephenfinto avoid rebasing the whole series15:42
lyarwoodstephenfin: yup fair, I'll let you update the change before I continue on in the series15:43
lyarwoodand by that I mean comment, not rebase or anything15:43
stephenfinkashyap: comments left on https://review.opendev.org/c/openstack/nova/+/774240. If you can respin I'll re-review today15:45
*** claudiub has joined #openstack-nova15:46
kashyapstephenfin: Thanks for the review.  Let me look ...15:47
kashyapstephenfin: That mock of _register_instance_machine_type is required after Lee's change15:49
stephenfinbut you didn't touch that function?15:49
kashyapstephenfin: Especially as the test is calling init_host() directly15:49
stephenfinkashyap: Ah, whoops15:50
lyarwoodthe diff has moved it around15:50
stephenfinyup15:50
stephenfinapologies15:50
kashyapNo problem15:50
*** gyee has joined #openstack-nova15:52
*** spatel has quit IRC15:55
kashyapstephenfin: Is it palatable to you if I don't address the style nit here: https://review.opendev.org/c/openstack/nova/+/774240/11/nova/tests/unit/virt/libvirt/test_driver.py#157915:57
gibinova meeting starts in 2 minutes in #openstack-meeting-315:57
kashyapstephenfin: I'm addressing the rest of all your comments15:57
stephenfinsure15:59
stephenfintbc though, I'm only suggesting doing that for the new functions, not the old ones of course16:00
openstackgerritStephen Finucane proposed openstack/nova master: trivial: Clarify purpose of 'Host.supports_*' properties  https://review.opendev.org/c/openstack/nova/+/77873916:00
stephenfinlyarwood: ^16:00
stephenfinLemme know if that's not clear16:00
*** dklyle has joined #openstack-nova16:00
lyarwoodstephenfin: thanks16:01
kashyapstephenfin: Ah, okay; yes, just for the newly-added ones might as well address that16:06
openstackgerritClaudiu Belu proposed openstack/nova master: POC: tests: Adds test checking unbalanced NUMA node association  https://review.opendev.org/c/openstack/nova/+/77874016:10
*** zoharm has quit IRC16:12
lyarwooddansmith: sorry joined the meeting late, re the cinder failures, anything like https://bugs.launchpad.net/cinder/+bug/1917750 ?16:13
openstackLaunchpad bug 1917750 in Cinder "Running parallel iSCSI/LVM c-vol backends is causing random failures in CI" [Undecided,New]16:13
dansmithlyarwood: depends on how that manifests, but can't say I've seen that specifically16:14
dansmiththe two major symptoms I see are a complaint about state conflict, and "unable to delete volume"16:14
lyarwoodright sorry, that basically leads to two instances looking at the same volume even when it isn't multiattached16:14
dansmithack16:15
dansmith(and also.. ouch)16:15
lyarwoodthat could be related if we are trying to detach the volume in Nova but it's still attached to another instance16:15
dansmithwell, I haven't seen detach fails, so much as failure to delete, but I guess it's possible it's just how we report it16:16
lyarwoodoh if it's the actual delete on the cinder side then it's likely something else16:16
lyarwoodwe've already nuked the connections to the computes at that point16:17
dansmithyeah I think it's  like "delete volume, poll until it's gone...timeout"16:17
*** vishalmanchanda has quit IRC16:17
lyarwoodkk, melwitt had a bug for lvcreate being slow, assuming it's waiting on lvdelete it could be related16:17
lyarwoodlvchange*16:17
lyarwoodthere's no lvdelete16:17
dansmithack16:18
*** mlavalle has joined #openstack-nova16:28
kashyapstephenfin: Isn't your "while" spurious, here,  on line-8?  (The "it.  If niether..." bit makes sense, though.) -- https://review.opendev.org/c/openstack/nova/+/774240/11/releasenotes/notes/allow-disabling-cpu-flags-cc861a3bdfffadf8.yaml#816:30
kashyapIt looks like so.  I'll disregard it.16:31
*** links has quit IRC16:33
stephenfinkashyap: I think it's relevant16:33
stephenfinThis is possible via a '+' / '-' notation, where if you specify a CPU flag prefixed with a '+' sign (without quotes), it will be enabled for the guest, a prefix of '-' will disable it16:33
stephenfinThis is possible via a '+' / '-' notation, where if you specify a CPU flag prefixed with a '+' sign (without quotes) then it will be enabled for the guest while a prefix of '-' will disable it.16:34
stephenfinThe latter reads better to me16:34
kashyapstephenfin: Ah, there; yes.  But you're missing a comma after "guest" :)16:35
kashyapEither that, or I've gone comma-wild (I was accused of this once, in a friendly way, on qemu-devel list before :D)16:35
stephenfinCorrect, missing comma16:36
stephenfinsince it's a comparison16:36
stephenfin*Correct. Missing comma ;)16:36
*** lpetrut has joined #openstack-nova16:36
kashyapstephenfin: I.e. the missing comma in the second version is correct?  Yeah?16:37
stephenfinyeah, add the comma16:37
kashyapAh, nod.16:37
lyarwoodstephenfin: https://review.opendev.org/c/openstack/nova/+/769548 - just a reminder if you didn't have this on your list, that would then move the series into the gate.16:38
claudiubHello! I've noticed that in the NUMA-related docs (https://docs.openstack.org/nova/latest/admin/cpu-topologies.html#customizing-instance-numa-placement-policies) it says that "The NUMA node(s) used are normally chosen at random",16:38
lyarwoodoh and https://review.opendev.org/c/openstack/nova/+/778462/2 that gibi++ added in16:38
claudiubbut numa_fit_instance_to_host (https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L2235) says that it will return a new InstanceNUMATopology with its cell ids set to host cell ids of the first successful permutation, or None.16:38
*** lpetrut_ has joined #openstack-nova16:38
*** lpetrut_ has quit IRC16:38
claudiubso, there's a mismatch there. From what I've seen, all the instances end up in the 1st NUMA node.16:39
stephenfinlyarwood: was in the middle of reviewing. +2 on the whole series now16:39
claudiubthat could be problematic. Basically, I can have nodes with 50% consumed resources, but 1 NUMA node completely empty.16:39
stephenfinclaudiub: Yup, that's a known bug :(16:40
claudiubso, I'm wondering which should be corrected: The docs, or the code.16:40
stephenfinI think sean-k-mooney filed a bug for same16:40
stephenfinclaudiub: the code16:40
claudiubah, gotcha. :)16:40
claudiubWondering what the backport potential for this would be, if a fix would be added. :)16:41
stephenfinwe should shuffle the nodes or sort by least-allocated node16:41
stephenfindepends on the implementation of course but definitely backportable IMO16:41
stephenfin*should definitely be16:41
claudiubis someone working on this? I could look into it if no one is16:42
*** lpetrut has quit IRC16:42
stephenfinNot right now. If you could look, I'd be happy to review16:42
openstackgerritArtom Lifshitz proposed openstack/nova master: pci: track host NUMA topology in stats  https://review.opendev.org/c/openstack/nova/+/77414916:42
openstackgerritArtom Lifshitz proposed openstack/nova master: pci: implement the 'socket' NUMA affinity policy  https://review.opendev.org/c/openstack/nova/+/77277916:42
openstackgerritArtom Lifshitz proposed openstack/nova master: pci: always pass node_id to manager  https://review.opendev.org/c/openstack/nova/+/77874716:43
lyarwoodstephenfin: awesome thanks for that16:43
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow disabling CPU flags via `cpu_model_extra_flags`  https://review.opendev.org/c/openstack/nova/+/77424016:43
claudiubgreat, will let you know how it goes. :)16:43
kashyapstephenfin: gibi (lost your +2, if you'd like to add the stamp again)  --^ Addressed the doc nits from Stephen16:44
gibisure16:44
* kashyap hopes he didn't mess up anything else16:44
bauzassean-k-mooney: could you please confirm that the os-vif SHA1 for the next release looks good to you ?16:45
bauzassean-k-mooney: https://review.opendev.org/c/openstack/releases/+/777955/1/deliverables/wallaby/os-vif.yaml16:45
bauzasfrom what I see, yup16:45
sean-k-mooneylooking16:46
sean-k-mooneyyep its the current head of master and the main delta is just fixing the lower-constratists-job and a deprecation wraning16:49
sean-k-mooneynormlaly i would say that it could be a bugfix release but we always do feature version bump for the end of a cycle16:49
sean-k-mooneyso this looks correct16:49
*** rcernin has joined #openstack-nova16:50
claudiubAlso, speaking of NUMA, I was wondering if you know if an instance placed in a single NUMA node can be live-migrated to another node in a different NUMA node, or it has to be in the same NUMA node? Trying to gauge the severity of that bug that places all the instances in the same NUMA node.16:50
sean-k-mooneyclaudiub: that can be done but only from train16:51
sean-k-mooneyclaudiub: artom  added numa live migration in the train release whre we can regenerate teh xml as part of the migration16:51
claudiublive-migrating instances with numa topologies, right? I've seen that bit in code16:51
artomclaudiub, except the user can't specify which NUMA node - which I think is what you're getting at16:52
sean-k-mooneywhat bug are you triaging?16:52
artomNova just finds a "free" one16:52
claudiubartom: that's perfect then. :)16:52
sean-k-mooneyclaudiub: please do not file a new bug for numa blanacing16:53
claudiubsean-k-mooney: I was hitting an issue where all the created instances were created on the same numa node, so I was asking about that. :)16:53
sean-k-mooneyclaudiub: yep that is by design16:53
sean-k-mooneyits somethign we could chagne but when i brough tit up i was told it was a featur not a bug16:54
sean-k-mooneywe talked about in the last ptg and when numa was first being added many years ago16:54
*** rcernin has quit IRC16:55
claudiubwell, one thing's for certain: the docs and the code don't match. :) The docs say the chosen NUMA node is random.16:55
sean-k-mooneyfrom a user perspecitve it is16:55
claudiubWondering if we could at least have a config option to randomize the selected numa node (ofc, if it can be randomized. not talking about PCI devices)16:55
sean-k-mooneyits not actully random form an api point of view it underfied16:55
sean-k-mooneyi have a much better solution for this just trying to fine the bug i already had filed16:56
sean-k-mooneyhttps://bugs.launchpad.net/nova/+bug/189312116:56
openstackLaunchpad bug 1893121 in OpenStack Compute (nova) "nova does not balance vm across numa node or prefer numa node with pci device when one is requested" [Undecided,Confirmed] - Assigned to sean mooney (sean-k-mooney)16:56
sean-k-mooneyclaudiub: this is what determins the order16:57
sean-k-mooneyhttps://github.com/openstack/nova/blob/20459e3e88cb8382d450c7fdb042e2016d5560c5/nova/virt/hardware.py#L2268-L227716:57
sean-k-mooneyas an end user you are not allowed to rely on the detail of that implemenation16:57
sean-k-mooneywhat i am proposing and had plannd on woking on is doing muliple sorts16:58
sean-k-mooneyso that we will blance vm plamcne based on avaiable resouces on a host16:58
sean-k-mooneyclaudiub: line 693 is the ptg dicussion form the last ptg on the topic https://etherpad.opendev.org/p/nova-wallaby-ptg16:59
sean-k-mooneythis is one of the topic i need to bring up internally but i would like to adress this next cycle if i can make time but if you have time to work on it then that woudl be good too.17:00
sean-k-mooneynuma blancing is the non invaisive way to optimise better then we do today.17:01
sean-k-mooneylong term we should be doing this more abstractly. e.g. computeing a cost metic for any give plamcnet based on a number of factors and then minimsiing that.17:02
sean-k-mooneykind of like how the wehers work but placment complictates that.17:02
sean-k-mooneyclaudiub: the workaround for now is to follow the advice we always gave. try to create flavors that aproximate the host toplogy. e.g. if you hosts all have 2 numa nodes then default to createign flavors with hw:numa_nodes=217:03
openstackgerritBalazs Gibizer proposed openstack/nova master: Replace blind retry with libvirt event waiting in detach  https://review.opendev.org/c/openstack/nova/+/77024617:04
*** lucasagomes has quit IRC17:05
claudiubsean-k-mooney: Hmm, I see. but correct me if I'm wrong, but in that code snippet, the host cells are not randomized or sorted in any other way if there are no pci_requests and no pci_stats. It's the same host_cells athat are set in host_topology.cells (not sure if the order ever changes here). I could spend some time on it, will read the PTG notes as well.17:08
*** belmoreira has quit IRC17:09
sean-k-mooneyif pci devices are not requested we sort the numa nodes to prefer the onces without numa nodes17:09
claudiubBut in any case, setting hw_numa_nodes=2 doesn't help in our scenario, especially since we also have nodes with just 1 NUMA node. :) Additionally, setting the instances on 2 numa nodes could affect the guest performance as well.17:09
claudiubsean-k-mooney: indeed, agreed there.17:10
sean-k-mooneyotherwise  itertools.permutations iterates over them in a determisict maner17:10
sean-k-mooneywhich for singel numa nodes instace is acending order form numa node 017:10
sean-k-mooneythen we bail out if it fits and dont try any other nodes17:11
sean-k-mooneyso that packs numa017:11
claudiubyep17:11
sean-k-mooneythis is has alwasy been the case since numa was firsts added17:11
sean-k-mooneythe specific behavior is implemation defiend and is not garenteed by the api17:12
artomstephenfin, D: how did you not jump on https://review.opendev.org/c/openstack/nova/+/774240/12/nova/virt/libvirt/driver.py#697 with a -2?17:12
artom;)17:12
*** khomesh24 has quit IRC17:12
sean-k-mooneyso it can be modified but the current beahivor optimises for being able to spawn large vms17:12
sean-k-mooneyif we balance the vms between numa ndoes it will improve performance in genreal but pessimise spawning large vms17:12
sean-k-mooneyso there is a tradeoff between packeing and spreading/blancing17:13
claudiubi agree there, and I am aware of that. :)17:13
sean-k-mooneyyep so this is why we said this cant be change in a bug and need a spec17:13
sean-k-mooneywhich means upstream at least not backportable17:13
sean-k-mooneydownstream we likely would backport it but not chagne the behavior by default17:14
stephenfinartom: My yoga guy said I needed to be more chill about these things17:14
stephenfinI'll fire him in the morning17:14
sean-k-mooneyupstream if accpetd i would like to change the default but in the cycle after its added17:14
*** ociuhandu_ has joined #openstack-nova17:14
stephenfin<sean-k-mooney> so it can be modified but the current beahivor optimises for being able to spawn large vms17:14
stephenfinare you talking about unpinned instances?17:14
sean-k-mooneystephenfin: no all numa instances17:15
sean-k-mooneystephenfin: by packing numa nodes before moving on17:15
sean-k-mooneywe keep the rest free17:15
sean-k-mooneyso vms that need all teh ram or cpus on a numa node can boot17:15
stephenfinah, yeah I don't think that's a good argument for the unpinned case17:15
sean-k-mooneyif we spread then that makes large vms less likely to fit17:15
stephenfinspreading makes sense there IMO17:15
sean-k-mooneyunpinned float so ya not an issue17:15
stephenfinyup17:16
claudiubin our scenario, large vms is not a concern, since we have pretty large hosts, so in our case, it would work better for a spread-out approach. But indeed, not everyone is the same. Could this be a config option then?17:16
stephenfinif you don't spread, you'll basically never end up on node 1, as claudiub is seeing17:16
stephenfinor node N > 017:16
sean-k-mooneyclaudiub: yep it could be a config option or it coudl be done via aggreate metadata17:16
stephenfinI don't think that's needed or unpinned17:17
stephenfin*for17:17
*** ociuhandu has quit IRC17:17
sean-k-mooneystephenfin: well this is needed for all numa guests pinned or unpinned17:17
claudiubhmm, aggregate metadata also sounds interesting. it could have best of both worlds17:17
sean-k-mooneybut its not needed for non numa instnaces17:17
sean-k-mooneyclaudiub:  my concern is if we codify this as a feature we need to supprot it with placment in the future17:17
stephenfinpinned guests can already use NUMA nodes > 017:17
sean-k-mooneyclaudiub: we can do that but that means we need to do the same behavior by sorting the allocation candiates17:18
sean-k-mooneyyep they can but that not really the issue17:18
*** ociuhandu_ has quit IRC17:18
claudiubhm, I am a bit outside the loop with the placement api, but doesn't the NUMAPlacementFilter also use the numa_fit_instance_to_host function?17:19
sean-k-mooneyclaudiub: yes currently we are not usign placmnet for numa and wont be for a few release17:19
claudiubor whatever the fitler name was. :)17:19
claudiuboh ok, gotcha.17:19
stephenfincan we back up and say why any of this needs a aggregate metadata filter17:19
stephenfinwe're not trying to change stack/spread behavior for pinned instances, right?17:19
sean-k-mooneyclaudiub: the concern is the more featers the filter has the more we need to port to the plamcent version17:20
sean-k-mooneystephenfin: no new aggreate filter17:20
stephenfinonly unpinned NUMA instances, because those are all landing on NUMA node 017:20
stephenfinsorry, an aggregate metadata key17:20
sean-k-mooneystephenfin: nope hugepages and all other numa instnace land there too17:20
stephenfin<sean-k-mooney> claudiub: yep it could be a config option or it coudl be done via aggreate metadata17:20
stephenfin^ that17:20
stephenfina page with hugepages and no pinning *is* an unpinned NUMA instance17:21
sean-k-mooneystephenfin: if we do it per host it has to be accounted for on live migration and we have the same proble we had wtih PCPUs and hyperthreading17:21
stephenfinif we do what per hose?17:21
stephenfin*host17:21
claudiubHm, I'm wondering why the current implementation is: "Hey HostState, I'm a request spec, pls fit me", rather than: "Hey HostState, Placement told me to sit in your X numa node."17:21
sean-k-mooneystephenfin: allow packing vs spreading17:21
stephenfinI'm not suggesting making it configurable at all17:22
sean-k-mooneywell people objected ot hardcoding spreading17:22
stephenfinthe current packing behavior is a bug17:22
stephenfindid they? Link?17:22
stephenfinclaudiub: Yes, it's the former17:22
sean-k-mooneyi filed https://bugs.launchpad.net/nova/+bug/1893121 and was told its a feature not a bug17:23
openstackLaunchpad bug 1893121 in OpenStack Compute (nova) "nova does not balance vm across numa node or prefer numa node with pci device when one is requested" [Undecided,Confirmed] - Assigned to sean mooney (sean-k-mooney)17:23
sean-k-mooneystephenfin: then i brought it up in the ptg as a bug and was told it need a spec https://etherpad.opendev.org/p/nova-wallaby-ptg17:23
stephenfinclaudiub: placement gives us X VCPU inventory, but it has nothing to do with what actual host CPUs are used17:23
sean-k-mooneystephenfin: line 71017:23
stephenfinclaudiub: Put another way, placement says you may have 4 unpinned/pinned CPUs, and nova-compute says you may map to these specific hosts core(s). Placement doesn't track the specifics17:24
sean-k-mooneystephenfin: if we alwasys want to spread thats simple. and thats what i wanted to do orginally17:24
stephenfinsean-k-mooney: Yeah, that's never an RFE. I'm not sure how we came to that conclusion17:25
stephenfinPacking all your instances onto one host NUMA node and leaving the others empty regardless of the number of instances created is a bug every day of the week :)17:26
*** jangutter_ has joined #openstack-nova17:26
sean-k-mooneyif we are ok treating this as a bug the i will try to work on it next cycle and backport it17:26
stephenfinwell it sound like claudiub might have time to work on it also17:26
stephenfinwhich would be great :)17:26
gibistephenfin: what will happen when we model NUMA nodes in placement? I guess at that point placement will track how many PCPU belongs to which NUMA node.17:26
sean-k-mooneygibi: we will need to sort the allocation candiates17:27
stephenfingibi: s/when/if/ ;)17:27
sean-k-mooneyto have the same behviaor17:27
sean-k-mooneywe should get mutiple allcoation candiate per host17:27
stephenfinyeah, what sean-k-mooney said17:27
gibiOK. I'm out of brain power but I feel that if we discussed it once and came to a conclusion that it is a feature then there might be complications17:27
*** rpittau is now known as rpittau|afk17:27
sean-k-mooneygibi: right now since the behavior is currently undefiend we can pretend the exsiting behavior is not a thing17:28
stephenfinI say we work on the patch and then review17:28
stephenfincomplications should be evident by then17:28
sean-k-mooneygibi: the concern was that it could cause large vms that previousl would have boot to fail17:29
stephenfinand we can adjust accordingly17:29
*** jangutter has quit IRC17:29
gibiso this will be somehow configurable or user requestable to pack or spread?17:29
sean-k-mooneythat was the reason we said i should write a spec17:29
stephenfinsean-k-mooney: that seems like an acceptable compromise given the alternative17:29
sean-k-mooneyto debate that point17:29
sean-k-mooneystephenfin: it not that we wont use the other numa nodes ever17:30
sean-k-mooneywe will if the vm does nto fit on the first node17:30
claudiubbtw, I had nodes with ~400 instances on a single NUMA node, and the other numa node was empty. :)17:30
stephenfinsean-k-mooney: I don't think that will ever happen17:31
stephenfinYeah, what claudiub says17:31
sean-k-mooneystephenfin: it does17:31
stephenfinI'm almost certain we don't apply overcommit ratios correctly on a per-node basis17:31
sean-k-mooneyclaudiub: you likely have misconfigured your flavors17:31
stephenfinAs above, I say we get a fix and functional test for this and then debate it there17:31
sean-k-mooneystephenfin: we dont but i think claudiub is missing hw:mem_page_size17:32
openstackgerritBalazs Gibizer proposed openstack/nova master: Replace blind retry with libvirt event waiting in detach  https://review.opendev.org/c/openstack/nova/+/77024617:32
gibiI rest my case (at least for today)17:32
sean-k-mooneystephenfin: we said we should start default that to hw:mem_page_size=any for all numa instnaces17:32
gibisee you tomorrow17:32
claudiubhm, I only had the "hw:numa_nodes=1" extra_spec17:32
lyarwoodgibi: awesome, I'll queue that up in the morning :)17:32
stephenfinsean-k-mooney: that's a legit request17:32
lyarwoodgibi: \o17:32
sean-k-mooneyclaudiub: yep that incorect17:32
gibilyarwood: note that it is still not all your comment fixed, but I will add one more separate patch to fix thoes17:33
sean-k-mooneyclaudiub: you have enbaled numa node but not enable either numa aware cpu tracking or memory tracking17:33
* gibi leaves17:33
sean-k-mooneyif you set hw:numa_nodes=1 and dont set hw:mem_page_size to any valid value its not correct17:34
stephenfinthat's a bit strong. It's fine if you don't have hugepages on the host17:34
stephenfinor other things taking memory that you haven't accounted for17:34
sean-k-mooneystephenfin: i did not say use hugepages17:34
stephenfinsetting hw:mem_page_size disables memory overcommit17:35
sean-k-mooneystephenfin: i said set hw:mem_page_size to any value17:35
sean-k-mooneystephenfin: yep you cant use over commit with numa properly17:35
*** bbowen_ has quit IRC17:35
sean-k-mooneystephenfin: claudiub  look at https://etherpad.opendev.org/p/nova-wallaby-ptg line 71217:36
sean-k-mooneyi explained why this is needed17:36
stephenfinthat's a veritable hammer of a solution17:37
stephenfinwe could do proper tracking without that17:37
claudiubouch. didn't know about that17:37
sean-k-mooneystephenfin: we cant we tried many times17:37
sean-k-mooneystephenfin: the only time oversubsript can be used with numa guest is if  hw:numa_nodes = the number of numa nodes on the host17:38
stephenfinI appreciate it's complicated because we need to marry the non-NUMA model with the NUMA model17:38
stephenfinthat's just because we don't do proper oversubscription modelling on a per-node basis17:39
sean-k-mooneywe do proper page tracking on a per numa basis17:39
sean-k-mooneyand that woudl be used if we did hw:mem_page_size=small17:39
sean-k-mooneythat could support oversubsripion if we wanted17:39
claudiubfrom what I've seen in the docs, it wasn't specifying that huge pages extra_spec is mandatory, so that could be easily missed, imo.17:39
stephenfinright, and we could use that with overcommit ratio for non-pinned NUMA instances17:39
sean-k-mooneybut we need to turn that on which si what hw:mem_page_size does17:40
stephenfinthat's the gap17:40
stephenfinthat we don't consider that information for instances without explicit page size configuration17:40
sean-k-mooneyyep but we were told we can make all guest numa guests17:40
sean-k-mooneythis only works if the guest cant float across numa ndoes17:40
stephenfinwhich they can't if they have a guest NUMA topology17:40
sean-k-mooneystephenfin: yep17:41
stephenfin<stephenfin> I appreciate it's complicated because we need to marry the non-NUMA model with the NUMA model17:41
sean-k-mooneyif we can make all guest numa guest in nova we can fix this17:41
stephenfin^ that's the complicated bit17:41
stephenfinbecause we can't make all guests NUMA guests, as you say17:41
sean-k-mooneyyep17:41
stephenfinso we need to somehow have two views into memory - one with NUMA context and another without it17:41
sean-k-mooneyso making all numa guest have hw:mem_page_size=any we trun on the memroy tracking17:42
stephenfinand somehow still be able to get a useful "how much free memory do I have" answer for both NUMA and non-NUMA guests17:42
sean-k-mooneyit will use smallpages unless the image asks17:42
sean-k-mooneywe can then extend that to do over subsiption if we want17:42
stephenfinthat's doable though17:42
sean-k-mooneyclaudiub: anyway sorry for the info overload17:43
claudiubnono, thanks, this is useful. :)17:43
sean-k-mooneyclaudiub: just being trying to fix this for 6+ years17:43
stephenfinfor example, in the NUMA case, free memory for NUMA N could be seen as (NUMA N total memory * overcommit) - (NUMA N used memory) - (non-NUMA used memory / NUMA count)17:43
stephenfini.e. just evenly divide the non-NUMA memory usage across all NUMA nodes17:44
sean-k-mooneywe cant do that17:44
stephenfinmy point being, there are other ways to solve this that don't involve the hw:mem_page_size=any hammer :)17:44
sean-k-mooneythat will cause oom issue17:45
sean-k-mooneywhen a vm has a numa toplogy we tell teh kernel and restict its meory allcoations and the cores it can float over to the numa node17:45
stephenfinby the memory isn't locked17:45
stephenfinso it can be swapped out17:45
sean-k-mooneyit can be swapped yes17:46
sean-k-mooneyin the case of 4k pages at least17:46
stephenfinand the memory for non-NUMA hosts will move across various NUMA nodes as needed17:46
sean-k-mooneyhugepages are not swapabel17:46
stephenfinyeah, I'm only focusing on small pages for now17:46
sean-k-mooneystephenfin: so there are 3 times we shoudl do. 1 numa blanceing, 2  hw:mem_page_size=any 3, make smallpages oversubscibale per numa node17:47
sean-k-mooneywell do 2 after 317:47
stephenfinI'm still not sure why 2 is needed, but agreed on the other two17:47
sean-k-mooneywe do to turn on the memroy tracking17:47
stephenfinI'll try to take a look at this the week after next17:47
sean-k-mooneywe dont do the claim otherwise in the hsot numna toplogy object17:48
stephenfinsince despite all this talk, I'm not going to start on it today :)17:48
*** slaweq has quit IRC17:49
sean-k-mooneyok either way i think we need to disucss this in the ptg again and we can talk about it on irc again before17:49
stephenfinagreed17:49
stephenfinwanna add it to the agenda if you haven't already?17:49
stephenfinif not I can17:49
sean-k-mooneyi didnt readded it since i was going to proceed based on what we agreed last ptg17:49
sean-k-mooneyi just didnt get time to wrok on this this cycle because of vdpa17:50
claudiubI'll try the hw:numa_pages thing as soon as possible, since it's a bit of a burning issue for us. :)17:50
*** slaweq has joined #openstack-nova17:51
sean-k-mooneyclaudiub: setting it to hw:mem_page_size=any or hw:mem_page_size=small should resolve your current issue17:51
sean-k-mooneyat the cost of oversubsciption of memory beign blocked17:51
lyarwoodstephenfin: do you have a link to you libvirt secure boot bug to hand?17:51
lyarwoodyour*17:52
stephenfinlyarwood: https://bugzilla.redhat.com/show_bug.cgi?id=192935717:52
openstackbugzilla.redhat.com bug 1929357 in libvirt "UEFI: Provide a way how to configure different combinations of secure boot enabled/disabled and keys enrolled/not enrolled" [Medium,New] - Assigned to phrdina17:52
lyarwoodthanks17:52
sean-k-mooneyclaudiub: it that is not an option for you and you can carry a downstream only patch you would add a random shuffle here https://github.com/openstack/nova/blob/20459e3e88cb8382d450c7fdb042e2016d5560c5/nova/virt/hardware.py#L2276 of host_cells17:52
claudiubwill try both. :)17:54
sean-k-mooneythe balancing without over subctiption or randomisation with it likely could be backproted as a workaround bugfix. with proper feature in the future17:56
*** derekh has quit IRC18:03
*** ralonsoh has quit IRC18:09
*** bbowen has joined #openstack-nova18:17
*** iurygregory has quit IRC18:22
*** iurygregory has joined #openstack-nova18:22
*** andrewbonney has quit IRC18:23
sean-k-mooneystephenfin:related to the previous topic it look like libvirt is locking the guest memroy any time a guest has vfio(pci passthough/sriov), mdev or nvme devices assigned nova was previously not aware of that and them means many guests we previously assumed  were swapable are not. i still have to file a bug for this but its emrging forlowing the memory locking disucssion we had for vdpa18:24
sean-k-mooneyim not sure how to fix that yet without requiring all guest with any kind of passthoug device to be numa guests or otherewise use hw:mem_page_size in some form18:26
sean-k-mooneywe can mitagate the problem for q35 guests by enabling the viommu18:27
sean-k-mooneybut i suspect this is the cause of many OOM bug that have been filed in the past18:27
sean-k-mooneyoh and more fun file backed memroy does not seam to work the way we tought either18:29
sean-k-mooneyi should do some more testing but usign it i was not actully able to allocate more vms then i had memory for without OOM issues killing the running vms18:30
sean-k-mooneyso it looks like instead of mmaping the guest memory form the files as the qemu/libvirt docs impleis18:31
sean-k-mooneyqemu just malloc the memroy normally and then also create a mapping of the memory to a file18:31
sean-k-mooneythat might be because we are usign the legacy api for this or it might be for a different reason but either way it makes me sad :(18:32
*** slaweq has quit IRC18:34
sean-k-mooneyactully i think i know why its broken if we want vms to  only have file backed memory which is what we inteded we need to explitly set the normal memory to 0 i belive and then add the file using the memory hotplug feature so ya it likely a qemu bug in the old api.18:49
*** rcernin has joined #openstack-nova18:50
*** rcernin has quit IRC18:56
*** mgagne has quit IRC18:56
*** mgagne has joined #openstack-nova18:57
*** whoami-rajat has quit IRC18:59
*** rcernin has joined #openstack-nova19:12
*** bbowen has quit IRC19:15
*** rcernin has quit IRC19:17
*** hamalq has joined #openstack-nova19:41
openstackgerritMerged openstack/nova master: libvirt: Parse the 'os' element from domainCapabilities  https://review.opendev.org/c/openstack/nova/+/67379019:43
*** rcernin has joined #openstack-nova20:00
*** nightmare_unreal has quit IRC20:15
*** gokhani has quit IRC20:17
openstackgerritMerged openstack/nova master: nova-manage: Add libvirt get_machine_type command  https://review.opendev.org/c/openstack/nova/+/76954820:17
*** k_mouza has quit IRC20:19
*** slaweq has joined #openstack-nova20:29
*** bbowen has joined #openstack-nova20:38
*** Jeffrey4l has quit IRC20:39
*** Jeffrey4l has joined #openstack-nova20:39
*** rcernin has quit IRC20:43
*** k_mouza has joined #openstack-nova20:50
*** k_mouza has quit IRC20:55
*** xek has quit IRC21:04
*** openstackgerrit has quit IRC21:05
*** rcernin has joined #openstack-nova21:09
*** luksky has quit IRC21:28
*** luksky has joined #openstack-nova21:28
*** luksky has quit IRC21:39
*** rcernin has quit IRC21:49
*** luksky has joined #openstack-nova21:53
*** ircuser-1 has joined #openstack-nova21:54
*** claudiub has quit IRC22:16
*** slaweq has quit IRC22:27
*** rcernin has joined #openstack-nova22:29
*** takamatsu has quit IRC22:42
*** rcernin has quit IRC22:54
*** rcernin has joined #openstack-nova22:54
*** swp20 has joined #openstack-nova22:56
*** takamatsu has joined #openstack-nova22:57
*** tkajinam has joined #openstack-nova22:57
*** songwenping__ has quit IRC22:59
melwittlyarwood: could you pls take a look at these stable/victoria backports? they've disabled tests in tripleo ci to workaround intermittent failures due to the bug https://review.opendev.org/c/openstack/nova/+/777121 and https://review.opendev.org/c/openstack/nova/+/77720923:03
*** openstackgerrit has joined #openstack-nova23:22
openstackgerritTakashi Kajinami proposed openstack/nova master: WIP: Clean up allocations left by evacuation  https://review.opendev.org/c/openstack/nova/+/77869623:22
*** luksky has quit IRC23:28
*** martinkennelly has quit IRC23:34
*** martinkennelly has joined #openstack-nova23:34
openstackgerritmelanie witt proposed openstack/nova master: Add functional test for bug 1837995  https://review.opendev.org/c/openstack/nova/+/77544923:51
openstackbug 1837995 in OpenStack Compute (nova) ""Unexpected API Error" when use "openstack usage show" command" [Undecided,In progress] https://launchpad.net/bugs/1837995 - Assigned to melanie witt (melwitt)23:51
openstackgerritmelanie witt proposed openstack/nova master: Dynamically archive FK related records in archive_deleted_rows  https://review.opendev.org/c/openstack/nova/+/77383423:51

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!