Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-04-11
16:18:41 bauzas I just wrote that :)
16:18:56 sean-k-mooney well you said could impliying we might not
16:18:58 bauzas anyway, looks to me none of us are telling nay
16:19:04 elodilles but downstream it can be consumed & released ;)
16:19:10 sean-k-mooney exactly
16:19:20 bauzas elodilles: IMHO you're good to go
16:19:22 sean-k-mooney so we still want to continue to merge them after EM
16:19:32 bauzas elodilles: propose the releases patch and auniyal and I will +1 it
16:20:08 elodilles bauzas: ack
16:20:21 bauzas auniyal: you had a subitem
16:20:29 bauzas about yoga and zed branches
16:20:32 auniyal yes bauzas
16:20:36 auniyal #info Please review these backport patches for stable zed and yoga release
16:20:51 auniyal #link https://etherpad.opendev.org/p/release-liaison-PatchesToReview
16:20:59 auniyal thats all :)
16:22:19 bauzas ok thanks auniyal
16:22:50 bauzas stable cores are welcome to review https://etherpad.opendev.org/p/release-liaison-PatchesToReview
16:23:10 bauzas auniyal: when do you plan to propose a stable release for yoga and zed ?
16:23:27 auniyal 20 April
16:24:00 bauzas ack
16:24:11 sean-k-mooney can you take a look at all nova deliverable fi you are doing that
16:24:12 bauzas let's revisit then on next weekly meeting
16:24:22 sean-k-mooney so os-vif, placement ectra
16:24:25 sean-k-mooney not just nova
16:24:40 sean-k-mooney i dont think we have a lot pending for those
16:25:06 bauzas sean-k-mooney: you mean the stable branches ?
16:25:12 bauzas yeah, that doesn't harm
16:25:15 auniyal ack sean-k-mooney, I am making same list for os-vif, placement and os-trait
16:25:28 bauzas auniyal: just use the same tracking etherpad IMHO
16:25:41 auniyal but I share them once I review them
16:25:44 auniyal ack bauzas
16:25:45 bauzas cool thanks
16:25:45 sean-k-mooney cool
16:25:55 bauzas ok, I guess we're done with this topic
16:26:05 sean-k-mooney for what its worth i dont see anythign for os-vif
16:26:11 bauzas thanks elodilles and auniyal for taking care of our eldests
16:26:18 elodilles ++
16:26:26 bauzas moving on
16:26:47 bauzas actually,
16:26:54 bauzas #topic Open discussion
16:27:01 bauzas there is nothing in the etherpad
16:27:06 sean-k-mooney refrsh
16:27:06 bauzas s/etherpad/wige
16:27:12 sean-k-mooney i added a topic
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

Earlier   Later