| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-11 | |||
| 16:27:27 | bauzas | heh, I'm used to refresh but I forgot this time | |
| 16:27:32 | bauzas | (sean-k-mooney) hypervisor version weighed. | |
| 16:27:36 | bauzas | go for it then :) | |
| 16:27:46 | sean-k-mooney | so this is pretty simple | |
| 16:27:57 | sean-k-mooney | i would like to add a new scheduler weigher | |
| 16:28:20 | sean-k-mooney | that woudl weigh hosts based on the Hypervisror_version filed in the hoststate object | |
| 16:28:29 | sean-k-mooney | and prefer putting vms on new hosts | |
| 16:28:42 | sean-k-mooney | this will help with upgrades both pratically and with testing | |
| 16:28:50 | dansmith | yeah, I'm not sure who would argue against such behavior, so it sounds like a good idea to me | |
| 16:28:56 | bauzas | me too | |
| 16:29:03 | bauzas | and it's a weigher | |
| 16:29:06 | bauzas | not a filter | |
| 16:29:07 | sean-k-mooney | what i would like to know is shoudl this be a specless bluepint or mini spec liek the pci weigher | |
| 16:29:08 | dansmith | every cloud I've worked with has wanted to move instances towards newer hosts | |
| 16:29:31 | bauzas | sean-k-mooney: do you need to add new fields for the ComputeNode records ? | |
| 16:29:37 | sean-k-mooney | no | |
| 16:29:38 | gibi | does hypervisror_version field something that is always meaningfully comparable? | |
| 16:29:41 | bauzas | I think no | |
| 16:29:43 | sean-k-mooney | no db or object chanbges | |
| 16:29:53 | sean-k-mooney | gibi: that is a good question | |
| 16:30:03 | sean-k-mooney | so initally i was just going to do this for libvirt/qemu | |
| 16:30:21 | sean-k-mooney | for the libvirt driver its the libvirt verison | |
| 16:30:28 | sean-k-mooney | converted to a number | |
| 16:30:35 | sean-k-mooney | so 7.0.0 becomes 700000000 | |
| 16:30:44 | dansmith | it's an integer, so it's certainly easily comparable | |
| 16:30:46 | sean-k-mooney | i dont know if all virt driver are comparibale | |
| 16:30:47 | bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L129 | |
| 16:30:57 | bauzas | at least we have this field | |
| 16:30:59 | dansmith | if someone is not putting something where "bigger means newer" in an integer field, it would be very strange | |
| 16:31:13 | sean-k-mooney | is it an int in the db | |
| 16:31:18 | dansmith | it is | |
| 16:31:32 | gibi | then it is OK | |
| 16:31:36 | sean-k-mooney | ok then i think it will work for eventying | |
| 16:31:39 | bauzas | s/id/field | |
| 16:31:47 | sean-k-mooney | the weigher just need to return the value as the weight directly | |
| 16:32:08 | sean-k-mooney | and it will be nomalised/multipled like all the rest | |
| 16:32:21 | bauzas | well, then if all the drivers provide this field, and if the HostState already has this, then there is no upgrade question | |
| 16:32:29 | bauzas | so, | |
| 16:32:29 | bauzas | specless blueprint to me | |
| 16:32:47 | bauzas | oh heh, we already query it https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/scheduler/filters/image_props_filter.py#L85 | |
| 16:32:50 | dansmith | seems okay to me if there are no other wrinkles | |
| 16:33:04 | gibi | OK to me too | |
| 16:33:08 | bauzas | so, basically, we already support this field | |
| 16:33:14 | sean-k-mooney | bauzas: we do yes | |
| 16:33:16 | bauzas | definitely a specless bp | |
| 16:33:18 | sean-k-mooney | and we use it in the conductor | |
| 16:33:27 | sean-k-mooney | to prevent live migrating form new to older | |
| 16:33:28 | bauzas | sean-k-mooney: my question was more about the scheduler | |
| 16:33:34 | sean-k-mooney | yep | |
| 16:33:40 | sean-k-mooney | ok ill file the blueprint after the meeting | |
| 16:33:42 | bauzas | I was wondering why we were having a HostState field | |
| 16:33:48 | sean-k-mooney | and ill detail this in the describption | |
| 16:33:57 | bauzas | that was meaning that we were already a filter using it | |
| 16:33:59 | sean-k-mooney | yep i check that already | |
| 16:34:01 | sean-k-mooney | we do | |
| 16:34:05 | bauzas | cool cool | |
| 16:34:07 | bauzas | so, | |
| 16:34:40 | sean-k-mooney | i will file a blueprint and i will ping you the link once done for you to review | |
| 16:35:03 | bauzas | #agreed a blueprint asking to have a weigher using hypervisor_version would be a specless one | |
| 16:35:25 | bauzas | #action sean-k-mooney to ping bauzas once he creates it | |
| 16:35:28 | bauzas | voila | |
| 16:35:41 | bauzas | anything else ? | |
| 16:36:06 | bauzas | if not | |
| 16:36:10 | bauzas | thanks all, | |
| 16:36:13 | bauzas | #endmeeting | |
| 16:36:13 | opendevmeet | Meeting ended Tue Apr 11 16:36:13 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 16:36:13 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-11-16.00.html | |
| 16:36:13 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-11-16.00.txt | |
| 16:36:13 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-11-16.00.log.html | |
| 16:36:19 | gibi | o/ | |
| 16:36:24 | bauzas | hah, https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/scheduler/filters/image_props_filter.py#L84 | |
| 16:36:52 | bauzas | so, basically we even use the hypervisor version value for an image property :) | |
| 16:37:01 | bauzas | this is even not only internal | |
| 16:37:16 | sean-k-mooney | really? that seams wrong | |
| 16:37:23 | bauzas | sean-k-mooney: look above | |
| 16:37:25 | sean-k-mooney | oh i know what this is for | |
| 16:37:32 | sean-k-mooney | this is for hyperv i think | |
| 16:37:45 | sean-k-mooney | they use v1 and v2 like we use machine types | |
| 16:37:59 | bauzas | maybe, but that works too for libvirt | |
| 16:38:11 | sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/hyperv/hostops.py#L99-L104 | |
| 16:38:21 | sean-k-mooney | i guess no it sused for somethign else | |
| 16:38:40 | sean-k-mooney | i would want this to be a min verion really rather then exact comparison | |
| 16:39:08 | sean-k-mooney | that is not waht it does unfornetly | |
| 16:40:55 | sean-k-mooney | actully return img_prop_predicate.satisfied_by(hyper_ver_str) | |
| 16:41:02 | sean-k-mooney | so that proably is a min version check | |
| 16:41:18 | sean-k-mooney | thats implmented by distutils | |
| 16:41:23 | bauzas | this is | |
| 16:41:25 | bauzas | and https://github.com/openstack/nova/blob/72370a188c0755bc9c864b5a5e4a972077cb8dd6/nova/virt/libvirt/driver.py#L9516 | |
| 16:41:51 | bauzas | if you're an operator, you can create an image requesting for a min libvirt version | |
| 16:41:56 | bauzas | that already exists | |
| 16:42:04 | sean-k-mooney | well that is good to know | |
| 16:42:06 | bauzas | this is bad to me | |
| 16:42:11 | bauzas | but we do support it | |
| 16:42:21 | sean-k-mooney | its bad becasue its leaking backend details | |
| 16:42:25 | bauzas | correct | |
| 16:42:36 | sean-k-mooney | its good if you need to target a version for certen fucntionality | |
| 16:42:46 | sean-k-mooney | it should not be requried if we used traits properly | |
| 16:42:56 | sean-k-mooney | so in the past i can see the usecase | |
| 16:42:59 | bauzas | it was obviously pre-traits | |
| 16:43:04 | sean-k-mooney | ya | |