Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-07
16:35:12 opendevreview Dmitriy Rabotyagov proposed openstack/nova stable/zed: Adding server actions tests to grenade-multinode https://review.opendev.org/c/openstack/nova/+/900342
16:35:21 bauzas what *you* missed is that I figured this out before the meeting (that spec is older than our min bump) but I missed the fact we want to direct to libvirt-only nodes, hence my mistake
16:35:28 sean-k-mooney dansmith: upgrade case or where your mixing virt drivers
16:35:41 sean-k-mooney dansmith: but use oru current min is 7.0.0 i belvie and the feature is in 6.x
16:35:48 dansmith sean-k-mooney: okay libvirt and ironic being the only possibilities there :)
16:35:50 bauzas dansmith: the former (upgrade case) was my concern
16:35:58 bauzas sean-k-mooney: it requires 6.7
16:36:26 dansmith so I mean, I would probably lean towards just a service version check to not let this work until everything is upgraded, but the multi-virt driver thing is a fair point
16:36:27 sean-k-mooney bauzas: yep i said 6.x because i know we met the min requirement with our min supported version
16:36:31 bauzas I don't want us to buy a new trait for something that's only because we support N-2 this cycle
16:36:40 dansmith and even though we're dropping basically all the others, we could have a new one in the future without this support, so...
16:36:57 sean-k-mooney dansmith: well we dont need a new compute service verion for this feature in general
16:37:24 sean-k-mooney altough i guess we coudl do oen for the new prefilter
16:37:27 bauzas dansmith: so you're on the same page than me, a service version check for upgrades is enough, but if we really want to avoid other hypervisors we could need a trait
16:37:28 dansmith sean-k-mooney: we don't need it, but we could use it (cheaper than a trait) for the usual purpose of not exposing features until everything is upgraded
16:37:51 dansmith bauzas: no, I said I lean that way, but I'm also fine with a trait because of the virt driver possibility
16:37:52 sean-k-mooney dansmith: oh i disagree i alwasy conisderd a comptue version bump more expensive or at most the same
16:38:17 dansmith sean-k-mooney: well, we disagree then.. we bump service versions all the time for stuff like this, where there isn't even a rpc bump to correlate
16:38:37 dansmith and it is a single integer in one tree versus a new enum in traits, a package release, a dep update, and then a nova patch
16:38:39 bauzas tbh, I'd rather prefer having the prefilter asking 'get me a libvirt compute' rather than 'get me a compute that supports foo' since this feature is very QEMU-centric
16:39:05 bauzas sean-k-mooney: the fact is, this service version check can drop next cycle
16:39:05 sean-k-mooney bauzas: that would be a misuse of traits
16:39:26 bauzas sean-k-mooney: starting with D, all computes will support a libvirt recent enough
16:39:29 dansmith sean-k-mooney: how is that a misuse of traits?
16:39:32 sean-k-mooney if we want to also have a servic verion bump and an additon check in the api prior to the call to the schduler we can
16:39:52 sean-k-mooney dansmith: we previosly said we didnt want to have a trait for which virt driver is in use
16:39:58 bauzas if two virt drivers were proposing the same feature, then yah a trait sounds good to me
16:40:07 sean-k-mooney we can revert that if we want but i know there was pushback to that in the past
16:40:30 bauzas but here that capability is purely qemu-based
16:40:37 sean-k-mooney bauzas: so is the only reason your takign this stance because we did the min libvirt bump last cycle
16:40:43 dansmith sean-k-mooney: we have traits for which type of hardware is on the host, this seems similar, but we can also filter on hypervisor type from host state anyway right? so we can do it without a trait
16:40:50 bauzas say some other feature does the same, we gonna add another trait and another prefilter
16:41:19 sean-k-mooney bauzas: yes we should anytime thre is a capablity that is not supproted by all supproted drivers
16:41:25 bauzas and boom, traits explosion, plus the fact we yet again push hypervisor features upfront
16:41:44 sean-k-mooney bauzas: traits are cheap and placment was built to deal with many of them
16:41:59 dansmith honestly, this particular feature is probably not critical, right? meaning:
16:42:13 bauzas service version checks that can get rid next cycle are cheaper IMHO and,
16:42:21 bauzas no traits is cheaper than a single one :)=
16:42:29 dansmith if we restrict to libvirt hosts with a filter, then it's easy for us to say in the reno that if you're not upgraded that feature request will not be honored by old computes that don't know about it
16:42:36 dansmith after the upgrade it's all good
16:42:51 dansmith this is an optimization not like "I *need* 32G of memory else please reject"
16:43:01 bauzas I just feel we can say in the notes 'please do what you need in case you have mixed hypervisors'
16:43:43 sean-k-mooney bauzas: i really dislike that direction as i feel our schduler shoudl ensure you land on a host that can supprot the request feature without additonal admin intervention
16:44:25 sean-k-mooney dansmith: in this partical case if we dont have the trait it will be non critical only in that on older host it willl be ignored
16:44:26 bauzas only if you have mixed hypervisors, right?
16:44:41 sean-k-mooney bauzas: no even with a singel hypervior
16:44:45 bauzas and in that case, you probably already did the setup in order to shard your cloiud
16:44:51 dansmith sean-k-mooney: right, it just seems like a best-effort sort of thing compared to some others
16:45:06 bauzas sean-k-mooney: still talking of the 'I want a compute with libvirt recent enough' then ?
16:45:15 bauzas again, doesn't sound to me worth adding a trait for this
16:45:19 sean-k-mooney dansmith: if its a flavor extra spec we shoudl always guarentee it abel to work on the slected host
16:45:43 sean-k-mooney so if we are fine with rejecting it on the compute node sure
16:45:47 bauzas anyway, I feel we're arguing right, but the time flies and we're on a meeting
16:45:49 sean-k-mooney im not ok with allowing the vm to boot
16:46:04 bauzas can we drop this until the end of this meeting
16:46:06 bauzas ?
16:46:10 dansmith yep
16:46:14 sean-k-mooney sure or to thet spec review
16:46:18 bauzas and we could try to find a way forward just after
16:46:29 bauzas cool, moving on then
16:47:13 bauzas #topic Review Priorities
16:47:18 bauzas still an action item on me
16:47:33 bauzas I have to create an etherpad as we agreed at PTG
16:47:46 bauzas so I'll keep this bullet until I'm set
16:47:46 dvo-plv I have some issue with electricity, battery dead, so ping me and i will answer later when I will be back online
16:48:11 bauzas #action bauzas to create a tracking etherpad for this cycle
16:48:38 bauzas dvo-plv: np, we also captured this conversation in the meeting logs that'll show up once we end the meeting
16:48:57 bauzas #topic Stable Branches
16:49:03 bauzas elodilles: your time
16:49:12 elodilles #info stable gates don't seem blocked
16:49:20 elodilles (stable/victoria's nova-ceph-multistore looked suspicious as it failed with POST_FAILURE a couple of times, but it has passed now)
16:49:35 elodilles #info stable release patches proposed: https://review.opendev.org/q/project:openstack/releases+is:open+intopic:nova
16:50:03 elodilles last time we agreed to wait for some patches to merge ^^^
16:50:24 elodilles feel free to update the patch when they are merged
16:50:27 bauzas yeah and noonedeadpunk proposed backports
16:50:35 elodilles ++
16:50:38 bauzas related to the RPC fixes we wanted to land
16:50:42 bauzas so, we need reviews
16:50:54 bauzas I surely can review things I wrote
16:51:03 elodilles ACK, will review them then :)
16:51:18 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:51:30 elodilles and that's all from my side
16:51:35 bauzas elodilles: ping me if you need the change numbers
16:51:41 bauzas cool, thanks
16:51:53 bauzas rushing, we have a few time left
16:51:57 bauzas #topic Open discussion
16:52:07 bauzas (gibi): Seeking for specless approval https://blueprints.launchpad.net/nova/+spec/libvirt-migrate-with-hostname-instead-of-ip based on the PTG discussion https://etherpad.opendev.org/p/nova-caracal-ptg#L815. I have a proposed impl https://review.opendev.org/c/openstack/nova/+/900203
16:52:17 gibi so
16:52:44 gibi as we discussed on the PTG I would like to make it possible for the libvirt driver to use hostnames during cold migration instead of IP addresses
16:52:45 noonedeadpunk bauzas: fwiw, backport to Zed is failing unit tests
16:52:53 noonedeadpunk so some look there is appreciated
16:53:09 gibi the live migration already uses hostnames by default
16:53:15 dansmith gibi: ++
16:53:30 gibi this specless bp propose a new config option to make the new behavior opt in
16:53:31 bauzas noonedeadpunk: I have a clue, but let's not discuss this now (I guess this is the rpc version check unittest that fails)
16:53:31 dansmith gibi: no new RPC or object stuff needed, just a change on which thing we advertise to the remote side right?
16:53:46 sean-k-mooney dansmith: we might need a db change
16:53:47 gibi no rpc, no object, just a config option for the libvirt driver
16:53:56 dansmith sean-k-mooney: why/
16:53:58 gibi sean-k-mooney: no DB change is needed afaik

Earlier   Later