sean-k-mooney | dcapone2004: what exactly are you trying to enable | 00:03 |
---|---|---|
sean-k-mooney | dcapone2004: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 way | 00:03 |
sean-k-mooney | <feature policy="disable" name="hypervisor"/> | 00:04 |
sean-k-mooney | <feature policy="require" name="vmx"/> | 00:04 |
sean-k-mooney | so do you jsut want vmx or do you also want to disabel the hyperviror feature flag | 00:04 |
sean-k-mooney | you can do both already | 00:04 |
sean-k-mooney | vmx will be present if you use host-model or host-passthough for the cpu_mode in the libvirt section of the nova.conf | 00:05 |
sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cpu_mode | 00:06 |
sean-k-mooney | if 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_flags | 00:06 |
sean-k-mooney | for <feature policy="disable" name="hypervisor"/> | 00:07 |
sean-k-mooney | you need to add either hw:hide_hypervisor_id=true in the flavor extra specs or img_hide_hypervisor_id in the image properties | 00:08 |
sean-k-mooney | dcapone2004:^ | 00:08 |
*** noonedeadpunk has quit IRC | 00:08 | |
sean-k-mooney | dcapone2004: that will allow you to set those two flags in the libvirt xml | 00:09 |
*** noonedeadpunk has joined #openstack-nova | 00:10 | |
sean-k-mooney | dcapone2004: note that adding vmx will only work if you actully have nested virt enabled in the host kernel kvm module parmaters | 00:10 |
sean-k-mooney | in this case the intel_kvm module | 00:10 |
sean-k-mooney | it 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 case | 00:11 |
sean-k-mooney | dcapone2004: hopefully that helps | 00:11 |
*** hamalq_ has joined #openstack-nova | 00:15 | |
*** tosky has quit IRC | 00:18 | |
*** hamalq has quit IRC | 00:19 | |
dcapone2004 | sean I already tried all you suggested | 00:20 |
dcapone2004 | it doesn't work | 00:21 |
dcapone2004 | the hide_hyperivsor_id=true property passes a kvm=no to qemu | 00:21 |
*** hamalq_ has quit IRC | 00:21 | |
dcapone2004 | instead of hypervisor=no, I have nested virtualization enabled and it works when my nested hypervisor is Linux/KVM | 00:21 |
*** mlavalle has quit IRC | 00:22 | |
dcapone2004 | but 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 found | 00:23 |
dcapone2004 | I am passing the vmx flag to the VM with nova.conf and the cpu_model_extra_flags configuration | 00:24 |
*** hamalq has joined #openstack-nova | 00:25 | |
*** cgoncalves has quit IRC | 00:28 | |
*** ociuhandu has joined #openstack-nova | 00:31 | |
sean-k-mooney | what version of openstack are you using and what version of the linux kernel are you using | 00:31 |
sean-k-mooney | dcapone2004: hide_hyperivsor_id=true should not disable kvm | 00:32 |
*** xek has quit IRC | 00:33 | |
sean-k-mooney | oh i see what its doing | 00:34 |
sean-k-mooney | it will produce something like this by default http://paste.openstack.org/show/800674/ | 00:35 |
*** ociuhandu has quit IRC | 00:35 | |
sean-k-mooney | vmx=on,pdcm=on,pcid=on,hypervisor=on, with kvm=off | 00:35 |
dcapone2004 | ussuri, kernel 4.10, centos 8 standard kernel | 00:36 |
sean-k-mooney | but i think that changes if you set the image type to windows | 00:36 |
*** gyee has quit IRC | 00:36 | |
sean-k-mooney | ussuri has the hyperv change i was wondering about | 00:36 |
dcapone2004 | so, I don't have as many flags as you enabled | 00:37 |
dcapone2004 | what happens on mine is that NO hypervisor option is passed | 00:37 |
sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5362-L5387 | 00:37 |
dcapone2004 | and I think I need it to explicitly pass no based on that "fix" article I read | 00:37 |
sean-k-mooney | this is the addtional logic for windows guest | 00:37 |
sean-k-mooney | dcapone2004: im using cpu_mode=host-passthough | 00:38 |
sean-k-mooney | so its adding all of my virutalisable cpu flags by default | 00:38 |
sean-k-mooney | dcapone2004: can you check if you have os_type=windows in the image metadata | 00:38 |
sean-k-mooney | dcapone2004: if not that might fix it | 00:39 |
dcapone2004 | yeah, 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 all | 00:39 |
dcapone2004 | I then use flavor traits to expose higher CPU models to VMs when needed based on the flavor | 00:39 |
dcapone2004 | aka, AVX2 to expose Haswell and have the scheduler route the VM to a node that has Haswell or better CPUs | 00:40 |
sean-k-mooney | traits wont make the cpu feature avaiable just so you are aware | 00:40 |
sean-k-mooney | i assume you are using the recently added support to list multiple cpu models | 00:40 |
dcapone2004 | correct | 00:40 |
sean-k-mooney | ya that should work | 00:41 |
dcapone2004 | I 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 defined | 00:41 |
sean-k-mooney | custom will enable everytin in cpu_map yes | 00:42 |
dcapone2004 | the VMs recognize the CPU as Haswell vs IvyBridge when booted when I use the flavor when I define AVX2 as required | 00:42 |
dcapone2004 | ok, that is the behavior I thought I was receiving | 00:42 |
sean-k-mooney | yes we have logic to select the cpu model form the list that includes the feature you requested | 00:43 |
sean-k-mooney | we test them in order i belive and use the first that has all requested features | 00:43 |
dcapone2004 | correct that is the behavior I see and expected | 00:43 |
sean-k-mooney | well that was the behavior we intended but that does not mean we dont have a bug :) | 00:43 |
sean-k-mooney | nice to know it works | 00:44 |
sean-k-mooney | so in your case | 00:44 |
sean-k-mooney | i think we need to extend this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5390-L5392 | 00:44 |
dcapone2004 | only 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-mooney | to add hypervior=off | 00:44 |
sean-k-mooney | dcapone2004: i may have missed it but did you check if you have os-type=windows in the image | 00:45 |
*** waverider has quit IRC | 00:45 | |
sean-k-mooney | so that https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5384-L5386 runs | 00:45 |
dcapone2004 | let me double check, pretty sure our windows images have a bunch of options set according to the docs recommendations but let me verify | 00:45 |
dcapone2004 | oddly enough i don't....we have os_distro set to win2k19 which is what i think was in the docs | 00:46 |
dcapone2004 | let me try adding that additional property and see what happens | 00:47 |
*** gregwork has quit IRC | 00:48 | |
dcapone2004 | so in Horizon, os_type shows up under the XenAPI Driver Options....I think that is why we did not set it | 00:49 |
dcapone2004 | as I/we thought it was a Xen specific property | 00:49 |
sean-k-mooney | that code was added to trick nvidia dirvers into tinking it its runing on a physical host | 00:49 |
sean-k-mooney | hopefully it will help | 00:50 |
sean-k-mooney | on the horizon front | 00:50 |
sean-k-mooney | that is actully managed via glance metadefs | 00:50 |
dcapone2004 | am 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-mooney | so those should likely be updated | 00:50 |
dcapone2004 | but 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") and | 00:54 |
sean-k-mooney | no its this one https://github.com/openstack/glance/blob/45749c30c1c02375a85eb17be0ccd983c695953f/etc/metadefs/compute-libvirt-image.json#L97-L105 | 00:54 |
dcapone2004 | That code calls a different hyperV specific function based on this property so I am hoping it is a winner :-)... will let you know shortly | 00:54 |
dcapone2004 | yeah that option in horizon is listed under XenApi in Horizon for some reason | 00:55 |
sean-k-mooney | weird | 00:55 |
sean-k-mooney | ok 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-mooney | we shoudl be able to add hypervior=no if libvirt support it | 00:55 |
sean-k-mooney | which it shoudl | 00:56 |
sean-k-mooney | but i would hope its not required with the existing code | 00:56 |
dcapone2004 | ok...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 property | 00:56 |
dcapone2004 | this is what horizon says about the property...OS Type (os_type) | 00:57 |
dcapone2004 | and it limits the injected host name to less than 16 characters. | 00:57 |
sean-k-mooney | what i have a ussuri deployment too let me check that wrong | 00:58 |
dcapone2004 | makes it seem as though the property is very Xen specific....your code clearly shows it is used in libvirt as well | 00:58 |
sean-k-mooney | ya so its not under the libvirt driver options for image section and is in zen with differet text | 00:59 |
sean-k-mooney | oh https://github.com/openstack/glance/commit/e1fe3024bb2482853130fac0be87e6a6a44e610e | 01:00 |
dcapone2004 | :-) someone else already noticed it | 01:01 |
dcapone2004 | so I just booted the VM | 01:01 |
sean-k-mooney | dcapone2004: stephenfin fixed it when he deleted the xenapi driver | 01:02 |
sean-k-mooney | but that is part of wallaby | 01:03 |
sean-k-mooney | not ussuri | 01:03 |
sean-k-mooney | dcapone2004: you can fix that in your current deployment via the glance api | 01:03 |
dcapone2004 | didn'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 help | 01:03 |
sean-k-mooney | you can update the metadata defs via the api | 01:03 |
dcapone2004 | yeah i can just update our internal MOPs | 01:03 |
sean-k-mooney | dcapone2004: yep os_type is used to enable the hyperv enlightenments too which enable the hyperv optimisations | 01:04 |
sean-k-mooney | it should improve you guest performance | 01:04 |
dcapone2004 | admittedly I don't overly care about nested VM performance....we basically use nested VM mostly to lab out potential deployments for customers | 01:05 |
dcapone2004 | but good to know anyway | 01:05 |
sean-k-mooney | dcapone2004: well it will impre the first level vm performance too and it shoudl reduce power use when the vms are ideling | 01:06 |
*** cgoncalves has joined #openstack-nova | 01:06 | |
dcapone2004 | ok, 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 KVM | 01:07 |
sean-k-mooney | that is what i was expecting hyperv on kvm | 01:08 |
sean-k-mooney | window has special kernel code for runing on hyperv and kvm support some of the hyperv feature | 01:09 |
sean-k-mooney | https://libvirt.org/formatdomain.html#hypervisor-features has a table ot the hyperv feature | 01:09 |
dcapone2004 | i see | 01:09 |
sean-k-mooney | although we dont support enabling most of them basically because no one has asked or done it | 01:10 |
dcapone2004 | unfortunately 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 it | 01:11 |
sean-k-mooney | so you could manally edit the xml and add that | 01:12 |
dcapone2004 | but sinc eyou mentioned performance improvements....is there anyway to add those flags to already existing, deployed/modified VMs? | 01:12 |
sean-k-mooney | then use libvirt to restart the vm | 01:12 |
sean-k-mooney | not openstack | 01:12 |
sean-k-mooney | dcapone2004: no not without a db update | 01:12 |
dcapone2004 | might try that as well first | 01:13 |
dcapone2004 | that is what I thought...db update and hard reboot? | 01:13 |
sean-k-mooney | if 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 table | 01:13 |
sean-k-mooney | dcapone2004: yes db update and hard reboot | 01:13 |
dcapone2004 | alright, 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-mooney | if 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#L5393 | 01:15 |
sean-k-mooney | as a bug fix | 01:15 |
sean-k-mooney | depending on if its jut for hyperv or for hyperv and kvm | 01:15 |
sean-k-mooney | sorry windows or windows and linux | 01:15 |
dcapone2004 | I 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 sure | 01:16 |
sean-k-mooney | kvm/hyperv does not matter in this case | 01:16 |
dcapone2004 | linux nested virtualization works without issue | 01:16 |
sean-k-mooney | yep | 01:16 |
dcapone2004 | I've used it on this same cluster and with the same flavor without issue | 01:16 |
sean-k-mooney | i use it every day | 01:16 |
sean-k-mooney | i do all my openstack dev on my home openstack cluster | 01:17 |
sean-k-mooney | with nested virt and hypervior hiding | 01:17 |
dcapone2004 | 1 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-mooney | oh you dont edit the xmls | 01:20 |
sean-k-mooney | i use kolla | 01:20 |
sean-k-mooney | you need to docker exec into nova_libvirt | 01:20 |
sean-k-mooney | e.g. docker exec -it nova_libvirt bash | 01:20 |
sean-k-mooney | then do virsh edit <vm id> | 01:20 |
sean-k-mooney | if you look at the extended atibute in the server show as an admin you can get teh libvirt domain name | 01:21 |
sean-k-mooney | otherwise you just need to find the one with the uuid that matches | 01:21 |
dcapone2004 | ok, I thought you said, "so you could manally edit the xml and add that" "then use libvirt to restart the vm | 01:23 |
sean-k-mooney | ah yes when you do virsh edit | 01:24 |
sean-k-mooney | it will open the xml in an editor for you | 01:24 |
sean-k-mooney | that is what i ment | 01:24 |
dcapone2004 | got it | 01:24 |
sean-k-mooney | it will also validate it with libvirt and only allow it to save if the edit is valid | 01:24 |
sean-k-mooney | anywyay its 01:25 here so im heading to bed | 01:25 |
sean-k-mooney | if that works defintly file the bug and we can see if we can fix this | 01:25 |
sean-k-mooney | the nova meeting is tomorrow too if you wanted to bring it up in open dicusstion | 01:26 |
sean-k-mooney | if you can confirm either way if setting that option fixes your issue let me know an i can bring it up if you cant attend | 01:26 |
dcapone2004 | will do | 01:27 |
dcapone2004 | just ran virsh reboot 35, so we shall see | 01:27 |
sean-k-mooney | you might need to stop the domin and start it by the way | 01:28 |
sean-k-mooney | i dont rembere if reboot does a soft reboot or hard | 01:28 |
dcapone2004 | was going to iterate through all possible methods before quitting :-) .... get some rest...your assistant has been much appreciated | 01:28 |
sean-k-mooney | soft being a qemu monitor command to tell the os to reboot without restarting the qemu process | 01:28 |
sean-k-mooney | o/ | 01:29 |
*** rcernin has quit IRC | 01:58 | |
*** rcernin has joined #openstack-nova | 01:58 | |
*** brinzhang0 has joined #openstack-nova | 02:01 | |
*** brinzhang_ has quit IRC | 02:04 | |
*** Jorhson has quit IRC | 02:04 | |
*** hemanth_n has joined #openstack-nova | 02:29 | |
*** hamalq has quit IRC | 02:32 | |
*** jdillaman has quit IRC | 02:35 | |
*** Yumeng has joined #openstack-nova | 02:37 | |
*** dcapone2004 has quit IRC | 02:41 | |
*** rcernin has quit IRC | 03:06 | |
*** Yumeng has quit IRC | 03:11 | |
openstackgerrit | chengsheng proposed openstack/nova master: CPU selection with hypervisor consideration https://review.opendev.org/c/openstack/nova/+/762330 | 03:17 |
*** brinzhang0 has quit IRC | 03:20 | |
*** rcernin has joined #openstack-nova | 03:26 | |
*** xinranwang has joined #openstack-nova | 03:29 | |
*** brinzhang has joined #openstack-nova | 03:29 | |
*** rcernin has quit IRC | 03:30 | |
*** rcernin has joined #openstack-nova | 03:30 | |
*** sapd1_x has joined #openstack-nova | 03:33 | |
*** mkrai has joined #openstack-nova | 03:43 | |
*** psachin has joined #openstack-nova | 03:59 | |
*** brinzhang_ has joined #openstack-nova | 04:04 | |
*** brinzhang has quit IRC | 04:07 | |
*** lemko has quit IRC | 04:25 | |
*** lemko has joined #openstack-nova | 04:25 | |
*** k_mouza has joined #openstack-nova | 04:55 | |
*** nweinber has joined #openstack-nova | 04:57 | |
*** k_mouza has quit IRC | 05:00 | |
*** nweinber has quit IRC | 05:04 | |
*** ianw is now known as ianw_pto | 05:24 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #openstack-nova | 05:33 | |
*** sapd1_x has quit IRC | 05:40 | |
openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | 05:51 |
*** songwenping__ has joined #openstack-nova | 06:00 | |
*** songwenping_ has quit IRC | 06:03 | |
*** chengsheng1 is now known as chengsheng | 06: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, thanks | 06:32 |
openstackgerrit | Xinran WANG proposed openstack/nova-specs master: Smart-nic Support Specification https://review.opendev.org/c/openstack/nova-specs/+/742785 | 07:05 |
*** mkrai has quit IRC | 07:23 | |
*** mkrai_ has joined #openstack-nova | 07:23 | |
*** rpittau|afk is now known as rpittau | 07:27 | |
*** sapd1_x has joined #openstack-nova | 07:29 | |
*** dklyle has quit IRC | 07:31 | |
*** songwenping_ has joined #openstack-nova | 07:37 | |
*** songwenping__ has quit IRC | 07:41 | |
*** slaweq has joined #openstack-nova | 07:41 | |
*** mkrai_ has quit IRC | 07:42 | |
*** lpetrut has joined #openstack-nova | 07:46 | |
*** belmoreira has joined #openstack-nova | 07:50 | |
openstackgerrit | Wenping Song proposed openstack/nova master: Nova supports password encrypted VNC https://review.opendev.org/c/openstack/nova/+/622336 | 08:07 |
*** tesseract has joined #openstack-nova | 08:18 | |
*** luksky has joined #openstack-nova | 08:22 | |
*** JamesBen_ has joined #openstack-nova | 08:23 | |
*** JamesBenson has quit IRC | 08:23 | |
*** Jorhson has joined #openstack-nova | 08:24 | |
*** mkrai has joined #openstack-nova | 08:30 | |
*** JamesBen_ has quit IRC | 08:32 | |
*** JamesBenson has joined #openstack-nova | 08:33 | |
*** tosky has joined #openstack-nova | 08:34 | |
bauzas | good morning Nova | 08:38 |
*** redrobot has quit IRC | 08:41 | |
*** rcernin has quit IRC | 08:46 | |
*** vishalmanchanda has joined #openstack-nova | 08:47 | |
gibi | good morning bauzas | 08:47 |
bauzas | :-) | 08:49 |
* bauzas just depiling a shit ton of emails just for one day off | 08:49 | |
* bauzas wonders what happened in the world | 08:49 | |
*** andrewbonney has joined #openstack-nova | 08:49 | |
openstackgerrit | Balazs Gibizer proposed openstack/nova master: Separate out the migration tests https://review.opendev.org/c/openstack/nova/+/765300 | 08:59 |
*** rcernin has joined #openstack-nova | 09:00 | |
*** zzzeek has quit IRC | 09:02 | |
*** rcernin has quit IRC | 09:04 | |
*** zzzeek has joined #openstack-nova | 09:04 | |
elod | good morning :) | 09:10 |
elod | bauzas: if you will have time can you have another look at this patch? https://review.opendev.org/c/openstack/nova/+/764432 | 09:11 |
*** derekh has joined #openstack-nova | 09:11 | |
elod | this would unblock the gate on stable/victoria | 09:11 |
bauzas | elod: for sure, I just want to progress on the routed networks impl, but I can do other urgent stuff | 09:11 |
bauzas | a-ha, good reason then | 09:11 |
bauzas | elod: and fwiw, lyarwood is on PTO those 2 days | 09:12 |
bauzas | damn, those RH folks who are always on vacation... | 09:12 |
elod | this is lyarwood's commit so it does not really matter ;) | 09:12 |
elod | actually, only a commit message change happened since your last +1 (and a successful zuul run \o/) | 09:13 |
*** ociuhandu has joined #openstack-nova | 09:42 | |
*** xinranwang has quit IRC | 09:45 | |
elod | bauzas: thx! \o/ (and sorry for the interrupt o:)) | 09:46 |
bauzas | np | 09:47 |
*** k_mouza has joined #openstack-nova | 09:49 | |
*** luksky has quit IRC | 09:51 | |
*** xek has joined #openstack-nova | 09:55 | |
*** ociuhandu has quit IRC | 09:57 | |
*** jangutter_ has joined #openstack-nova | 09:59 | |
*** mkrai has quit IRC | 10:00 | |
*** ociuhandu has joined #openstack-nova | 10:01 | |
*** jangutter has quit IRC | 10:02 | |
*** ociuhandu has quit IRC | 10:19 | |
openstackgerrit | Lucian Petrut proposed openstack/nova master: hyper-v rbd volume support https://review.opendev.org/c/openstack/nova/+/763550 | 10:24 |
*** dtantsur|afk is now known as dtantsur | 10:26 | |
*** mkrai has joined #openstack-nova | 10:31 | |
*** ociuhandu has joined #openstack-nova | 10:41 | |
openstackgerrit | Brin Zhang proposed openstack/nova master: Replace all_tenants with all_projects https://review.opendev.org/c/openstack/nova/+/765311 | 11:05 |
*** sapd1 has quit IRC | 11:17 | |
*** zzzeek has quit IRC | 11:17 | |
*** zzzeek has joined #openstack-nova | 11:19 | |
*** luksky has joined #openstack-nova | 11:22 | |
chengsheng | kashyap: I have updated: https://review.opendev.org/c/openstack/nova/+/762330/ | 11:27 |
*** sapd1_x has quit IRC | 11:27 | |
kashyap | chengsheng: 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-nova | 11:28 | |
gibi | kashyap: thanks for the heads up, have a nice time off! | 11:29 |
kashyap | gibi: Thank you; lots of non-computer reading :-) | 11:29 |
gibi | nice! | 11:30 |
*** ociuhandu has quit IRC | 11:31 | |
*** sapd1_x has joined #openstack-nova | 11:33 | |
*** spatel has joined #openstack-nova | 11:34 | |
*** sapd1_x has quit IRC | 11:38 | |
*** spatel has quit IRC | 11:39 | |
*** k_mouza has quit IRC | 11:42 | |
*** psachin has quit IRC | 11:45 | |
*** k_mouza has joined #openstack-nova | 11: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 suggestions | 11:47 |
openstackgerrit | Brin Zhang proposed openstack/nova master: WIP: Replace tenants* with projects* in List Servers's policy https://review.opendev.org/c/openstack/nova/+/765315 | 11:48 |
brinzhang_ | gmann: this is the replace role name patch https://review.opendev.org/c/openstack/nova/+/765315 | 11:48 |
brinzhang_ | gmann: thanks | 11: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/+/764292 | 11:52 |
sean-k-mooney | brinzhang_: im not sure we have many patches tat are changing the api at present, i i would hope there wont be many conflicts | 12:00 |
sean-k-mooney | but yes ill try to review later today | 12: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.html | 12:02 |
brinzhang_ | whatever, there is a microversion to be bound, it's easy to do ^^ | 12:03 |
sean-k-mooney | yep but how many of those are close to merging | 12:03 |
sean-k-mooney | what im not sure about is what to do with the follow up patches | 12:04 |
brinzhang_ | I thinks this one https://review.opendev.org/c/openstack/nova/+/764292 | 12:04 |
sean-k-mooney | it kind of feels like you shoudl be doing this in one big patch | 12:04 |
sean-k-mooney | if its 3 it feels like you need 3 microverions | 12:05 |
brinzhang_ | no, I wont to do this in one patch | 12:05 |
brinzhang_ | it's not easy to review, and not easy to manage by me | 12:05 |
sean-k-mooney | right 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 here | 12:06 |
brinzhang_ | sean-k-mooney: i know what you are concern, I try to complete this in Wallaby release | 12:07 |
sean-k-mooney | i think the best way forward is too have multiple patches but only merge them when all patches are ready | 12:07 |
brinzhang_ | but might as your concern, may Icannt complete ^^ | 12:07 |
sean-k-mooney | gibi: gmann any toughts on ^ | 12:08 |
sean-k-mooney | gibi: gmann the remove-tenant-id changes are really too big to have in one patch | 12: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 patches | 12:09 |
sean-k-mooney | gibi: gmann but we also dont want multiple micorverions here | 12:09 |
sean-k-mooney | brinzhang_: in anycase ill try and review it today | 12:10 |
brinzhang_ | sean-k-mooney: thanks | 12:11 |
sean-k-mooney | brinzhang_: are there more patches in that serise by the way or just the 3 your have pushed | 12:12 |
brinzhang_ | yeah, I just pushed List Servers APIs changes | 12: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 nothing | 12:13 |
sean-k-mooney | well it was more if im reviewing it ill try and review all the patches at the same time | 12:13 |
sean-k-mooney | https://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 it | 12:14 |
sean-k-mooney | they dont all need to be there | 12:14 |
sean-k-mooney | just wanted to make sure that had all the patches that were currently avaiable | 12:14 |
brinzhang_ | There a two patches are avaliable, except the policy changes patch, that I want to get help from gmann | 12:15 |
brinzhang_ | after complete the policy changes, the server list apis change is ok for this microversion, IMO, yes | 12:16 |
*** mgariepy has quit IRC | 12:20 | |
gibi | sean-k-mooney, brinzhang_: what if we merge the changes gradually but not expose the new microversion until the last patch? | 12:22 |
gibi | what 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#248 | 12:22 |
sean-k-mooney | gibi: 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 merges | 12: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 microversion | 12:24 |
gibi | sean-k-mooney: why do we need to disable the new codepaths? Not having the microversion 88 published makes those new codepath unreachable | 12:25 |
brinzhang_ | it's my opinion | 12:25 |
sean-k-mooney | gibi: oh ok in that case yep that should work | 12:25 |
gibi | brinzhang_: you do have a microversion it just not available for the client to request it | 12:25 |
sean-k-mooney | unless a different api change takes the microversion | 12:25 |
gibi | sean-k-mooney: yeah, another api change can break this | 12:26 |
gibi | hm hm | 12:26 |
*** ociuhandu_ has quit IRC | 12:26 | |
gibi | so if we want to go this direction then we need to make the api patches serialized | 12:26 |
gibi | right now | 12:27 |
gibi | not just at the merge point | 12:27 |
*** ociuhandu has joined #openstack-nova | 12:27 | |
sean-k-mooney | basically allocate a micro version to them | 12:27 |
sean-k-mooney | could we do that with placeholder microverions? | 12:27 |
sean-k-mooney | and change the meaning of the microversion when it merges | 12:28 |
sean-k-mooney | that a bit of hack | 12:28 |
sean-k-mooney | bug kind of like the palceholder db migrations | 12:28 |
gibi | hm | 12:28 |
sean-k-mooney | allocate 2.88 2.89 and 2.90 to the 3 specs in flight and make them all the same as 2.87 for now | 12:29 |
brinzhang_ | as your concern above, if we placeholder microversion, and I am not completed this in this release, it will be a bad news | 12:29 |
sean-k-mooney | that still not great | 12:29 |
gibi | how far the other two patches from merge? | 12:29 |
gibi | if we could merge them quickly then this problem is solved for the cycle | 12:29 |
gibi | (assuming no new spec proposed api changes for wallaby) | 12:30 |
gibi | e.g. we allocating the microversion by merging the two small feature first | 12:30 |
brinzhang_ | there is a noVNC spec reqired a microversion also in my list | 12:30 |
gibi | so the novnc password, and the hypervisor api modernization are the in flight api changes besides the tenat_id one | 12:31 |
brinzhang_ | yes, if there are all quickly completed fastly, it would be better. | 12:32 |
gibi | I 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/+/622336 | 12:33 |
sean-k-mooney | well there is also https://review.opendev.org/c/openstack/nova/+/749505 | 12:34 |
sean-k-mooney | that one proably shoudl be merged first for 2.88 | 12:35 |
sean-k-mooney | although it could be after | 12:35 |
sean-k-mooney | we do wnat to get that done sooner rather then later however | 12:35 |
sean-k-mooney | stephenfin: whats your plance regardign fixing all the http status codes ^ | 12:36 |
stephenfin | I don't really have one. It sounds very low priority. I might do it if I get some other stuff landed first | 12:37 |
*** ociuhandu has quit IRC | 12:37 | |
sean-k-mooney | stephenfin: looks like you havent worked on it in 3 months will you be updating that soon or in the new year | 12:37 |
sean-k-mooney | ok so sound like we shoudl not wait for that one so | 12:37 |
stephenfin | no, definitely not | 12:37 |
gibi | stephenfin: thanks for the info | 12:38 |
stephenfin | do I note have the hypervisor one up? | 12:39 |
stephenfin | not | 12:39 |
* stephenfin checks | 12:39 | |
sean-k-mooney | you do i think | 12:39 |
zigo | Hi. When building Nova 22.0.1, I get 1787 unit test failures like this one: http://paste.openstack.org/show/800690/ | 12:39 |
zigo | while nova 22.0.0 does build without any issue. | 12:39 |
zigo | Is this a known problem? | 12:39 |
gibi | I don't find it here https://review.opendev.org/q/topic:%22bp%252Fmodernize-os-hypervisors-api%22+(status:open%20OR%20status:merged) | 12:39 |
stephenfin | whoops, wrong topic | 12:39 |
stephenfin | https://review.opendev.org/q/topic:%22bp%252Fdeprecate-os-hypervisors%22+(status:open%20OR%20status:merged) | 12:39 |
* stephenfin updates | 12:40 | |
brinzhang_ | so the noVNC that we can promote priority, maybe it's the fast one that closes to merge | 12:40 |
stephenfin | gibi: fixed | 12:40 |
sean-k-mooney | brinzhang_: gibi have we been doing runway this cycle | 12:40 |
zigo | If nobody knows, then I can probably bisect the 22.0.0 to 22.0.1 patches ... | 12:41 |
gibi | zigo: give me a se | 12:41 |
gibi | c | 12:41 |
gibi | stephenfin: thanks | 12:41 |
sean-k-mooney | not really | 12:41 |
sean-k-mooney | ok can we add the password one to https://etherpad.opendev.org/p/nova-runways-wallaby | 12:41 |
gibi | sean-k-mooney: the etherpad is up there it is just only brinzhang_ who put thing is nit | 12:42 |
gibi | thing in it | 12: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 runway | 12:42 |
*** artom has quit IRC | 12:44 | |
gibi | zigo: looked at the diff but nothing popped out, so I guess it is bisect time. | 12:44 |
zigo | gibi: Thanks for looking, I'll try then. | 12:45 |
gibi | zigo: let me know what you found | 12:45 |
sean-k-mooney | yep so if we do noVNC then os-hyperviors then teants change? | 12:45 |
sean-k-mooney | that shoudl avoid it assumeing stephens paatch is already ready for review otherwise move os-hyperviors to 2.90 | 12:46 |
gibi | sean-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 commitment | 12:48 |
brinzhang_ | gibi: agree | 12:49 |
*** vinay_m has joined #openstack-nova | 12:49 | |
brinzhang_ | if I cannot complete it in Wallaby release, the 2.88 just suit for part of apis | 12:49 |
brinzhang_ | but if wait for all patches submited, and ready to review, there will be a heavy work | 12:51 |
gibi | there is no easy solution | 12:52 |
sean-k-mooney | brinzhang_: merging it would block all other api work however so really we need ti to be close before we merge the first patch | 12:52 |
vinay_m | hello 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 fine | 12:52 |
vinay_m | not able to figure out what could be issue | 12:53 |
gibi | brinzhang_: 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-mooney | vinay_m: did you look at the console output to see if cloud init reran and updated the networking correctly | 12:53 |
zigo | It'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 |
gibi | zigo: 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 gate | 12:54 |
vinay_m | sean-k-mooney: yeah tried , but no log from this vm | 12:54 |
sean-k-mooney | vinay_m: if you had hardcoded macs or static ips the vm might just nto be getting the right ip | 12:54 |
zigo | gibi: I'll bisect and find out. | 12:54 |
gibi | zigo: anyhow I started running unit test on 22.0.1 in a loop now locally | 12:54 |
zigo | But it will take a long time... | 12:55 |
sean-k-mooney | vinay_m: there shoudl always be at least a minimal log is it actully booting correct | 12:55 |
brinzhang_ | gibi: the noVNC patch is ready to review now, IMO, it can be mereged firstly | 12:55 |
vinay_m | sean-k-mooney: same doubt , but status was showing active that's it | 12: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 ready | 12:56 |
sean-k-mooney | vinay_m: and nothing form "openstack console log show <uuid>"? | 12:57 |
brinzhang_ | gibi: I am not similiar with the hypervisor series process | 12:57 |
vinay_m | sean-k-mooney: no console log | 12:57 |
sean-k-mooney | vinay_m: you might need to connect to libvirt directly and check but it sound like its not even getting to finding the os | 12:58 |
gibi | brinzhang_: 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 once | 12:58 |
sean-k-mooney | vinay_m: im not familar with vepc but if it used differnt disk buses or machine types it could cause the image to be unbootable | 12:59 |
gibi | sorry 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_m | sean-k-mooney: os i have used was ubuntu 18.0.4 | 12:59 |
sean-k-mooney | oh vepc is vEPC | 12: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 boss | 13:00 |
sean-k-mooney | i tought it was an image creation tool like disk image builder | 13:00 |
*** ociuhandu has joined #openstack-nova | 13:00 | |
gibi | brinzhang_: does the tenant_id work has high priority from your perspective? | 13:00 |
sean-k-mooney | vinay_m: my best guess is there is someing in the vECP applcaition that is breakign the guest netorking | 13:01 |
brinzhang_ | gibi: is there a deadline line? maybe I can do some changes before the deadline | 13:01 |
gibi | brinzhang_: M3 is feature freeze | 13:01 |
sean-k-mooney | vinay_m: im not really sure we can help much unless you have a specific nova/libvirt errorr | 13:01 |
gibi | that is the deadline to land these changes | 13:01 |
gibi | in W | 13:02 |
brinzhang_ | gibi: it's lower than my boss's point | 13:02 |
brinzhang_ | when? | 13:02 |
sean-k-mooney | brinzhang_: m3 in march/april | 13:02 |
gibi | Marc 12 2021 | 13:02 |
sean-k-mooney | https://releases.openstack.org/wallaby/schedule.html yep | 13:02 |
gibi | brinzhang_: from my limited perspective the cyborg patches has higher prio than the tenant_id work as the cyborg patches finishing something we already started | 13: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 update | 13:03 |
vinay_m | sean-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 there | 13:03 |
sean-k-mooney | brinzhang_: ideally you would aim to finsih before that but ya | 13:04 |
brinzhang_ | gibi: yeah, the cyborg support patch is ready and it's closes to merge, hope you all to review | 13:04 |
gibi | brinzhang_: I suggest to focus on cyborg and the stuff that is higher on you boss's list | 13:05 |
brinzhang_ | sean-k-mooney: I am not sure I can complete, but I can try | 13:05 |
gibi | brinzhang_: as for me tenant_id can wait | 13:05 |
*** ociuhandu has quit IRC | 13:05 | |
vinay_m | problem i'm thinking was with setup deployed on a bare metal .. will it ? | 13:05 |
brinzhang_ | gibi: Their priorities depend on my decision | 13:05 |
sean-k-mooney | vinay_m: if cirros/plain ubuntu is workign this is pointing to an issue with the vEPC config not with openstack | 13:06 |
brinzhang_ | gibi: yeah, after the shelve/unshelve patch merged, we will start the cyborg resume/paused support work, otherwise we will wait | 13:06 |
sean-k-mooney | brinzhang_: if you dont think you can complete the tenant work this cycle then we shoudl wait to merge it | 13: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 ok | 13:07 |
*** hemanth_n has quit IRC | 13:07 | |
gibi | brinzhang_: 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 progress | 13:08 |
*** zzzeek has quit IRC | 13:09 | |
brinzhang_ | gibi: I said before, it's nothing | 13:09 |
gibi | brinzhang_: 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 more | 13: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 me | 13:10 |
* gibi goes back to review the first tenant_id patch | 13:10 | |
brinzhang_ | gibi: yeah, we can review but not merge it, I can accept this decision. | 13:11 |
*** zzzeek has joined #openstack-nova | 13:11 | |
gibi | brinzhang_: thank you for your understanding | 13:11 |
brinzhang_ | gibi, sean-k-mooney: NP, thanks again | 13:12 |
* brinzhang_ will go home | 13:12 | |
*** artom has joined #openstack-nova | 13:13 | |
gibi | brinzhang_: o/ | 13:13 |
*** mgariepy has joined #openstack-nova | 13:15 | |
*** brinzhang_ has quit IRC | 13:18 | |
*** ociuhandu has joined #openstack-nova | 13:26 | |
*** mkrai has quit IRC | 13:29 | |
*** mugsie has quit IRC | 13:32 | |
*** raildo has joined #openstack-nova | 13:32 | |
*** ociuhandu has quit IRC | 13:32 | |
*** waverider has joined #openstack-nova | 13:37 | |
*** nweinber has joined #openstack-nova | 13:41 | |
*** dcapone2004 has joined #openstack-nova | 13:51 | |
dcapone2004 | sean-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 down | 13:52 |
gibi | stephenfin: when we removed os-fping in Rocky, did we intentionally kept the api doc for it in tree? | 13:53 |
sean-k-mooney | dcapone2004: ok i guess there might be a kernel panic or something | 13:53 |
sean-k-mooney | dcapone2004:in the windows guest | 13:54 |
*** ociuhandu has joined #openstack-nova | 13:54 | |
dcapone2004 | sean-k-mooney: yeah not sure because I never am able to get to a console fast enough....Nova logs just show that instance stopped itself | 13:54 |
dcapone2004 | but the hypervisor=off parameter does get passed when it happens | 13:55 |
sean-k-mooney | ok so it still fails with hypervior=off | 13:55 |
sean-k-mooney | dcapone2004: you coudl also set hyperv to manual start in the windows service | 13:56 |
sean-k-mooney | that way when it crashs on start | 13:56 |
sean-k-mooney | you can check the system events | 13:56 |
sean-k-mooney | on the next boot in the vm | 13:56 |
*** Jorhson has quit IRC | 13:56 | |
sean-k-mooney | since it wont auto start | 13:56 |
dcapone2004 | I 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 logged | 13:57 |
lpetrut | hey, are instances automatically shutting down? nova might be doing it if db state says that it should be shut off | 13:58 |
*** hack-char has quit IRC | 13:58 | |
*** hack-char has joined #openstack-nova | 13:59 | |
dcapone2004 | ipetrut: 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 api | 13:59 |
*** ociuhandu has quit IRC | 13:59 | |
lpetrut | got it, that's expected behavior but it can be disabled | 13:59 |
lpetrut | just a sec, fetching the cfg opt | 13:59 |
dcapone2004 | original DB power_state: 4, current VM power_state: 1 | 14:00 |
lpetrut | you may want to use this so that Nova doesn't automatically turn the instance back off: http://paste.openstack.org/raw/800701/ | 14:00 |
dcapone2004 | help me with enum for the power states, that is what is showing in my logs | 14:00 |
*** ociuhandu has joined #openstack-nova | 14:02 | |
dcapone2004 | just asked kolla to implement those changes, I'll report back in about 20 | 14:03 |
lpetrut | this is what you're seeing in the logs https://github.com/openstack/nova/blob/22.0.1/nova/compute/manager.py#L9622-L9627 | 14:03 |
lpetrut | unless 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 again | 14:04 |
*** ociuhandu has quit IRC | 14:06 | |
*** ociuhandu has joined #openstack-nova | 14:07 | |
dcapone2004 | yeah except the message was confusing to me because it said "shutdown by itself", when in fact I just started it was libvirt | 14:08 |
dcapone2004 | with* | 14:08 |
dcapone2004 | so, 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 it | 14:08 |
sean-k-mooney | dcapone2004: that is liekly the power state sync | 14:09 |
dcapone2004 | oh 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-mooney | if its off in the nova db nova will shut it down | 14:09 |
dcapone2004 | then when I try to start it again, nova is saying, this is supposed to be shutdown and powers it back off | 14:10 |
sean-k-mooney | if we see the vm stop we update the db to be shutdown | 14:10 |
sean-k-mooney | dcapone2004: as lpetrut noted you can disable this behavior if you want/need too | 14:10 |
dcapone2004 | yep, 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 KVM | 14:11 |
lpetrut | is hyper-v hanging or crashing and rebooting? | 14:15 |
lpetrut | if you can't get any logs or crash dump, you can even attach a debugger to the serial port | 14:17 |
dcapone2004 | so, if I enable hyper-v, the system hangs on the boot | 14:18 |
dcapone2004 | after a hard reboot, windows loads itself into the startup recovery tool | 14:19 |
sean-k-mooney | lpetrut: dcapone2004 is trying to get docker on windows working on windows 10 for context | 14:19 |
dcapone2004 | I 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-mooney | so hyperv is need to run the linux continer in light weight vms | 14:19 |
dcapone2004 | so, I am trying to test what happens when the hypervisor=no parameter is passed | 14:20 |
*** martinkennelly has joined #openstack-nova | 14:21 | |
dcapone2004 | I'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 config | 14:22 |
mgariepy | hello, is there someone who can help push this patch along for Ussuri please: https://review.opendev.org/c/openstack/nova/+/758761 | 14:24 |
lpetrut | dcapone2004 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,+vmx | 14:25 |
dcapone2004 | ipetrut: those flags I have...they are added by nova with the os_type=windows properties....sean helped guide me to try that last night | 14:27 |
lpetrut | dcapone2004: it may be worth double checking, I'm not sure if Nova sets all the flags required for running Hyper-V on top | 14:31 |
dcapone2004 | the one I feel is missing based on that article I referenced and linked is the hypervisor=off option | 14:32 |
dcapone2004 | with your config changes, I have been able to add that via virsh, so enabling hyper-v now and about to reboot | 14: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 missing | 14:39 |
dcapone2004 | time 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=off | 14:48 |
dcapone2004 | bingo, 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-mooney | dcapone2004: so which options are needed that are missing? | 14:58 |
*** dklyle has joined #openstack-nova | 14:58 | |
sean-k-mooney | look like you enabled a bunch of the enlightnments | 14:58 |
sean-k-mooney | i dont see hypervior=off in the list | 14:59 |
sean-k-mooney | so it looks like we jsut ened to enable the enlightements | 14:59 |
dcapone2004 | nope, 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 it | 14:59 |
sean-k-mooney | lpetrut: do you know of any reason not to do that for all windows guests by default | 14:59 |
*** ociuhandu has quit IRC | 15:00 | |
sean-k-mooney | lpetrut: e.g. if your qemu and libvirt is new enough to support a hyperv enlightment we would jsut enable it by defualt | 15:00 |
sean-k-mooney | lpetrut: that shoudl improve performace ingereall even without the nested virt or docker usecase | 15:01 |
dcapone2004 | hv-vpindex,hv-runtime,hv-synic,hv-reset those were the 4 additional that virsh would accept and I added | 15:01 |
sean-k-mooney | hv-synic might be the issue | 15:02 |
stephenfin | gibi: You mean the docs? Yes, we did, because it's still available on older releases | 15:02 |
sean-k-mooney | Enable Synthetic Interrupt Controller (SynIC) | 15:02 |
gibi | stephenfin: I mean the api ref docs. | 15:02 |
stephenfin | and the API reference is unversioned | 15:02 |
gibi | stephenfin: so we don't have victoria api ref | 15:03 |
gibi | :/ | 15:03 |
stephenfin | We shouldn't have. There's just an API ref | 15:03 |
lpetrut | sean-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 performance | 15:03 |
stephenfin | Because a request for e.g. 2.13 should look the exact same across all versions of nova that support that | 15:03 |
*** mkrai has joined #openstack-nova | 15:04 | |
sean-k-mooney | lpetrut: our min qemu is proably new enought now | 15:04 |
gibi | stephenfin: but it is not true for fping as it is removed in rocky | 15:04 |
gibi | stephenfin: so fping request even if it is called with 2.13 is 404 since rocky | 15:05 |
sean-k-mooney | lpetrut: ok not quite | 15:05 |
sean-k-mooney | lpetrut: our min is 4.0.0 | 15:05 |
gibi | or at least this is how I understand the api ref | 15:05 |
sean-k-mooney | and min livbirt is 5.0.0 | 15:05 |
stephenfin | gibi: 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 410 | 15:05 |
sean-k-mooney | lpetrut: we will be going to livbirt 6.0.0 and qemu 4.2.0 this cycle | 15:06 |
stephenfin | https://docs.openstack.org/api-ref/compute/#ping-instances-os-fping | 15: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-mooney | lpetrut: dcapone2004 so at that point we coudl enable all of them | 15:06 |
lpetrut | I 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 well | 15:07 |
sean-k-mooney | https://libvirt.org/formatdomain.html#hypervisor-features | 15:07 |
sean-k-mooney | the versions are listed there | 15:07 |
gibi | stephenfin: OK, then what to do with this https://review.opendev.org/c/openstack/nova/+/765311/1/api-ref/source/parameters.yaml#396 | 15:08 |
stephenfin | we should keep it but not update it | 15:09 |
gibi | stephenfin: keep it as we cannot update the already deleted code | 15:09 |
gibi | is it? | 15:09 |
lpetrut | sean-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-in | 15:09 |
stephenfin | yes | 15:09 |
stephenfin | it's just documentation | 15:10 |
gibi | stephenfin: OK, thanks. it is clear now | 15:10 |
dcapone2004 | ipetrut: an enable_hyperv_support property maybe? | 15:10 |
*** ociuhandu has joined #openstack-nova | 15:11 | |
lpetrut | dcapone2004: yep, that would probably be the way to go unless it becomes the default for Windows guests | 15:12 |
lpetrut | we 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 default | 15:13 |
dcapone2004 | ipetrut: 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 again | 15:15 |
lpetrut | I assume most of those features are related to Hyper-V VMBus (virtio equivalent), so older guests might not support those enlightments | 15:15 |
lpetrut | dcapone2004: right, this list is very helpful | 15:16 |
sean-k-mooney | so what we bacially will want is an image proerty | 15:16 |
sean-k-mooney | that is a list of enum values | 15:16 |
sean-k-mooney | and the image could declare what it supports | 15:16 |
*** ociuhandu has quit IRC | 15:16 | |
sean-k-mooney | we can add the current allways on enlighemtn as the defualt for the value | 15:16 |
sean-k-mooney | the other way is to use traits | 15:17 |
lpetrut | sean-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 supports | 15:17 |
lpetrut | while having some safe defaults | 15:18 |
sean-k-mooney | dcapone2004: so this is basically evolving form a potenial bug to a feature request | 15:19 |
noonedeadpunk | hi! 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-mooney | is this something you would have capsity to work on or just soemthjing you would like to see added | 15:19 |
sean-k-mooney | noonedeadpunk:that proably more of an oslo question | 15:20 |
lpetrut | sean-k-mooney: I can't remember, does the libvirt nova driver allow you to set arbitrary cpu flags? | 15:20 |
sean-k-mooney | noonedeadpunk: https://github.com/openstack/oslo.cache/blob/master/oslo_cache/backends/etcd3gw.py#L17 | 15:21 |
sean-k-mooney | lpetrut: cpu flags yes but these are not cpu flags | 15:21 |
sean-k-mooney | lpetrut: and only via the nova config | 15:21 |
sean-k-mooney | noonedeadpunk: it look like it does an unconditonal import | 15:21 |
noonedeadpunk | it 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-mooney | noonedeadpunk: these config option are actully adde by oslo.cache | 15:22 |
noonedeadpunk | I'm jsut not sure why it loads etcd3gw backend at all... | 15:23 |
sean-k-mooney | im guessing its usign the stevado extention manager to load it unconditonally | 15:26 |
sean-k-mooney | looking for that currently | 15:26 |
sean-k-mooney | noonedeadpunk: where is that being raised | 15:29 |
noonedeadpunk | found it here https://zuul.opendev.org/t/openstack/build/0af9364cc9094b5096899ed7693a9f60/log/logs/host/nova-conductor.service.journal-10-50-46.log.txt#2431 | 15:30 |
*** lpetrut has quit IRC | 15:30 | |
sean-k-mooney | we are not using sevedor to load this in oslo cache or in nova | 15:31 |
noonedeadpunk | um..... | 15:32 |
sean-k-mooney | im wondering if this is coming form oslo.config | 15:32 |
noonedeadpunk | can hardly imagine path of the imports tbh | 15:33 |
noonedeadpunk | But I think it appeared only in V since in U haven't seen that message | 15:33 |
sean-k-mooney | we are using oslo cache | 15:33 |
sean-k-mooney | but i dont see it directly using sevedor in its code | 15:34 |
noonedeadpunk | ah, yes, might be oslo.config that using it, right | 15:34 |
sean-k-mooney | https://codesearch.opendev.org/?q=stevedore&i=nope&files=&excludeFiles=&repos=openstack/nova,openstack/oslo.cache,openstack/oslo.config,openstack/oslo.privsep | 15:34 |
sean-k-mooney | that is what im looking at | 15:34 |
*** redrobot has joined #openstack-nova | 15:35 | |
sean-k-mooney | we use stevador for 3 things in nova, extra spec validator, schudler dirvers and metric monitors | 15:35 |
*** martinkennelly has quit IRC | 15:35 | |
sean-k-mooney | oslo cache and oslo privsep dont use it at all it just in ther lower constraits | 15:36 |
sean-k-mooney | because they depend on oslo.config which does use it | 15:36 |
*** ociuhandu has joined #openstack-nova | 15:37 | |
sean-k-mooney | it might be https://github.com/openstack/oslo.cache/commit/308f49aaaad554573aeff8ddc68c39ff7fe57438 | 15:37 |
noonedeadpunk | seem like https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2152-L2154 | 15:37 |
noonedeadpunk | yeah | 15:37 |
sean-k-mooney | ya | 15:38 |
*** waverider has quit IRC | 15:39 | |
*** waverider has joined #openstack-nova | 15:39 | |
*** waverider has quit IRC | 15:40 | |
sean-k-mooney | anyway this seams to be an oslo issue in one form or another | 15:40 |
*** waverider has joined #openstack-nova | 15:40 | |
noonedeadpunk | yeah, agreed - thanks for helping out - will go and chase oslo folks | 15:41 |
*** ociuhandu has quit IRC | 15:46 | |
*** ociuhandu has joined #openstack-nova | 15:47 | |
*** k_mouza has quit IRC | 15:48 | |
*** k_mouza has joined #openstack-nova | 15:50 | |
*** xek_ has joined #openstack-nova | 15:56 | |
*** macz_ has joined #openstack-nova | 15:56 | |
*** mlavalle has joined #openstack-nova | 15:57 | |
gibi | nova weekly meeting starts in 3 minutes on #openstack-meeting-3 | 15:57 |
gmann | gibi: 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 help | 15:57 |
gmann | ypo. * rebase is *not* so hard for microversion | 15:57 |
*** xek has quit IRC | 15:59 | |
gibi | gmann: 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 none | 15:59 |
gmann | gibi: yeah but i think code cleanup also there which i suspect a large chunk but need to grep and see. | 16:00 |
gmann | I think having all changes up and zuul +1 then we can start merging. | 16:01 |
gibi | gmann: 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 place | 16:01 |
gibi | gmann: yes, that would be ideal, but Brin noted that this will be a lot of patches | 16:02 |
gmann | humm | 16:02 |
gibi | so we talked about options | 16:02 |
gibi | but at the end we found no viable option other than having all the patches | 16:02 |
gibi | (if we want to keep them in a single microversion) | 16:02 |
*** waverider has quit IRC | 16:03 | |
gmann | and base patch with -W until all are ready ? | 16:03 |
*** waverider has joined #openstack-nova | 16:10 | |
*** mgariepy has quit IRC | 16:10 | |
gibi | yeah, basically | 16:13 |
gibi | if 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 it | 16:13 |
gibi | so now it is all or nothing | 16:14 |
gmann | gibi: +1 | 16:17 |
*** mkrai has quit IRC | 16:19 | |
*** mkrai_ has joined #openstack-nova | 16:20 | |
gibi | sean-k-mooney: if you are around we need you in #openstack-meeting-3 | 16:21 |
*** dklyle has quit IRC | 16:25 | |
*** dklyle has joined #openstack-nova | 16:25 | |
*** waverider has quit IRC | 16:28 | |
*** sapd1_x has joined #openstack-nova | 16:37 | |
dcapone2004 | sean-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 |
kashyap | dcapone2004: FWIW, it's actually gotten significantly simpler; OpenStack Gerrit also provides a "sandbox" to practise your workflow | 16:42 |
kashyap | (https://docs.opendev.org/opendev/infra-manual/latest/sandbox.html) | 16:42 |
dcapone2004 | nteresting...I will take a look at that | 16:43 |
sean-k-mooney | dcapone2004: thats ok. can you file a blueprint for this https://blueprints.launchpad.net/nova/+addspec | 16:43 |
sean-k-mooney | dcapone2004: basically like a bug but descibing your use case, what we have learns and what we your are trying to do | 16:43 |
dcapone2004 | sean-k-mooney: that I can do | 16:44 |
sean-k-mooney | if you can include the 4 enlightments that were need in your case that will helpt o document them | 16:44 |
dcapone2004 | kashyap: 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 merged | 16:44 |
kashyap | dcapone2004: It takes some time getting used to, but it's not as complex - if you're focusing on one small part of the code | 16:46 |
kashyap | dasp: 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 |
kashyap | Err, I meant dcapone2004 --^ | 16:46 |
dcapone2004 | I 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 general | 16:47 |
*** ociuhandu has quit IRC | 16:47 | |
*** rpittau is now known as rpittau|afk | 16:49 | |
*** vinay_m has quit IRC | 16:50 | |
*** mgariepy has joined #openstack-nova | 16:53 | |
*** luksky has quit IRC | 16:54 | |
*** mkrai_ has quit IRC | 16:54 | |
stephenfin | sean-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 | *for | 16:58 |
sean-k-mooney | either of those i coudl be ok with | 16:59 |
sean-k-mooney | periods to dashes is the recommend transformation in the RFS and docs for /etc/hostname and systemd-hostnamed | 16:59 |
sean-k-mooney | just using the first segment is acutlly striping the domain and using the hostname for the host name field | 17:00 |
sean-k-mooney | striping woudl be using the dns "host name" for the non DNS "hostname" | 17:00 |
sean-k-mooney | those should generally be the same but are not required to be. | 17:01 |
bauzas | stephenfin: I'm personnally on the former side | 17:01 |
artom | bauzas, https://bugzilla.redhat.com/show_bug.cgi?id=1721068#c41 oh yeah we did | 17:02 |
openstack | bugzilla.redhat.com bug 1721068 in openstack-nova "allocations database is not properly cleaned" [Medium,Closed: errata] - Assigned to sbauza | 17:02 |
artom | (QE it on Queens, I mean) | 17:02 |
bauzas | changing periods to dashes is less easy to explain in terms of backportability IMHO | 17:02 |
sean-k-mooney | gibi: QE is quality engenering basically our test engineeres | 17:02 |
gibi | thanks | 17:02 |
sean-k-mooney | gibi: so QE'd just means tested by them | 17:02 |
bauzas | artom: I know I'm old but I remembered this | 17:02 |
stephenfin | bauzas: same thing, no? The hostname is going to be different in both cases | 17:03 |
sean-k-mooney | bauzas: reading the orginal unicode bug i woudl consider the current unicode bhavior to be invalid and actully a bug | 17:03 |
gibi | as we consider the audit a big win, and we did backported nova-manage commands in the past. I'm OK to take the risk | 17:03 |
gibi | and merge the backports | 17:03 |
artom | bauzas, hehe | 17:03 |
artom | So the train one wasn't so bad: https://review.opendev.org/c/openstack/nova/+/720838 | 17:03 |
gibi | but I don't have +2 on stable :) | 17:03 |
bauzas | stephenfin: I mean that I feel reasonably confident to explain to angry users that we consider that a FQDN isn't a hostname | 17:03 |
bauzas | and that we only spoke of a server name | 17:03 |
stephenfin | I'm worried about users with instance names like 'test-server.1', 'test-server.2', ... | 17:04 |
stephenfin | or 'ubuntu18.04' | 17:04 |
bauzas | the first case seems weirdo to me | 17:05 |
gibi | hm, test-server.1 and test-server.2 becomes test-server as a hostname in the geuest | 17:05 |
sean-k-mooney | so as an exampel we are proposign if servername=example.fqdn then instance.hostname==example and instance.display_name==example.fqdn | 17:05 |
bauzas | the second case is indeed somehow hard to convince | 17:05 |
bauzas | gibi: and I'm cool with this | 17:05 |
bauzas | (to have duplicate hostnames) | 17:05 |
stephenfin | sean-k-mooney: yes, and the alternative is instance.hostname=example-fqdn | 17:05 |
sean-k-mooney | yes | 17:06 |
sean-k-mooney | so if we maintain dispaly name that means that nova show example.fqdn will work in both cases | 17:06 |
sean-k-mooney | so ti wont affect server show | 17:06 |
sean-k-mooney | or list | 17:06 |
gibi | yeah, I agree not to affect server show and list | 17:06 |
stephenfin | Yes, it'll only affect people relying on cloud-init, which you're saying is already broken for FQDN? | 17:06 |
bauzas | just being clear, don't touch display_name ! | 17:07 |
stephenfin | *cloud-init for DNS integration | 17:07 |
sean-k-mooney | so it will only effect what is in the metadata and passed to designate | 17:07 |
bauzas | hangouts, folks ? | 17:07 |
stephenfin | isn't a bit late for you Europeans? | 17:07 |
bauzas | actually, my wife will kill me | 17:07 |
stephenfin | yeah :) | 17:07 |
gibi | mine too | 17:07 |
sean-k-mooney | yes with designate you get test-dns.invalid.dns.cloud.seanmooney.info for a servername=test-dns.invalid.dns via dns | 17:07 |
bauzas | stephenfin: dude, you're part of Europe | 17:08 |
stephenfin | *continental Europeans | 17:08 |
stephenfin | ;) | 17:08 |
bauzas | on a small isolated island tho | 17:08 |
* stephenfin is on PTO tomorrow too, fwiw | 17:08 | |
gibi | :D | 17:08 |
sean-k-mooney | bauzas: its the brit in him showing :P | 17:08 |
bauzas | well, I actually feel isolated too | 17:08 |
gibi | push this two option ack to the ML: a) truncate b) replace with - | 17:08 |
bauzas | anyway | 17:08 |
bauzas | gibi: +1 | 17:08 |
stephenfin | gibi: good call; me does that | 17:08 |
gibi | sleep on it | 17:09 |
sean-k-mooney | cool that work for me too | 17:09 |
gibi | then try to close this out next week | 17:09 |
gibi | when stephenfin is back | 17:09 |
bauzas | stephenfin: clarify there are only two options and that we're about to backport the chosen | 17:09 |
gibi | ^^ +1 | 17:09 |
sean-k-mooney | do we need a workaround flag for this | 17:10 |
sean-k-mooney | for the backports | 17:10 |
artom | Random idea | 17: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 crazy | 17:10 |
artom | You can set the port's dns_name "manually" via the Neutron API | 17:10 |
bauzas | sean-k-mooney: NO | 17:10 |
artom | So... why not just stop doing it automagically when Nova creates/updates the port? | 17:10 |
sean-k-mooney | bauzas: ok | 17:10 |
* gibi is slowly backing away from IRC and moving towards dinner | 17:10 | |
artom | And let people pick their own hostname that way | 17:10 |
sean-k-mooney | artom: only with designate | 17:10 |
bauzas | yeah | 17:10 |
sean-k-mooney | well or a vey new extenion i think | 17:11 |
artom | sean-k-mooney, not based on https://docs.openstack.org/api-ref/network/v2/index.html?expanded=update-port-detail,show-port-details-detail#update-port | 17:11 |
sean-k-mooney | ill check | 17:11 |
bauzas | and that's exactly why I think that nova shouldn't deal with TLDs in their server hostnames | 17:11 |
artom | Like, the original BZ we have is because Neutron exploded | 17:11 |
artom | Not Designate | 17:11 |
bauzas | but I can recognize that the dash conversion seems kinda more acceptable to users | 17:11 |
*** links has joined #openstack-nova | 17:11 | |
bauzas | anyway, /me needs to bail out | 17:12 |
bauzas | ++ | 17:12 |
* gibi bails out too | 17:13 | |
gibi | o/ | 17:13 |
stephenfin | o/ | 17:13 |
sean-k-mooney | artom: im pretty sure nova used to explode at one point too with some of the shared nova net code | 17:13 |
sean-k-mooney | artom: the orginal bz was in my dev cloud in intel | 17:14 |
artom | sean-k-mooney, bz or launchpad bug? | 17:14 |
sean-k-mooney | it was filed by someone on my team after i told them it was never supported | 17:14 |
sean-k-mooney | sorry the launch pad bug | 17:14 |
artom | Well, nova-network doesn't exist anymore, so... :) | 17:14 |
sean-k-mooney | i think it used to explode somewhere in https://github.com/openstack/nova/blob/stable/train/nova/network/minidns.py | 17:16 |
sean-k-mooney | this si where we are current failing right https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L678-L686 | 17:17 |
artom | sean-k-mooney, no, based on https://bugzilla.redhat.com/show_bug.cgi?id=1872314 we actually make the request to Neutron | 17:20 |
openstack | bugzilla.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-maint | 17:20 |
artom | And bubble up the BadRequest it returns | 17:20 |
sean-k-mooney | artom: oh i know | 17:20 |
sean-k-mooney | but back in like havana i think it broken in nova it also broke in neutorn | 17:21 |
sean-k-mooney | at somepoint neutron started allowing the fqdn | 17:21 |
sean-k-mooney | but it was never done intentually at least form a nova point of view | 17:21 |
artom | So https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1138 would be where our request to Neutron explodes | 17:22 |
artom | And https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1494 is where we populate the dns_name | 17:23 |
artom | I'm saying don't actually do that | 17:23 |
artom | And let the users do a port update manually with the hostname of their chosing, not one that Nova has derived from the VM name | 17:23 |
artom | And *then* if Neutron isn't happy, it really is user error and WONTFIX :) | 17:25 |
*** sapd1_x has quit IRC | 17:25 | |
sean-k-mooney | artom: that wont fix the fact the contend ot the metadata api is not what you expect | 17:27 |
artom | sean-k-mooney, eh? | 17:28 |
sean-k-mooney | look at http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019137.html | 17:28 |
sean-k-mooney | with a default designate domain of cloud.seanmooney.info adn default dhcp_domain of novalocal | 17:29 |
sean-k-mooney | fi you create a server called test-dns.invalid.dns | 17:29 |
*** tosky has quit IRC | 17:29 | |
sean-k-mooney | you will have "test-dns.invalid.dns.novalocal" "test-dns.invalid.dns.cloud.seanmooney.info" "test-dns.cloud.seanmooney.info" and test-dns for hostnames/fqdns | 17:30 |
sean-k-mooney | but you will never have test-dns.invalid.dns which was the fqdn you uses as the servername | 17:31 |
artom | sean-k-mooney, I feel like we're conflating many problems into 1 | 17:31 |
sean-k-mooney | not really | 17:31 |
sean-k-mooney | if we allow FQDNs we shoudl support them consitently | 17:31 |
sean-k-mooney | right now you will get 4 possible name for the server none of them will be the one you passed in unless | 17:32 |
sean-k-mooney | you explcity configure [DEFAULT]/dhcp_domain="" and do not use a default designate domain | 17:32 |
artom | sean-k-mooney, right, this falls in the wider "our DNS interoperation is crap" problem | 17:33 |
artom | On which my grip is not great | 17:34 |
artom | But feels like fixing that would involve a new microversion with a separate hostname and/or fqdn parameter | 17:34 |
artom | At 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 valid | 17:35 |
sean-k-mooney | if you want real fun read https://review.opendev.org/c/openstack/neutron-specs/+/88623/16/specs/liberty/internal-dns-resolution.rst | 17:36 |
artom | If I want real fun I'll go do some drugs | 17:36 |
sean-k-mooney | https://bugs.launchpad.net/neutron/+bug/1459030 | 17:36 |
openstack | Launchpad 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 IRC | 17:38 | |
artom | I wonder if anyone's asked PSI whether they actually need the DNS integration :P | 17:38 |
sean-k-mooney | its quite useful | 17:38 |
sean-k-mooney | its why i use it | 17:38 |
*** dtantsur is now known as dtantsur|afk | 17:39 | |
sean-k-mooney | but its also not well maintained | 17:39 |
sean-k-mooney | or rather a very small team | 17:39 |
sean-k-mooney | no that i have moved my dns to cloudflare most of my issue with updating dns are fixed | 17:40 |
sean-k-mooney | godda's ui/api was horrible | 17:40 |
sean-k-mooney | by 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 create | 17:44 |
*** k_mouza has quit IRC | 17:53 | |
*** tesseract has quit IRC | 17:57 | |
*** k_mouza has joined #openstack-nova | 17:59 | |
*** jangutter has joined #openstack-nova | 18:00 | |
*** derekh has quit IRC | 18:01 | |
*** k_mouza has quit IRC | 18:02 | |
*** k_mouza has joined #openstack-nova | 18:02 | |
*** jangutter_ has quit IRC | 18:03 | |
*** xek_ has quit IRC | 18:06 | |
*** k_mouza has quit IRC | 18:06 | |
*** jangutter has quit IRC | 18:21 | |
*** jangutter has joined #openstack-nova | 18:22 | |
*** jangutter has quit IRC | 18:25 | |
*** jangutter has joined #openstack-nova | 18:26 | |
*** andrewbonney has quit IRC | 18:29 | |
*** artom has quit IRC | 18:37 | |
*** artom has joined #openstack-nova | 18:37 | |
*** jangutter has quit IRC | 18:39 | |
*** jangutter has joined #openstack-nova | 18:40 | |
*** jangutter has quit IRC | 18:41 | |
*** jangutter_ has joined #openstack-nova | 18:41 | |
*** jangutter_ has quit IRC | 18:45 | |
*** jangutter has joined #openstack-nova | 18:45 | |
*** k_mouza has joined #openstack-nova | 18:48 | |
*** hamalq has joined #openstack-nova | 18:58 | |
*** belmoreira has quit IRC | 19:11 | |
*** k_mouza has quit IRC | 19:13 | |
*** vishalmanchanda has quit IRC | 19:22 | |
*** luksky has joined #openstack-nova | 19:42 | |
*** rcernin has joined #openstack-nova | 19:57 | |
*** jmlowe has quit IRC | 19:58 | |
*** jmlowe has joined #openstack-nova | 19:59 | |
*** k_mouza has joined #openstack-nova | 20:05 | |
*** k_mouza has quit IRC | 20:07 | |
*** rcernin has quit IRC | 20:23 | |
*** xek_ has joined #openstack-nova | 20:23 | |
*** waverider has joined #openstack-nova | 20:48 | |
*** tosky has joined #openstack-nova | 20:55 | |
*** rcernin has joined #openstack-nova | 20:58 | |
*** songwenping__ has joined #openstack-nova | 21:02 | |
*** rcernin has quit IRC | 21:03 | |
*** songwenping_ has quit IRC | 21:06 | |
*** openstackgerrit has quit IRC | 21:08 | |
*** purplerbot has quit IRC | 21:24 | |
*** rcernin has joined #openstack-nova | 21:29 | |
*** purplerbot has joined #openstack-nova | 21:33 | |
*** purplerbot has quit IRC | 21:35 | |
*** purplerbot has joined #openstack-nova | 21:41 | |
*** ociuhandu has joined #openstack-nova | 21:46 | |
*** waverider has quit IRC | 21:56 | |
*** waverider has joined #openstack-nova | 21:56 | |
*** nweinber has quit IRC | 22:06 | |
*** xek_ has quit IRC | 22:20 | |
*** ociuhandu has quit IRC | 22:24 | |
*** ociuhandu has joined #openstack-nova | 22:25 | |
*** ociuhandu has quit IRC | 22:30 | |
*** ociuhandu has joined #openstack-nova | 22:55 | |
*** luksky has quit IRC | 23:03 | |
*** tkajinam has quit IRC | 23:03 | |
*** ociuhandu has quit IRC | 23:04 | |
*** tkajinam has joined #openstack-nova | 23:04 | |
*** openstackgerrit has joined #openstack-nova | 23:10 | |
openstackgerrit | Mamduh 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/+/765419 | 23:11 |
*** bnemec has quit IRC | 23:22 | |
*** ociuhandu has joined #openstack-nova | 23:22 | |
*** ociuhandu has quit IRC | 23:27 | |
*** songwenping_ has joined #openstack-nova | 23:30 | |
*** songwenping__ has quit IRC | 23:33 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!