| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-04-11 | |||
| 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 | |
| 16:43:23 | sean-k-mooney | anyway at least we know the semantic of "it shoudl be sortable" | |
| 16:43:30 | sean-k-mooney | have already been depened on | |
| 16:43:32 | bauzas | yeah, but instead of pinning a specific virt version, we should absract this into abstract versions | |
| 16:43:38 | sean-k-mooney | so that makes the weigher simpler | |
| 16:43:44 | bauzas | semantic versioning I mean | |
| 16:44:06 | sean-k-mooney | ya well to do that we woudl need to change this form an int to string | |
| 16:44:08 | sean-k-mooney | to model that | |
| 16:44:09 | bauzas | but yeah, for your weigher, it just makes the paperwork easy | |
| 16:44:19 | sean-k-mooney | but i dont want to touch that now | |
| 16:44:26 | sean-k-mooney | we can in the future if it makes sense too | |
| 16:44:36 | bauzas | sean-k-mooney: yup, and ideally it should obfuscate the hypervisor specific version | |
| 16:44:45 | sean-k-mooney | i will go do the paperwork and let you knwo when its donw | |
| 16:44:56 | bauzas | cool, I'll approve it once you ping me | |
| 16:45:16 | bauzas | and the weigher seems to me an easy peasy given the existing | |
| 16:45:30 | bauzas | the code change itself should be simple to review :) | |
| 16:46:39 | bauzas | anyway, done for today | |
| 17:06:20 | sean-k-mooney | bauzas: when you have time https://blueprints.launchpad.net/nova/+spec/weigh-host-by-hypervisor-version | |
| 17:07:47 | bauzas | sean-k-mooney: done | |
| 17:08:06 | sean-k-mooney | thanks | |
| 17:49:29 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | |
| 17:49:29 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 17:49:30 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |
| 17:49:30 | opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | |