Thursday, 2020-12-03

sean-k-mooneydcapone2004: what exactly are you trying to enable00:03
sean-k-mooneydcapone2004:in general the answer is no by design that is not allowed but we may already have a way to do what you want in a more abstract way00:03
sean-k-mooney<feature policy="disable" name="hypervisor"/>00:04
sean-k-mooney  <feature policy="require" name="vmx"/>00:04
sean-k-mooneyso do you jsut want vmx or do you also want to disabel the hyperviror feature flag00:04
sean-k-mooneyyou can do both already00:04
sean-k-mooneyvmx will be present if you use host-model or host-passthough for the cpu_mode in the libvirt section of the nova.conf00:05
sean-k-mooneyhttps://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_mode00:06
sean-k-mooneyif you use cpu_mode=custom then you need to use cpu_model_extra_flags to add vmx https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_model_extra_flags00:06
sean-k-mooneyfor <feature policy="disable" name="hypervisor"/>00:07
sean-k-mooneyyou need to add either hw:hide_hypervisor_id=true in the flavor extra specs or img_hide_hypervisor_id in the image properties00:08
sean-k-mooneydcapone2004:^00:08
*** noonedeadpunk has quit IRC00:08
sean-k-mooneydcapone2004: that will allow you to set those two flags in the libvirt xml00:09
*** noonedeadpunk has joined #openstack-nova00:10
sean-k-mooneydcapone2004: note that adding vmx will only work if you actully have nested virt enabled in the host kernel kvm module parmaters00:10
sean-k-mooneyin this case the intel_kvm module00:10
sean-k-mooneyit also requires you to use virt-type kvm rather then qemu but you should be using kvm by default anyway just tought i would mention it just in case00:11
sean-k-mooneydcapone2004: hopefully that helps00:11
*** hamalq_ has joined #openstack-nova00:15
*** tosky has quit IRC00:18
*** hamalq has quit IRC00:19
dcapone2004sean I already tried all you suggested00:20
dcapone2004it doesn't work00:21
dcapone2004the hide_hyperivsor_id=true property passes a kvm=no to qemu00:21
*** hamalq_ has quit IRC00:21
dcapone2004instead of hypervisor=no, I have nested virtualization enabled and it works when my nested hypervisor is Linux/KVM00:21
*** mlavalle has quit IRC00:22
dcapone2004but just as described in several google search articles I found, when trying it with hyper-v, once hyper-v is enabled in a VM, the VM locks up and no longer boots... the solution appears to be based on those settings in that article I found00:23
dcapone2004I am passing the vmx flag to the VM with nova.conf and the cpu_model_extra_flags configuration00:24
*** hamalq has joined #openstack-nova00:25
*** cgoncalves has quit IRC00:28
*** ociuhandu has joined #openstack-nova00:31
sean-k-mooneywhat version of openstack are you using and what version of the linux kernel are you using00:31
sean-k-mooneydcapone2004: hide_hyperivsor_id=true should not disable kvm00:32
*** xek has quit IRC00:33
sean-k-mooneyoh i see what its doing00:34
sean-k-mooneyit will produce something like this by default http://paste.openstack.org/show/800674/00:35
*** ociuhandu has quit IRC00:35
sean-k-mooneyvmx=on,pdcm=on,pcid=on,hypervisor=on, with kvm=off00:35
dcapone2004ussuri, kernel 4.10, centos 8 standard kernel00:36
sean-k-mooneybut i think that changes if you set the image type to windows00:36
*** gyee has quit IRC00:36
sean-k-mooneyussuri has the hyperv change i was wondering about00:36
dcapone2004so, I don't have as many flags as you enabled00:37
dcapone2004what happens on mine is that NO hypervisor option is passed00:37
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5362-L538700:37
dcapone2004and I think I need it to explicitly pass no based on that "fix" article I read00:37
sean-k-mooneythis is the addtional logic for windows guest00:37
sean-k-mooneydcapone2004: im using cpu_mode=host-passthough00:38
sean-k-mooneyso its adding all of my virutalisable cpu flags by default00:38
sean-k-mooneydcapone2004: can you check if you have os_type=windows in the image metadata00:38
sean-k-mooneydcapone2004: if not that might fix it00:39
dcapone2004yeah, I'm using custom as we have some different CPUs in our clusters so i use custom to use the lowest common CPU model among them all00:39
dcapone2004I then use flavor traits to expose higher CPU models to VMs when needed based on the flavor00:39
dcapone2004aka, AVX2 to expose Haswell and have the scheduler route the VM to a node that has Haswell or better CPUs00:40
sean-k-mooneytraits wont make the cpu feature avaiable just so you are aware00:40
sean-k-mooneyi assume you are using the recently added support to list multiple cpu models00:40
dcapone2004correct00:40
sean-k-mooneyya that should work00:41
dcapone2004I am assuming that it at least passes through the features that are included in cpu_map.xml definitions of each cpu, just none of the "extra traits" unless explicitly defined00:41
sean-k-mooneycustom will enable everytin in cpu_map yes00:42
dcapone2004the VMs recognize the CPU as Haswell vs IvyBridge when booted when I use the flavor when I define AVX2 as required00:42
dcapone2004ok, that is the behavior I thought I was receiving00:42
sean-k-mooneyyes we have  logic to select the cpu model form the list that includes the feature you requested00:43
sean-k-mooneywe test them in order i belive and use the first that has all requested features00:43
dcapone2004correct that is the behavior I see and expected00:43
sean-k-mooneywell that was the behavior we intended but that does not mean we dont have a bug :)00:43
sean-k-mooneynice to know it works00:44
sean-k-mooneyso in your case00:44
sean-k-mooneyi think we need to extend this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5390-L539200:44
dcapone2004only this hypervisor option I can't seem to figure out if it possible and I've been combing through the docs for 2 days now...I usually prefer to solve my issues myself before asking because every time I read docs for one thing I'm trying to fix, I end up learning 4 more things :-)00:44
sean-k-mooneyto add hypervior=off00:44
sean-k-mooneydcapone2004: i may have missed it but did you check if you have os-type=windows in the image00:45
*** waverider has quit IRC00:45
sean-k-mooneyso that https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5384-L5386 runs00:45
dcapone2004let me double check, pretty sure our windows images have a bunch of options set according to the docs recommendations but let me verify00:45
dcapone2004oddly enough i don't....we have os_distro set to win2k19 which is what i think was in the docs00:46
dcapone2004let me try adding that additional property and see what happens00:47
*** gregwork has quit IRC00:48
dcapone2004so in Horizon, os_type shows up under the XenAPI Driver Options....I think that is why we did not set it00:49
dcapone2004as I/we thought it was a Xen specific property00:49
sean-k-mooneythat code was added to trick nvidia dirvers into tinking it its runing on a physical host00:49
sean-k-mooneyhopefully it will help00:50
sean-k-mooneyon the horizon front00:50
sean-k-mooneythat is actully managed via glance metadefs00:50
dcapone2004am I looking at the correct property .... yes in my search for documentation, I read the "bug" report and the full history on that implementation :-)00:50
sean-k-mooneyso those should likely be updated00:50
dcapone2004but it is the correct property that I am looking to enable even though it appears to be documented a bit poorly in horizon?00:51
dcapone2004        if (virt_type in ("qemu", "kvm") and00:54
sean-k-mooneyno its this one https://github.com/openstack/glance/blob/45749c30c1c02375a85eb17be0ccd983c695953f/etc/metadefs/compute-libvirt-image.json#L97-L10500:54
dcapone2004That code calls a different hyperV specific function based on this property so I am hoping it is a winner :-)... will let you know shortly00:54
dcapone2004yeah that option in horizon is listed under XenApi in Horizon for some reason00:55
sean-k-mooneyweird00:55
sean-k-mooneyok well if it does not work feel free to file that as a bug and link to the code i pointed too and the article.00:55
sean-k-mooneywe shoudl be able to add hypervior=no if libvirt support it00:55
sean-k-mooneywhich it shoudl00:56
sean-k-mooneybut i would hope its not required with the existing code00:56
dcapone2004ok...I feel confident it is going to work with os_type=windows....if it does it is more of  a documentation bug in glance/horizon for that property00:56
dcapone2004this is what horizon says about the property...OS Type (os_type)00:57
dcapone2004and it limits the injected host name to less than 16 characters.00:57
sean-k-mooneywhat i have a ussuri deployment too let me check that wrong00:58
dcapone2004makes it seem as though the property is very Xen specific....your code clearly shows it is used in libvirt as well00:58
sean-k-mooneyya so its not under the libvirt driver options for image section and is in zen with differet text00:59
sean-k-mooneyoh https://github.com/openstack/glance/commit/e1fe3024bb2482853130fac0be87e6a6a44e610e01:00
dcapone2004:-)  someone else already noticed it01:01
dcapone2004so I just booted the VM01:01
sean-k-mooneydcapone2004: stephenfin fixed it when he deleted the xenapi driver01:02
sean-k-mooneybut that is part of wallaby01:03
sean-k-mooneynot ussuri01:03
sean-k-mooneydcapone2004: you can fix that in your current deployment via the glance api01:03
dcapone2004didn't pass hypervisor=no, but it did pass a whole bunch of other hv options....might essentially resolve the same issue...will know in about 6 minutes when hyper-v finishes installing...I greatly appreciate your help01:03
sean-k-mooneyyou can update the metadata defs via the api01:03
dcapone2004yeah i can just update our internal MOPs01:03
sean-k-mooneydcapone2004: yep os_type is used to enable the hyperv enlightenments too which enable the hyperv optimisations01:04
sean-k-mooneyit should improve you guest performance01:04
dcapone2004admittedly I don't overly care about nested VM performance....we basically use nested VM mostly to lab out potential deployments for customers01:05
dcapone2004but good to know anyway01:05
sean-k-mooneydcapone2004: well it will impre the first level vm performance too and it shoudl reduce power use when the vms are ideling01:06
*** cgoncalves has joined #openstack-nova01:06
dcapone2004ok, maybe slight miscommunication.....these are being deployed on KVM hosts....not Hyper-V hosts....don't know if that makes a different in the configuration....I point that out because I cannot understand how exposes hyper-v features to the VM would aid performance when running on KVM01:07
sean-k-mooneythat is what i was expecting hyperv on kvm01:08
sean-k-mooneywindow has special kernel code for runing on hyperv and kvm support some of the hyperv feature01:09
sean-k-mooneyhttps://libvirt.org/formatdomain.html#hypervisor-features has a table ot the hyperv feature01:09
dcapone2004i see01:09
sean-k-mooneyalthough we dont support enabling most of them basically because no  one has asked or done it01:10
dcapone2004unfortunately the bad news is that didn't seem to resolve this specific situation.... Im about to try this out on a non openstack standalone kvm system to see if hypervisor=off does anything for it01:11
sean-k-mooneyso you could manally edit the xml and add that01:12
dcapone2004but sinc eyou mentioned performance improvements....is there anyway to add those flags to already existing, deployed/modified VMs?01:12
sean-k-mooneythen use libvirt to restart the vm01:12
sean-k-mooneynot openstack01:12
sean-k-mooneydcapone2004: no not without a db update01:12
dcapone2004might try that as well first01:13
dcapone2004that is what I thought...db update and hard reboot?01:13
sean-k-mooneyif you were willing to do that then all you need to do is add img_os_type windows to each vm in the instance_system_metadata table01:13
sean-k-mooneydcapone2004: yes db update and hard reboot01:13
dcapone2004alright, you have been very helpful, I am going to play around with a few things and see what happens, if the hypervisor=no option works, I might be asking for a feature request :-)01:14
sean-k-mooneyif you confim that adding the elemnt fixes the issue then we can simple add it here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5386 or here https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L539301:15
sean-k-mooneyas a bug fix01:15
sean-k-mooneydepending on if its jut for hyperv or for hyperv and kvm01:15
sean-k-mooneysorry windows or windows and linux01:15
dcapone2004I think this is KVM specific based on the articles about the problem and how to fix it....I unfortunately don't have any openstack hyper-v nodes to test for sure01:16
sean-k-mooneykvm/hyperv does not matter in this case01:16
dcapone2004linux nested virtualization works without issue01:16
sean-k-mooneyyep01:16
dcapone2004I've used it on this same cluster and with the same flavor without issue01:16
sean-k-mooneyi use it every day01:16
sean-k-mooneyi do all my openstack dev on my home openstack cluster01:17
sean-k-mooneywith nested virt and hypervior hiding01:17
dcapone20041 more question...to potentially save me some time searching....do you know where the xml files for VMs is in a kolla containerized deployment?01:19
sean-k-mooneyoh you dont edit the xmls01:20
sean-k-mooneyi use kolla01:20
sean-k-mooneyyou need to docker exec into nova_libvirt01:20
sean-k-mooneye.g. docker exec -it nova_libvirt bash01:20
sean-k-mooneythen do virsh edit <vm id>01:20
sean-k-mooneyif you look at the extended atibute in the server show as an admin you can get teh libvirt domain name01:21
sean-k-mooneyotherwise you just need to find the one with the uuid that matches01:21
dcapone2004ok, I thought you said, "so you could manally edit the xml and add that"  "then use libvirt to restart the vm01:23
sean-k-mooneyah yes when you do virsh edit01:24
sean-k-mooneyit will open the xml in an editor for you01:24
sean-k-mooneythat is what i ment01:24
dcapone2004got it01:24
sean-k-mooneyit will also validate it with libvirt and only allow it to save if the edit is valid01:24
sean-k-mooneyanywyay its 01:25 here so im heading to bed01:25
sean-k-mooneyif that works defintly file the bug and we can see if we can fix this01:25
sean-k-mooneythe nova meeting is tomorrow too if you wanted to bring it up in open dicusstion01:26
sean-k-mooneyif you can confirm either way if setting that option fixes your issue let me know an i can bring it up if you cant attend01:26
dcapone2004will do01:27
dcapone2004just ran virsh reboot 35, so we shall see01:27
sean-k-mooneyyou might need to stop the domin and start it by the way01:28
sean-k-mooneyi dont rembere if reboot does a soft reboot or hard01:28
dcapone2004was going to iterate through all possible methods before quitting :-)  .... get some rest...your assistant has been much appreciated01:28
sean-k-mooneysoft being a qemu monitor command to tell the os to reboot without restarting the qemu process01:28
sean-k-mooneyo/01:29
*** rcernin has quit IRC01:58
*** rcernin has joined #openstack-nova01:58
*** brinzhang0 has joined #openstack-nova02:01
*** brinzhang_ has quit IRC02:04
*** Jorhson has quit IRC02:04
*** hemanth_n has joined #openstack-nova02:29
*** hamalq has quit IRC02:32
*** jdillaman has quit IRC02:35
*** Yumeng has joined #openstack-nova02:37
*** dcapone2004 has quit IRC02:41
*** rcernin has quit IRC03:06
*** Yumeng has quit IRC03:11
openstackgerritchengsheng proposed openstack/nova master: CPU selection with hypervisor consideration  https://review.opendev.org/c/openstack/nova/+/76233003:17
*** brinzhang0 has quit IRC03:20
*** rcernin has joined #openstack-nova03:26
*** xinranwang has joined #openstack-nova03:29
*** brinzhang has joined #openstack-nova03:29
*** rcernin has quit IRC03:30
*** rcernin has joined #openstack-nova03:30
*** sapd1_x has joined #openstack-nova03:33
*** mkrai has joined #openstack-nova03:43
*** psachin has joined #openstack-nova03:59
*** brinzhang_ has joined #openstack-nova04:04
*** brinzhang has quit IRC04:07
*** lemko has quit IRC04:25
*** lemko has joined #openstack-nova04:25
*** k_mouza has joined #openstack-nova04:55
*** nweinber has joined #openstack-nova04:57
*** k_mouza has quit IRC05:00
*** nweinber has quit IRC05:04
*** ianw is now known as ianw_pto05:24
*** evrardjp has quit IRC05:33
*** evrardjp has joined #openstack-nova05:33
*** sapd1_x has quit IRC05:40
openstackgerritWenping Song proposed openstack/nova master: Nova supports password encrypted VNC  https://review.opendev.org/c/openstack/nova/+/62233605:51
*** songwenping__ has joined #openstack-nova06:00
*** songwenping_ has quit IRC06:03
*** chengsheng1 is now known as chengsheng06:07
brinzhang_gibi, dansmith: updated cyborg shelve/unshelve support patch, please review it while you are free https://review.opendev.org/c/openstack/nova/+/729563, thanks06:32
openstackgerritXinran WANG proposed openstack/nova-specs master: Smart-nic Support Specification  https://review.opendev.org/c/openstack/nova-specs/+/74278507:05
*** mkrai has quit IRC07:23
*** mkrai_ has joined #openstack-nova07:23
*** rpittau|afk is now known as rpittau07:27
*** sapd1_x has joined #openstack-nova07:29
*** dklyle has quit IRC07:31
*** songwenping_ has joined #openstack-nova07:37
*** songwenping__ has quit IRC07:41
*** slaweq has joined #openstack-nova07:41
*** mkrai_ has quit IRC07:42
*** lpetrut has joined #openstack-nova07:46
*** belmoreira has joined #openstack-nova07:50
openstackgerritWenping Song proposed openstack/nova master: Nova supports password encrypted VNC  https://review.opendev.org/c/openstack/nova/+/62233608:07
*** tesseract has joined #openstack-nova08:18
*** luksky has joined #openstack-nova08:22
*** JamesBen_ has joined #openstack-nova08:23
*** JamesBenson has quit IRC08:23
*** Jorhson has joined #openstack-nova08:24
*** mkrai has joined #openstack-nova08:30
*** JamesBen_ has quit IRC08:32
*** JamesBenson has joined #openstack-nova08:33
*** tosky has joined #openstack-nova08:34
bauzasgood morning Nova08:38
*** redrobot has quit IRC08:41
*** rcernin has quit IRC08:46
*** vishalmanchanda has joined #openstack-nova08:47
gibigood morning bauzas08:47
bauzas:-)08:49
* bauzas just depiling a shit ton of emails just for one day off08:49
* bauzas wonders what happened in the world 08:49
*** andrewbonney has joined #openstack-nova08:49
openstackgerritBalazs Gibizer proposed openstack/nova master: Separate out the migration tests  https://review.opendev.org/c/openstack/nova/+/76530008:59
*** rcernin has joined #openstack-nova09:00
*** zzzeek has quit IRC09:02
*** rcernin has quit IRC09:04
*** zzzeek has joined #openstack-nova09:04
elodgood morning :)09:10
elodbauzas: if you will have time can you have another look at this patch? https://review.opendev.org/c/openstack/nova/+/76443209:11
*** derekh has joined #openstack-nova09:11
elodthis would unblock the gate on stable/victoria09:11
bauzaselod: for sure, I just want to progress on the routed networks impl, but I can do other urgent stuff09:11
bauzasa-ha, good reason then09:11
bauzaselod: and fwiw, lyarwood is on PTO those 2 days09:12
bauzasdamn, those RH folks who are always on vacation...09:12
elodthis is lyarwood's commit so it does not really matter ;)09:12
elodactually, only a commit message change happened since your last +1 (and a successful zuul run \o/)09:13
*** ociuhandu has joined #openstack-nova09:42
*** xinranwang has quit IRC09:45
elodbauzas: thx! \o/ (and sorry for the interrupt o:))09:46
bauzasnp09:47
*** k_mouza has joined #openstack-nova09:49
*** luksky has quit IRC09:51
*** xek has joined #openstack-nova09:55
*** ociuhandu has quit IRC09:57
*** jangutter_ has joined #openstack-nova09:59
*** mkrai has quit IRC10:00
*** ociuhandu has joined #openstack-nova10:01
*** jangutter has quit IRC10:02
*** ociuhandu has quit IRC10:19
openstackgerritLucian Petrut proposed openstack/nova master: hyper-v rbd volume support  https://review.opendev.org/c/openstack/nova/+/76355010:24
*** dtantsur|afk is now known as dtantsur10:26
*** mkrai has joined #openstack-nova10:31
*** ociuhandu has joined #openstack-nova10:41
openstackgerritBrin Zhang proposed openstack/nova master: Replace all_tenants with all_projects  https://review.opendev.org/c/openstack/nova/+/76531111:05
*** sapd1 has quit IRC11:17
*** zzzeek has quit IRC11:17
*** zzzeek has joined #openstack-nova11:19
*** luksky has joined #openstack-nova11:22
chengshengkashyap: I have updated: https://review.opendev.org/c/openstack/nova/+/762330/11:27
*** sapd1_x has quit IRC11:27
kashyapchengsheng: Hi; will look.  (Side note: I'm juggling various things this and next week, as I'll be off from 14-Dec until 31-Dec)11:28
*** ociuhandu_ has joined #openstack-nova11:28
gibikashyap: thanks for the heads up, have a nice time off!11:29
kashyapgibi: Thank you; lots of non-computer reading :-)11:29
gibinice!11:30
*** ociuhandu has quit IRC11:31
*** sapd1_x has joined #openstack-nova11:33
*** spatel has joined #openstack-nova11:34
*** sapd1_x has quit IRC11:38
*** spatel has quit IRC11:39
*** k_mouza has quit IRC11:42
*** psachin has quit IRC11:45
*** k_mouza has joined #openstack-nova11:45
brinzhang_gmann: There is an small issue while I want the replace the list servers's policies, I am not find a good way to decrepate the old policy (https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L1299), I have submited a base patch, hope you can give some suggestions11:47
openstackgerritBrin Zhang proposed openstack/nova master: WIP: Replace tenants* with projects* in List Servers's policy  https://review.opendev.org/c/openstack/nova/+/76531511:48
brinzhang_gmann: this is the replace role name patch https://review.opendev.org/c/openstack/nova/+/76531511:48
brinzhang_gmann: thanks11:48
brinzhang_gibi, stephenfin, sean-k-mooney, gmann: the blueprint remove-tenant-id need a microversion, and there are so many nova API need to be changed, so I would like to get a microversion to avoid many conflict, do you have time to review the first patch that adding a microversion 2.88 for this change. links:https://review.opendev.org/c/openstack/nova/+/76429211:52
sean-k-mooneybrinzhang_: im not sure we have many patches tat are changing the api at present, i i would hope there wont be many conflicts12:00
sean-k-mooneybut yes ill try to review later today12:01
brinzhang_sean-k-mooney: thanks, but from the list nova apis in the spec, there are at least 3 APIs need a microversion, I thinks https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/remove-tenant-id.html12:02
brinzhang_whatever, there is a microversion to be bound, it's easy to do ^^12:03
sean-k-mooneyyep but how many of those are close to merging12:03
sean-k-mooneywhat im not sure about is what to do with the follow up patches12:04
brinzhang_I thinks this one https://review.opendev.org/c/openstack/nova/+/76429212:04
sean-k-mooneyit kind of feels like you shoudl be doing this in one big patch12:04
sean-k-mooneyif its 3 it feels like you need 3 microverions12:05
brinzhang_no, I wont to do this in one patch12:05
brinzhang_it's not easy to review, and not easy to manage by me12:05
sean-k-mooneyright but since master is ment to be deployable at all times if its 3 patches it strictly speaking should be 3 microverions i think but perhaps we can make an excption here12:06
brinzhang_sean-k-mooney: i know what you are concern, I try to complete this in Wallaby release12:07
sean-k-mooneyi think the best way forward is too have multiple patches but only merge them when all patches are ready12:07
brinzhang_but might as your concern, may Icannt complete ^^12:07
sean-k-mooneygibi: gmann  any toughts on ^12:08
sean-k-mooneygibi: gmann  the remove-tenant-id changes are really too big to have in one patch12:09
brinzhang_wan-k-mooney: yeah, it's also good to me, if so, that I should avoid to maintain more microversion keys in all patches12:09
sean-k-mooneygibi: gmann  but we also dont want multiple micorverions here12:09
sean-k-mooneybrinzhang_: in anycase ill try and review it today12:10
brinzhang_sean-k-mooney: thanks12:11
sean-k-mooneybrinzhang_: are there more patches in that serise by the way or just the 3 your have pushed12:12
brinzhang_yeah, I just pushed List Servers APIs changes12:12
brinzhang_If there is need all patches submited then to review, that you all can ignore my asked above ^^12:13
brinzhang_That's nothing12:13
sean-k-mooneywell it was more if im reviewing it ill try and review all the patches at the same time12:13
sean-k-mooneyhttps://review.opendev.org/q/topic:%22bp%252Fremove-tenant-id%22+(status:open%20OR%20status:merged) so i was wondering if there were more pending or if that was it12:14
sean-k-mooneythey dont all need to be there12:14
sean-k-mooneyjust wanted to make sure that had all the patches that were currently avaiable12:14
brinzhang_There a two patches are avaliable, except the policy changes patch, that I want to get help from gmann12:15
brinzhang_after complete the policy changes, the server list apis change is ok for this microversion, IMO, yes12:16
*** mgariepy has quit IRC12:20
gibisean-k-mooney, brinzhang_: what if we merge the changes gradually but not expose the new microversion until the last patch?12:22
gibiwhat happens if we don't do this change until the last patch? https://review.opendev.org/c/openstack/nova/+/764292/5/nova/api/openstack/api_version_request.py#24812:22
sean-k-mooneygibi: i was wondering about that too i think we did that in the past but if we do we need to diable the new codepaths until the last patch merges12:23
brinzhang_for example: in the server list apis, I need to remove the tenant_id and all_tenants, and replaced with project_id and all_projects, some places need the version to have a judgement, maybe it's not easy to control all changes if there is not a microversion12:24
gibisean-k-mooney: why do we need to disable the new codepaths? Not having the microversion 88 published makes those new codepath unreachable12:25
brinzhang_it's my opinion12:25
sean-k-mooneygibi: oh ok in that case yep that should work12:25
gibibrinzhang_: you do have a microversion it just not available for the client to request it12:25
sean-k-mooneyunless a different api change takes the microversion12:25
gibisean-k-mooney: yeah, another api change can break this12:26
gibihm hm12:26
*** ociuhandu_ has quit IRC12:26
gibiso if we want to go this direction then we need to make the api patches serialized12:26
gibiright now12:27
gibinot just at the merge point12:27
*** ociuhandu has joined #openstack-nova12:27
sean-k-mooneybasically allocate a micro version to them12:27
sean-k-mooneycould we do that with placeholder microverions?12:27
sean-k-mooneyand change the meaning of the microversion when it merges12:28
sean-k-mooneythat a bit of  hack12:28
sean-k-mooneybug kind of like the palceholder db migrations12:28
gibihm12:28
sean-k-mooneyallocate 2.88 2.89 and 2.90 to the 3 specs in flight and make them all the same as 2.87 for now12:29
brinzhang_as your concern above, if we placeholder microversion, and I am not completed this in this release, it will be a bad news12:29
sean-k-mooneythat still not great12:29
gibihow far the other two patches from merge?12:29
gibiif we could merge them quickly then this problem is solved for the cycle12:29
gibi(assuming no new spec proposed api changes for wallaby)12:30
gibie.g. we allocating the microversion by merging the two small feature first12:30
brinzhang_there is a noVNC spec reqired a microversion also in my list12:30
gibiso the novnc password, and the hypervisor api modernization are the in flight api changes besides the tenat_id one12:31
brinzhang_yes, if there are all quickly completed fastly, it would be better.12:32
gibiI don't see open patches for the hyperisor modernizaton :/12:33
brinzhang_As I know the noVNC implentation code is ready to review, my staff complete it today, all tests: https://review.opendev.org/c/openstack/nova/+/62233612:33
sean-k-mooneywell there is also https://review.opendev.org/c/openstack/nova/+/74950512:34
sean-k-mooneythat one proably shoudl be merged first for 2.8812:35
sean-k-mooneyalthough it could be after12:35
sean-k-mooneywe do wnat to get that done sooner rather then later however12:35
sean-k-mooneystephenfin: whats your plance regardign fixing all the http status codes ^12:36
stephenfinI don't really have one. It sounds very low priority. I might do it if I get some other stuff landed first12:37
*** ociuhandu has quit IRC12:37
sean-k-mooneystephenfin: looks like you havent worked on it in 3 months will you be updating that soon or in the new year12:37
sean-k-mooneyok so sound like we shoudl not wait for that one so12:37
stephenfinno, definitely not12:37
gibistephenfin: thanks for the info12:38
stephenfindo I note have the hypervisor one up?12:39
stephenfinnot12:39
* stephenfin checks12:39
sean-k-mooneyyou do i think12:39
zigoHi. When building Nova 22.0.1, I get 1787 unit test failures like this one: http://paste.openstack.org/show/800690/12:39
zigowhile nova 22.0.0 does build without any issue.12:39
zigoIs this a known problem?12:39
gibiI don't find it here https://review.opendev.org/q/topic:%22bp%252Fmodernize-os-hypervisors-api%22+(status:open%20OR%20status:merged)12:39
stephenfinwhoops, wrong topic12:39
stephenfinhttps://review.opendev.org/q/topic:%22bp%252Fdeprecate-os-hypervisors%22+(status:open%20OR%20status:merged)12:39
* stephenfin updates12:40
brinzhang_so the noVNC that we can promote priority, maybe it's the fast one that closes to merge12:40
stephenfingibi: fixed12:40
sean-k-mooneybrinzhang_: gibi  have we been doing runway this cycle12:40
zigoIf nobody knows, then I can probably bisect the 22.0.0 to 22.0.1 patches ...12:41
gibizigo: give me a se12:41
gibic12:41
gibistephenfin: thanks12:41
sean-k-mooneynot really12:41
sean-k-mooneyok can we add the password one to https://etherpad.opendev.org/p/nova-runways-wallaby12:41
gibisean-k-mooney: the etherpad is up there it is just only brinzhang_ who put thing is nit12:42
gibithing in it12:42
brinzhang_sean-k-mooney: yeah, and I already used it to put cyborg support shelve/unshelve feature, and I will add the noVNC patch later in the runway12:42
*** artom has quit IRC12:44
gibizigo: looked at the diff but nothing popped out, so I guess it is bisect time.12:44
zigogibi: Thanks for looking, I'll try then.12:45
gibizigo: let me know what you found12:45
sean-k-mooneyyep so if we do noVNC then os-hyperviors then teants change?12:45
sean-k-mooneythat shoudl avoid it assumeing stephens paatch is already ready for review otherwise move os-hyperviors to 2.9012:46
gibisean-k-mooney: as soon as we merging the first patch of the tenant_id referring internally to 2.88  (or any specific microversion) we commit to not have any other microversion bump merged until we finish the tenant_id work. I'm affraid of such commitment12:48
brinzhang_gibi: agree12:49
*** vinay_m has joined #openstack-nova12:49
brinzhang_if I cannot complete it in Wallaby release, the 2.88 just suit for part of apis12:49
brinzhang_but if wait for all patches submited, and ready to review, there will be a heavy work12:51
gibithere is no easy solution12:52
sean-k-mooneybrinzhang_: merging it would block all other api work however so really we need ti to be close before we merge the first patch12:52
vinay_mhello every one, i have a devstack setup on a baremetal, and i have created a image out of snapshot of a openstack VM install with vepc software,when im launching vms with this image not able to ping or ssh , while vms with cirros or some other works fine12:52
vinay_mnot able to figure out what could be issue12:53
gibibrinzhang_: let's make it so that I will review the open API patches in tenant_id, vnc and hypervisor series to see where we are now.12:53
sean-k-mooneyvinay_m: did you look at the console output to see if cloud init reran and updated the networking correctly12:53
zigoIt's super annoying: invidual unit tests are looking good, it's only when I start testing them all at once that I get failures ...:/12:53
gibizigo: sh*t, I would like to help you. Is there any specific env setup that makes this appear? as I don't see it happening in the gate12:54
vinay_msean-k-mooney: yeah tried , but no log from this vm12:54
sean-k-mooneyvinay_m: if you had hardcoded macs or static ips the vm might just nto be getting the right ip12:54
zigogibi: I'll bisect and find out.12:54
gibizigo: anyhow I started running unit test on 22.0.1 in a loop now locally12:54
zigoBut it will take a long time...12:55
sean-k-mooneyvinay_m: there shoudl always be at least a minimal log is it actully booting correct12:55
brinzhang_gibi: the noVNC patch is ready to review now, IMO, it can be mereged firstly12:55
vinay_msean-k-mooney: same doubt , but status was showing active that's it12:55
brinzhang_the tenant_id just ready for the list servers apis change, except the policies changes, but after I get gmann's sugestions, I think it's easily to ready12:56
sean-k-mooneyvinay_m: and nothing form "openstack console log show <uuid>"?12:57
brinzhang_gibi: I am not similiar with the hypervisor series process12:57
vinay_msean-k-mooney: no console log12:57
sean-k-mooneyvinay_m: you might need to connect to libvirt directly and check but it sound like its not even getting to finding the os12:58
gibibrinzhang_: I think you have to make progress with the tenant_id patches while we merges the other API impacts and then try to assess the situation to see if your patches can be merged in once12:58
sean-k-mooneyvinay_m: im not familar with vepc but if it used differnt disk buses or machine types it could cause the image to be unbootable12:59
gibisorry but from the overall nova developement progress perspective I have to prioritize the smaller API impacts first before we block the API changes due to the tenant_id work.12:59
vinay_msean-k-mooney: os i have used was ubuntu 18.0.412:59
sean-k-mooneyoh vepc is vEPC12:59
vinay_m<sean-k-mooney> oh vepc is vEPC  -> yes :-)13:00
brinzhang_From my current job, I may not be able to complete all of them, because I have to update the Cyborg Shelve /unshelve support patch, or the noVNC patch with my partner, and other jobs from my boss13:00
sean-k-mooneyi tought it was an image creation tool like disk image builder13:00
*** ociuhandu has joined #openstack-nova13:00
gibibrinzhang_: does the tenant_id work has high priority from your perspective?13:00
sean-k-mooneyvinay_m: my best guess is there is someing in the vECP applcaition that is breakign the guest netorking13:01
brinzhang_gibi: is there a deadline line? maybe I can do some changes before the deadline13:01
gibibrinzhang_: M3 is feature freeze13:01
sean-k-mooneyvinay_m: im not really sure we can help much unless you have a specific nova/libvirt errorr13:01
gibithat is the deadline to land these changes13:01
gibiin W13:02
brinzhang_gibi: it's lower than my boss's point13:02
brinzhang_when?13:02
sean-k-mooneybrinzhang_: m3 in march/april13:02
gibiMarc 12 202113:02
sean-k-mooneyhttps://releases.openstack.org/wallaby/schedule.html yep13:02
gibibrinzhang_: from my limited perspective the cyborg patches has higher prio than the tenant_id work as the cyborg patches finishing something we already started13:03
brinzhang_so if I want to complete this feature, I need to submit all changes before Marc 1 2021, otherwise there is no time to review and update13:03
vinay_msean-k-mooney: yes , i have thought same but i have tried this complete process in  another devstack setup deployed in a ubuntu VM with same image , it worked over there13:03
sean-k-mooneybrinzhang_: ideally you would aim to finsih before that but ya13:04
brinzhang_gibi: yeah, the cyborg support patch is ready and it's closes to merge, hope you all to review13:04
gibibrinzhang_: I suggest to focus on cyborg and the stuff that is higher on you boss's list13:05
brinzhang_sean-k-mooney: I am not sure I can complete, but I can try13:05
gibibrinzhang_: as for me tenant_id can wait13:05
*** ociuhandu has quit IRC13:05
vinay_mproblem i'm thinking was with setup deployed on a bare metal .. will it ?13:05
brinzhang_gibi: Their priorities depend on my decision13:05
sean-k-mooneyvinay_m: if cirros/plain ubuntu is workign this is pointing to an issue with the vEPC config not with openstack13:06
brinzhang_gibi: yeah, after the shelve/unshelve patch merged, we will start the cyborg resume/paused support work, otherwise we will wait13:06
sean-k-mooneybrinzhang_: if you dont think you can complete the tenant work this cycle then we shoudl wait to merge it13:07
vinay_m<sean-k-mooney> vinay_m: if cirros/plain ubuntu is workign this is pointing to an issue with the vEPC config not with openstack -> hoo ok13:07
*** hemanth_n has quit IRC13:07
gibibrinzhang_: I know it is a pain to update such big series with a new api microversion number so I'm sorry but I still think we need to see the big picture and do that those rebases as we progress13:08
*** zzzeek has quit IRC13:09
brinzhang_gibi: I said before, it's nothing13:09
gibibrinzhang_: OK, then let's build up a series of tenant_id patches during the cycle, you can ping me to keep them reviewed, but we will not start merging the first one before we see more13:10
brinzhang_gibi: hope you all can review the patches, make it closes to merge except the microversion changes, maybe it's the smallest changes for me13:10
* gibi goes back to review the first tenant_id patch13:10
brinzhang_gibi: yeah, we can review but not merge it, I can accept this decision.13:11
*** zzzeek has joined #openstack-nova13:11
gibibrinzhang_: thank you for your understanding13:11
brinzhang_gibi, sean-k-mooney: NP, thanks again13:12
* brinzhang_ will go home13:12
*** artom has joined #openstack-nova13:13
gibibrinzhang_: o/13:13
*** mgariepy has joined #openstack-nova13:15
*** brinzhang_ has quit IRC13:18
*** ociuhandu has joined #openstack-nova13:26
*** mkrai has quit IRC13:29
*** mugsie has quit IRC13:32
*** raildo has joined #openstack-nova13:32
*** ociuhandu has quit IRC13:32
*** waverider has joined #openstack-nova13:37
*** nweinber has joined #openstack-nova13:41
*** dcapone2004 has joined #openstack-nova13:51
dcapone2004sean-k-mooney: I tried what you had suggested last night, and I think I need to pull the VM out and attempt to see what happens on a standalone libvirt kvm system....for some reason after start the VM, it would instantly automatically shut itself down13:52
gibistephenfin: when we removed os-fping in Rocky, did we intentionally kept the api doc for it in tree?13:53
sean-k-mooneydcapone2004: ok i guess there might be a kernel panic or something13:53
sean-k-mooneydcapone2004:in the windows guest13:54
*** ociuhandu has joined #openstack-nova13:54
dcapone2004sean-k-mooney: yeah not sure because I never am able to get to a console fast enough....Nova logs just show that instance stopped itself13:54
dcapone2004but the hypervisor=off parameter does get passed when it happens13:55
sean-k-mooneyok so it still fails with hypervior=off13:55
sean-k-mooneydcapone2004: you coudl also set hyperv to manual start in the windows service13:56
sean-k-mooneythat way when it crashs on start13:56
sean-k-mooneyyou can check the system events13:56
sean-k-mooneyon the next boot in the vm13:56
*** Jorhson has quit IRC13:56
sean-k-mooneysince it wont auto start13:56
dcapone2004I might try that but unsure if that will work either because the whole system immediately becomes unresponsive, so I dont know if anything even ends up logged13:57
lpetruthey, are instances automatically shutting down? nova might be doing it if db state says that it should be shut off13:58
*** hack-char has quit IRC13:58
*** hack-char has joined #openstack-nova13:59
dcapone2004ipetrut:  it is a specific test case where I am trying to test something by shutting down and restarting an instance directly in libvirt instead of using the openstack api13:59
*** ociuhandu has quit IRC13:59
lpetrutgot it, that's expected behavior but it can be disabled13:59
lpetrutjust a sec, fetching the cfg opt13:59
dcapone2004original DB power_state: 4, current VM power_state: 114:00
lpetrutyou may want to use this so that Nova doesn't automatically turn the instance back off: http://paste.openstack.org/raw/800701/14:00
dcapone2004help me with enum for the power states, that is what is showing in my logs14:00
*** ociuhandu has joined #openstack-nova14:02
dcapone2004just asked kolla to implement those changes, I'll report back in about 2014:03
lpetrutthis is what you're seeing in the logs https://github.com/openstack/nova/blob/22.0.1/nova/compute/manager.py#L9622-L962714:03
lpetrutunless those options are set, Nova will change the DB instance state when the instance is shut down through external actions. when it comes back up, nova enforces the db state and stops it again14:04
*** ociuhandu has quit IRC14:06
*** ociuhandu has joined #openstack-nova14:07
dcapone2004yeah except the message was confusing to me because it said "shutdown by itself", when in fact I just started it was libvirt14:08
dcapone2004with*14:08
dcapone2004so, I was interpreting the log entry to mean it recognized the start and then libvirt shut it down for some reason and now nova was syncing it14:08
sean-k-mooneydcapone2004: that is liekly the power state sync14:09
dcapone2004oh i think i get what your saying....nova sees when I shut it down with libvirt....processes that change in change and updates the DB and shows that it is shutdown (I can see this happen in the horizon interface where it shows as shutdown)14:09
sean-k-mooneyif its off in the nova db nova will shut it down14:09
dcapone2004then when I try to start it again, nova is saying, this is supposed to be shutdown and powers it back off14:10
sean-k-mooneyif we see the vm stop we update the db to be shutdown14:10
sean-k-mooneydcapone2004: as lpetrut noted you can disable this behavior if you want/need too14:10
dcapone2004yep, I am temporarily doing that now, waiting for kolla to reconfigure the changes, basically only need this for this test of the hypervisor option to see if that fixes the lock up with hyper-v on KVM14:11
lpetrutis hyper-v hanging or crashing and rebooting?14:15
lpetrutif you can't get any logs or crash dump, you can even attach a debugger to the serial port14:17
dcapone2004so, if I enable hyper-v, the system hangs on the boot14:18
dcapone2004after a hard reboot, windows loads itself into the startup recovery tool14:19
sean-k-mooneylpetrut: dcapone2004  is trying to get docker on windows working on windows 10 for context14:19
dcapone2004I found this fix here.... https://www.mess.org/2020/06/22/Hyper-V-in-KVM/#:~:text=Hyper%2DV%20on%20Windows%20requires,it%20is%...14:19
sean-k-mooneyso hyperv is need to run the linux continer in light weight vms14:19
dcapone2004so, I am trying to test what happens when the hypervisor=no parameter is passed14:20
*** martinkennelly has joined #openstack-nova14:21
dcapone2004I'm technically doing this using windows server 2019, but I found a different article that basically said the same thing for windows server 2019, but the article wasn't as short and sweet getting right to the config14:22
mgariepyhello, is there someone who can help push this patch along for Ussuri please: https://review.opendev.org/c/openstack/nova/+/75876114:24
lpetrutdcapone2004 it might be related to the virtual cpu flags. it's been a while since I last ran Hyper-V on top of KVM, but I was using those qemu parameters: -cpu Skylake-Client,hv-relaxed,hv-vapic,hv-time,hv-crash,hv-reset,hv-vpindex,hv-runtime,hv-synic,hv_spinlocks=0x1fff,+vmx14:25
dcapone2004ipetrut:  those flags I have...they are added by nova with the os_type=windows properties....sean helped guide me to try that last night14:27
lpetrutdcapone2004: it may be worth double checking, I'm not sure if Nova sets all the flags required for running Hyper-V on top14:31
dcapone2004the one I feel is missing based on that article I referenced and linked is the hypervisor=off option14:32
dcapone2004with your config changes, I have been able to add that via virsh, so enabling hyper-v now and about to reboot14:33
dcapone2004-cpu Haswell,pcid=on,vmx=on,rtm=on,hle=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vendor-id=1234567890ab,kvm=off is all that is generated by default, so there are definitely quite a few missing14:39
dcapone2004time and crash do not validate with virsh, but trying again with the rest of the options, -cpu Haswell,pcid=on,vmx=on,rtm=on,hle=on,hv-time,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-vpindex,hv-runtime,hv-synic,hv-reset,hv-vendor-id=1234567890ab,kvm=off14:48
dcapone2004bingo, those options appear to have resolved the booting problem.....now only if nova could add those additional options with some type of image/flavor property ;-)  ;-)14:56
sean-k-mooneydcapone2004: so which options are needed that are missing?14:58
*** dklyle has joined #openstack-nova14:58
sean-k-mooneylook like you enabled a bunch of the enlightnments14:58
sean-k-mooneyi dont see hypervior=off in the list14:59
sean-k-mooneyso it looks like we jsut ened to enable the enlightements14:59
dcapone2004nope, hypervisor=off wasn't needed with all of the other enlightments....I don't know if there was a specific magic individual one that did it14:59
sean-k-mooneylpetrut: do you know of any reason not to do that for all windows guests by default14:59
*** ociuhandu has quit IRC15:00
sean-k-mooneylpetrut: e.g. if your qemu and libvirt is new enough to support a hyperv enlightment we would jsut enable it by defualt15:00
sean-k-mooneylpetrut: that shoudl improve performace ingereall even without the nested virt or docker usecase15:01
dcapone2004hv-vpindex,hv-runtime,hv-synic,hv-reset those were the 4 additional that virsh would accept and I added15:01
sean-k-mooneyhv-synic might be the issue15:02
stephenfingibi: You mean the docs? Yes, we did, because it's still available on older releases15:02
sean-k-mooneyEnable Synthetic Interrupt Controller (SynIC)15:02
gibistephenfin: I mean the api ref docs.15:02
stephenfinand the API reference is unversioned15:02
gibistephenfin: so we don't have victoria api ref15:03
gibi:/15:03
stephenfinWe shouldn't have. There's just an API ref15:03
lpetrutsean-k-mooney, dcapone2004: probably the qemu version was the main concern. then we'd also have to make sure that those flags don't impact the performance15:03
stephenfinBecause a request for e.g. 2.13 should look the exact same across all versions of nova that support that15:03
*** mkrai has joined #openstack-nova15:04
sean-k-mooneylpetrut: our min qemu is proably new enought now15:04
gibistephenfin: but it is not true for fping as it is removed in rocky15:04
gibistephenfin: so fping request even if it is called with 2.13 is 404 since rocky15:05
sean-k-mooneylpetrut: ok not quite15:05
sean-k-mooneylpetrut: our min is 4.0.015:05
gibior at least this is how I understand the api ref15:05
sean-k-mooneyand min livbirt is 5.0.015:05
stephenfingibi: Yup, and for those cases we stick a note at the top saying "this has been removed in foo" and update the return codes to include HTTP 41015:05
sean-k-mooneylpetrut: we will be going to livbirt 6.0.0 and qemu 4.2.0 this cycle15:06
stephenfinhttps://docs.openstack.org/api-ref/compute/#ping-instances-os-fping15:06
stephenfin"This API only works with nova-network which is deprecated. It should be avoided in any new applications. These will fail with a 404 starting from microversion 2.36. It was removed in the 18.0.0 Rocky release."15:06
sean-k-mooneylpetrut: dcapone2004 so at that point we coudl enable all of them15:06
lpetrutI think all the above mentioned flags should be supported by qemu 4.0.0, not sure if libvirt needs to be aware of those as well15:07
sean-k-mooneyhttps://libvirt.org/formatdomain.html#hypervisor-features15:07
sean-k-mooneythe versions are listed there15:07
gibistephenfin: OK, then what to do with this https://review.opendev.org/c/openstack/nova/+/765311/1/api-ref/source/parameters.yaml#39615:08
stephenfinwe should keep it but not update it15:09
gibistephenfin: keep it as we cannot update the already deleted code15:09
gibiis it?15:09
lpetrutsean-k-mooney: nice, then I guess Nova could set those flags. I'm still not 100% if that should be the default or if it should be opt-in15:09
stephenfinyes15:09
stephenfinit's just documentation15:10
gibistephenfin: OK, thanks. it is clear now15:10
dcapone2004ipetrut: an enable_hyperv_support property maybe?15:10
*** ociuhandu has joined #openstack-nova15:11
lpetrutdcapone2004: yep, that would probably be the way to go unless it becomes the default for Windows guests15:12
lpetrutwe could take another look at qemu, maybe even ask the qemu guys if they think there's any potential issue (e.g. affecting perf, stability or older guests) in using those flags by default15:13
dcapone2004ipetrut:  if you discuss, all fo the othe rflags are already added, the only ones that were added in addition were these 4: hv-vpindex,hv-runtime,hv-synic,hv-reset   I know I mentioned that earlier, but figured I would just bring that up again15:15
lpetrutI assume most of those features are related to Hyper-V VMBus (virtio equivalent), so older guests might not support those enlightments15:15
lpetrutdcapone2004: right, this list is very helpful15:16
sean-k-mooneyso what we bacially will want is an image proerty15:16
sean-k-mooneythat is a list of enum values15:16
sean-k-mooneyand the image could declare what it supports15:16
*** ociuhandu has quit IRC15:16
sean-k-mooneywe can add the current allways on enlighemtn as the defualt for the value15:16
sean-k-mooneythe other way is to use traits15:17
lpetrutsean-k-mooney: sounds good. fwiw, new hyper-v enlightments might be added in the future so it's probably important to be able to pick the ones that the image supports15:17
lpetrutwhile having some safe defaults15:18
sean-k-mooneydcapone2004: so this is basically evolving form a potenial bug to a feature request15:19
noonedeadpunkhi! Any idea why I might be seing this http://paste.openstack.org/show/800707/ when `backend` is set to `oslo_cache.memcache_pool` in [cache]?15:19
sean-k-mooneyis this something you would have capsity to work on or just soemthjing you would like to see added15:19
sean-k-mooneynoonedeadpunk:that proably more of an oslo question15:20
lpetrutsean-k-mooney: I can't remember, does the libvirt nova driver allow you to set arbitrary cpu flags?15:20
sean-k-mooneynoonedeadpunk: https://github.com/openstack/oslo.cache/blob/master/oslo_cache/backends/etcd3gw.py#L1715:21
sean-k-mooneylpetrut: cpu flags yes but these are not cpu flags15:21
sean-k-mooneylpetrut: and only via the nova config15:21
sean-k-mooneynoonedeadpunk: it look like it does an unconditonal import15:21
noonedeadpunkit feels it tries to load all modules possible...  so nova just passes [cache] section just directly to oslo? (I'm not very common with codebase still - it's huge)15:22
sean-k-mooneynoonedeadpunk: these config option are actully adde by oslo.cache15:22
noonedeadpunkI'm jsut not sure why it loads etcd3gw backend at all...15:23
sean-k-mooneyim guessing its usign the stevado extention manager to load it unconditonally15:26
sean-k-mooneylooking for that currently15:26
sean-k-mooneynoonedeadpunk: where is that being raised15:29
noonedeadpunkfound it here https://zuul.opendev.org/t/openstack/build/0af9364cc9094b5096899ed7693a9f60/log/logs/host/nova-conductor.service.journal-10-50-46.log.txt#243115:30
*** lpetrut has quit IRC15:30
sean-k-mooneywe are not using sevedor to load this in oslo cache or in nova15:31
noonedeadpunkum.....15:32
sean-k-mooneyim wondering if this is coming form oslo.config15:32
noonedeadpunkcan hardly imagine path of the imports tbh15:33
noonedeadpunkBut I think it appeared only in V since in U haven't seen that message15:33
sean-k-mooneywe are using oslo cache15:33
sean-k-mooneybut i dont see it directly using sevedor in its code15:34
noonedeadpunkah, yes, might be oslo.config that using it, right15:34
sean-k-mooneyhttps://codesearch.opendev.org/?q=stevedore&i=nope&files=&excludeFiles=&repos=openstack/nova,openstack/oslo.cache,openstack/oslo.config,openstack/oslo.privsep15:34
sean-k-mooneythat is what im looking at15:34
*** redrobot has joined #openstack-nova15:35
sean-k-mooneywe use stevador for 3 things in nova, extra spec validator, schudler dirvers and metric monitors15:35
*** martinkennelly has quit IRC15:35
sean-k-mooneyoslo cache and oslo privsep dont use it at all it just in ther lower constraits15:36
sean-k-mooneybecause they depend on oslo.config which does use it15:36
*** ociuhandu has joined #openstack-nova15:37
sean-k-mooneyit might be https://github.com/openstack/oslo.cache/commit/308f49aaaad554573aeff8ddc68c39ff7fe5743815:37
noonedeadpunkseem like https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2152-L215415:37
noonedeadpunkyeah15:37
sean-k-mooneyya15:38
*** waverider has quit IRC15:39
*** waverider has joined #openstack-nova15:39
*** waverider has quit IRC15:40
sean-k-mooneyanyway this seams to be an oslo issue in one form or another15:40
*** waverider has joined #openstack-nova15:40
noonedeadpunkyeah, agreed - thanks for helping out - will go and chase oslo folks15:41
*** ociuhandu has quit IRC15:46
*** ociuhandu has joined #openstack-nova15:47
*** k_mouza has quit IRC15:48
*** k_mouza has joined #openstack-nova15:50
*** xek_ has joined #openstack-nova15:56
*** macz_ has joined #openstack-nova15:56
*** mlavalle has joined #openstack-nova15:57
gibinova weekly meeting starts in 3 minutes on #openstack-meeting-315:57
gmanngibi: sean-k-mooney we need to put API patch changes at the end which bump the microversion and all code cleanup as first in the series. and rebase is so hard for microversion race i think we end up doing this in every cycle.  brin is not online I will check with him on policy stuff help15:57
gmannypo. * rebase is *not* so hard for microversion15:57
*** xek has quit IRC15:59
gibigmann: most of the changes needed for the tenant_id bp is actually changes in the API code so we cannot frontload tha backend change as there is none15:59
gmanngibi: yeah but i think code cleanup also there which i suspect a large chunk but need to grep and see.16:00
gmannI think having all changes up and zuul +1 then we can start merging.16:01
gibigmann: I thin the majority of the change line vise is api sample changes and test code, and both need to have the microversion bump already in place16:01
gibigmann: yes, that would be ideal, but Brin noted that this will be a lot of patches16:02
gmannhumm16:02
gibiso we talked about options16:02
gibibut at the end we found no viable option other than having all the patches16:02
gibi(if we want to keep them in a single microversion)16:02
*** waverider has quit IRC16:03
gmannand base patch with -W until all are ready ?16:03
*** waverider has joined #openstack-nova16:10
*** mgariepy has quit IRC16:10
gibiyeah, basically16:13
gibiif we could merge every other API impacting changes accepted to W then maybe we can consider merging some of the tenant_id stuff or at least reconsider it16:13
gibiso now it is all or nothing16:14
gmanngibi: +116:17
*** mkrai has quit IRC16:19
*** mkrai_ has joined #openstack-nova16:20
gibisean-k-mooney: if you are around we need you in #openstack-meeting-316:21
*** dklyle has quit IRC16:25
*** dklyle has joined #openstack-nova16:25
*** waverider has quit IRC16:28
*** sapd1_x has joined #openstack-nova16:37
dcapone2004sean-k-mooney:  sorry, I had a meeting I needed to attend...I was always thinking about it as a feature request  .... and I wish I had the capacity to contribute way more than I do....I know python, but I have never done formal software development, so the whole submitting patches, code review process escapes me :-(16:37
kashyapdcapone2004: FWIW, it's actually gotten significantly simpler; OpenStack Gerrit also provides a "sandbox" to practise your workflow16:42
kashyap(https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html)16:42
dcapone2004nteresting...I will take a look at that16:43
sean-k-mooneydcapone2004: thats ok. can you file a blueprint for this https://blueprints.launchpad.net/nova/+addspec16:43
sean-k-mooneydcapone2004: basically like a bug but descibing your use case, what we have learns and what we your are trying to do16:43
dcapone2004sean-k-mooney: that I can do16:44
sean-k-mooneyif you can include the 4 enlightments that were need in your case that will helpt o document them16:44
dcapone2004kashyap:  The part that more eludes more than the simple checkout check in or review process is the whole multiple people working on the same thing at once and how that all gets merged16:44
kashyapdcapone2004: It takes some time getting used to, but it's not as complex - if you're focusing on one small part of the code16:46
kashyapdasp: If someone modified the same area of code that you're working on and that got merged; you'll need to do a bit of conflict/rebasing -- which can be worked out with more experienced contributors :-)16:46
kashyapErr, I meant dcapone2004 --^16:46
dcapone2004I will definitely take a look and play around...would love to contribute and by doing so, I know I would indirectly learn a whole bunch more about openstack in general16:47
*** ociuhandu has quit IRC16:47
*** rpittau is now known as rpittau|afk16:49
*** vinay_m has quit IRC16:50
*** mgariepy has joined #openstack-nova16:53
*** luksky has quit IRC16:54
*** mkrai_ has quit IRC16:54
stephenfinsean-k-mooney: gibi: bauzas: (fore after the meeting) before I send this email, are we sure we want to strip everything after the first period as opposed to replacing periods with dashes?16:58
stephenfin*for16:58
sean-k-mooneyeither of those i coudl be ok with16:59
sean-k-mooneyperiods to dashes is the recommend transformation in the RFS and docs for /etc/hostname and systemd-hostnamed16:59
sean-k-mooneyjust using the first segment is acutlly striping the domain and using the hostname for the host name field17:00
sean-k-mooneystriping woudl be using the dns "host name" for the non DNS "hostname"17:00
sean-k-mooneythose should generally be the same but are not required to be.17:01
bauzasstephenfin: I'm personnally on the former side17:01
artombauzas, https://bugzilla.redhat.com/show_bug.cgi?id=1721068#c41 oh yeah we did17:02
openstackbugzilla.redhat.com bug 1721068 in openstack-nova "allocations database is not properly cleaned" [Medium,Closed: errata] - Assigned to sbauza17:02
artom(QE it on Queens, I mean)17:02
bauzaschanging periods to dashes is less easy to explain in terms of backportability IMHO17:02
sean-k-mooneygibi: QE is quality engenering basically our test engineeres17:02
gibithanks17:02
sean-k-mooneygibi: so QE'd just means tested by them17:02
bauzasartom: I know I'm old but I remembered this17:02
stephenfinbauzas: same thing, no? The hostname is going to be different in both cases17:03
sean-k-mooneybauzas: reading the orginal unicode bug i woudl consider the current unicode bhavior to be invalid and actully a bug17:03
gibias we consider the audit a big win, and we did backported nova-manage commands in the past. I'm OK to take the risk17:03
gibiand merge the backports17:03
artombauzas, hehe17:03
artomSo the train one wasn't so bad: https://review.opendev.org/c/openstack/nova/+/72083817:03
gibibut I don't have +2 on stable :)17:03
bauzasstephenfin: I mean that I feel reasonably confident to explain to angry users that we consider that a FQDN isn't a hostname17:03
bauzasand that we only spoke of a server name17:03
stephenfinI'm worried about users with instance names like 'test-server.1', 'test-server.2', ...17:04
stephenfinor 'ubuntu18.04'17:04
bauzasthe first case seems weirdo to me17:05
gibihm, test-server.1 and test-server.2 becomes test-server as a hostname in the geuest17:05
sean-k-mooneyso as an exampel we are proposign if servername=example.fqdn then instance.hostname==example and instance.display_name==example.fqdn17:05
bauzasthe second case is indeed somehow hard to convince17:05
bauzasgibi: and I'm cool with this17:05
bauzas(to have duplicate hostnames)17:05
stephenfinsean-k-mooney: yes, and the alternative is instance.hostname=example-fqdn17:05
sean-k-mooneyyes17:06
sean-k-mooneyso if we maintain dispaly name that means that nova show example.fqdn will work in both cases17:06
sean-k-mooneyso ti wont affect server show17:06
sean-k-mooneyor list17:06
gibiyeah, I agree not to affect server show and list17:06
stephenfinYes, it'll only affect people relying on cloud-init, which you're saying is already broken for FQDN?17:06
bauzasjust being clear, don't touch display_name !17:07
stephenfin*cloud-init for DNS integration17:07
sean-k-mooneyso it will only effect what is in the metadata and passed to designate17:07
bauzashangouts, folks ?17:07
stephenfinisn't a bit late for you Europeans?17:07
bauzasactually, my wife will kill me17:07
stephenfinyeah :)17:07
gibimine too17:07
sean-k-mooneyyes with designate you get test-dns.invalid.dns.cloud.seanmooney.info for a servername=test-dns.invalid.dns via dns17:07
bauzasstephenfin: dude, you're part of Europe17:08
stephenfin*continental Europeans17:08
stephenfin;)17:08
bauzason a small isolated island tho17:08
* stephenfin is on PTO tomorrow too, fwiw17:08
gibi:D17:08
sean-k-mooneybauzas: its the brit in him showing :P17:08
bauzaswell, I actually feel isolated too17:08
gibipush this two option ack to the ML: a) truncate b) replace with -17:08
bauzasanyway17:08
bauzasgibi: +117:08
stephenfingibi: good call; me does that17:08
gibisleep on it17:09
sean-k-mooneycool that work for me too17:09
gibithen try to close this out next week17:09
gibiwhen stephenfin is back17:09
bauzasstephenfin: clarify there are only two options and that we're about to backport the chosen17:09
gibi^^ +117:09
sean-k-mooneydo we need a workaround flag for this17:10
sean-k-mooneyfor the backports17:10
artomRandom idea17:10
bauzas(but again, from an ops pov (well from the last decade), I just feel that naming your server with 'x.y' is either very smart or totally crazy17:10
artomYou can set the port's dns_name "manually" via the Neutron API17:10
bauzassean-k-mooney: NO17:10
artomSo... why not just stop doing it automagically when Nova creates/updates the port?17:10
sean-k-mooneybauzas: ok17:10
* gibi is slowly backing away from IRC and moving towards dinner17:10
artomAnd let people pick their own hostname that way17:10
sean-k-mooneyartom: only with designate17:10
bauzasyeah17:10
sean-k-mooneywell or a vey new extenion i think17:11
artomsean-k-mooney, not based on https://docs.openstack.org/api-ref/network/v2/index.html?expanded=update-port-detail,show-port-details-detail#update-port17:11
sean-k-mooneyill check17:11
bauzasand that's exactly why I think that nova shouldn't deal with TLDs in their server hostnames17:11
artomLike, the original BZ we have is because Neutron exploded17:11
artomNot Designate17:11
bauzasbut I can recognize that the dash conversion seems kinda more acceptable to users17:11
*** links has joined #openstack-nova17:11
bauzasanyway, /me needs to bail out17:12
bauzas++17:12
* gibi bails out too17:13
gibio/17:13
stephenfino/17:13
sean-k-mooneyartom: im pretty sure nova used to explode at one point too with some of the shared nova net code17:13
sean-k-mooneyartom: the orginal bz was in my dev cloud in intel17:14
artomsean-k-mooney, bz or launchpad bug?17:14
sean-k-mooneyit was filed by someone on my team after i told them it was never supported17:14
sean-k-mooneysorry the launch pad bug17:14
artomWell, nova-network doesn't exist anymore, so... :)17:14
sean-k-mooneyi think it used to explode somewhere in https://github.com/openstack/nova/blob/stable/train/nova/network/minidns.py17:16
sean-k-mooneythis si where we are current failing right https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L678-L68617:17
artomsean-k-mooney, no, based on https://bugzilla.redhat.com/show_bug.cgi?id=1872314 we actually make the request to Neutron17:20
openstackbugzilla.redhat.com bug 1872314 in openstack-nova "[OSP 16.1] Can't launch instance if name ends with a number" [Medium,New] - Assigned to nova-maint17:20
artomAnd bubble up the BadRequest it returns17:20
sean-k-mooneyartom: oh i know17:20
sean-k-mooneybut back in like havana i think it broken in nova it also broke in neutorn17:21
sean-k-mooneyat somepoint neutron started allowing the fqdn17:21
sean-k-mooneybut it was never done intentually at least form a nova point of view17:21
artomSo https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1138 would be where our request to Neutron explodes17:22
artomAnd https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1494 is where we populate the dns_name17:23
artomI'm saying don't actually do that17:23
artomAnd let the users do a port update manually with the hostname of their chosing, not one that Nova has derived from the VM name17:23
artomAnd *then* if Neutron isn't happy, it really is user error and WONTFIX :)17:25
*** sapd1_x has quit IRC17:25
sean-k-mooneyartom: that wont fix the fact the contend ot the metadata api is not what you expect17:27
artomsean-k-mooney, eh?17:28
sean-k-mooneylook at http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019137.html17:28
sean-k-mooneywith a default designate domain of cloud.seanmooney.info adn default dhcp_domain of novalocal17:29
sean-k-mooneyfi you create a server called test-dns.invalid.dns17:29
*** tosky has quit IRC17:29
sean-k-mooneyyou will have "test-dns.invalid.dns.novalocal" "test-dns.invalid.dns.cloud.seanmooney.info" "test-dns.cloud.seanmooney.info" and test-dns for hostnames/fqdns17:30
sean-k-mooneybut you will never have test-dns.invalid.dns which was the fqdn you uses as the servername17:31
artomsean-k-mooney, I feel like we're conflating many problems into 117:31
sean-k-mooneynot really17:31
sean-k-mooneyif we allow FQDNs we shoudl support them consitently17:31
sean-k-mooneyright now you will get 4 possible name for the server none of them will be the one you passed in unless17:32
sean-k-mooneyyou explcity configure [DEFAULT]/dhcp_domain="" and do not use a default designate domain17:32
artomsean-k-mooney, right, this falls in the wider "our DNS interoperation is crap" problem17:33
artomOn which my grip is not great17:34
artomBut feels like fixing that would involve a new microversion with a separate hostname and/or fqdn parameter17:34
artomAt the tightest possible scope, this bug is caused by Nova deriving a `dns_name` from the display name, and passing it to Neutron, which can then refuse it, despite the display name being perfectly valid17:35
sean-k-mooneyif you want real fun read https://review.opendev.org/c/openstack/neutron-specs/+/88623/16/specs/liberty/internal-dns-resolution.rst17:36
artomIf I want real fun I'll go do some drugs17:36
sean-k-mooneyhttps://bugs.launchpad.net/neutron/+bug/145903017:36
openstackLaunchpad bug 1459030 in neutron "Allow nova to feed its hostname to Neutron for eventually integration with Designate" [Medium,Fix released] - Assigned to Miguel Lavalle (minsel)17:36
*** links has quit IRC17:38
artomI wonder if anyone's asked PSI whether they actually need the DNS integration :P17:38
sean-k-mooneyits quite useful17:38
sean-k-mooneyits why i use it17:38
*** dtantsur is now known as dtantsur|afk17:39
sean-k-mooneybut its also not well maintained17:39
sean-k-mooneyor rather a very small team17:39
sean-k-mooneyno that i have moved my dns to cloudflare most of my issue with updating dns are fixed17:40
sean-k-mooneygodda's ui/api was horrible17:40
sean-k-mooneyby the way aparet form the backportable solution stephenfin are we also going to add an fqdn or domain field and a new microverion to the server create17:44
*** k_mouza has quit IRC17:53
*** tesseract has quit IRC17:57
*** k_mouza has joined #openstack-nova17:59
*** jangutter has joined #openstack-nova18:00
*** derekh has quit IRC18:01
*** k_mouza has quit IRC18:02
*** k_mouza has joined #openstack-nova18:02
*** jangutter_ has quit IRC18:03
*** xek_ has quit IRC18:06
*** k_mouza has quit IRC18:06
*** jangutter has quit IRC18:21
*** jangutter has joined #openstack-nova18:22
*** jangutter has quit IRC18:25
*** jangutter has joined #openstack-nova18:26
*** andrewbonney has quit IRC18:29
*** artom has quit IRC18:37
*** artom has joined #openstack-nova18:37
*** jangutter has quit IRC18:39
*** jangutter has joined #openstack-nova18:40
*** jangutter has quit IRC18:41
*** jangutter_ has joined #openstack-nova18:41
*** jangutter_ has quit IRC18:45
*** jangutter has joined #openstack-nova18:45
*** k_mouza has joined #openstack-nova18:48
*** hamalq has joined #openstack-nova18:58
*** belmoreira has quit IRC19:11
*** k_mouza has quit IRC19:13
*** vishalmanchanda has quit IRC19:22
*** luksky has joined #openstack-nova19:42
*** rcernin has joined #openstack-nova19:57
*** jmlowe has quit IRC19:58
*** jmlowe has joined #openstack-nova19:59
*** k_mouza has joined #openstack-nova20:05
*** k_mouza has quit IRC20:07
*** rcernin has quit IRC20:23
*** xek_ has joined #openstack-nova20:23
*** waverider has joined #openstack-nova20:48
*** tosky has joined #openstack-nova20:55
*** rcernin has joined #openstack-nova20:58
*** songwenping__ has joined #openstack-nova21:02
*** rcernin has quit IRC21:03
*** songwenping_ has quit IRC21:06
*** openstackgerrit has quit IRC21:08
*** purplerbot has quit IRC21:24
*** rcernin has joined #openstack-nova21:29
*** purplerbot has joined #openstack-nova21:33
*** purplerbot has quit IRC21:35
*** purplerbot has joined #openstack-nova21:41
*** ociuhandu has joined #openstack-nova21:46
*** waverider has quit IRC21:56
*** waverider has joined #openstack-nova21:56
*** nweinber has quit IRC22:06
*** xek_ has quit IRC22:20
*** ociuhandu has quit IRC22:24
*** ociuhandu has joined #openstack-nova22:25
*** ociuhandu has quit IRC22:30
*** ociuhandu has joined #openstack-nova22:55
*** luksky has quit IRC23:03
*** tkajinam has quit IRC23:03
*** ociuhandu has quit IRC23:04
*** tkajinam has joined #openstack-nova23:04
*** openstackgerrit has joined #openstack-nova23:10
openstackgerritMamduh proposed openstack/os-vif stable/ussuri: Refactor code of linux_net to more cleaner and increase performace  https://review.opendev.org/c/openstack/os-vif/+/76541923:11
*** bnemec has quit IRC23:22
*** ociuhandu has joined #openstack-nova23:22
*** ociuhandu has quit IRC23:27
*** songwenping_ has joined #openstack-nova23:30
*** songwenping__ has quit IRC23:33

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