Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-07
16:30:27 sean-k-mooney and its required in my view for as long as we have any virt driver (other then ironic and libvirt) that supprot vms
16:30:36 bauzas https://review.opendev.org/c/openstack/nova/+/876075/25/nova/virt/libvirt/driver.py
16:30:57 bauzas that exactly models the libvirt version
16:31:14 dansmith not really
16:31:16 sean-k-mooney its the only way to detect it because libvirt does not have a way to detect it without a version check
16:31:19 sean-k-mooney but
16:31:26 sean-k-mooney since we now have the min versio nrequiremnet
16:31:31 dansmith it's exposing whether or not the feature is supported, but the way it does that is by the libvirt version internally
16:31:40 sean-k-mooney this would be a static trait that is exposed by computes using the libvirt driver
16:31:42 dansmith that's different than exposing a trait of the actual version
16:31:52 sean-k-mooney dansmith: exactly
16:31:54 bauzas sean-k-mooney: then I'd suggest a prefilter that would only ensure that we land on a libvirt hostr
16:32:08 dansmith the prefilter can be the trait though
16:32:15 sean-k-mooney bauzas: i belive the prefilter was aldreay in the spec
16:32:34 sean-k-mooney bauzas: its somethign i have defintly dicussed for this feature previously
16:32:37 bauzas yeah, but again, I don't like us adding yet another trait for this
16:32:56 sean-k-mooney bauzas: i belive this is exactly what traits shoudl be used for
16:32:58 dansmith but this is what we do right? all the other traits are just like this I think
16:33:08 sean-k-mooney dansmith: more or less
16:33:17 bauzas then, let's just provide this trait without a conditional
16:33:28 sean-k-mooney bauzas: yes i also said that in my comments
16:33:40 sean-k-mooney and i said this last cycle too when we origianlly proposed it
16:33:41 bauzas if it's really about directing to libvirt nodes
16:33:41 dansmith we can do that if we hard-require the min version
16:34:20 sean-k-mooney bauzas: basically the context yoru missing is we had prviously agree that if we enforced the min verison we would update the sepc depending on which feature landed first
16:34:27 sean-k-mooney kasyaps min version bump
16:34:29 sean-k-mooney or this feature
16:34:48 sean-k-mooney in the repopoal it should be updated to drop the check because the min verion bump already happend in bobcat
16:35:05 dansmith so to be clear, we're already hard-requiring the min version needed for this, and thus the trait is just for the upgrade case where we might have old computes?
16:35:11 opendevreview Dmitriy Rabotyagov proposed openstack/nova stable/zed: Fix rebuild compute RPC API exception for rolling-upgrades https://review.opendev.org/c/openstack/nova/+/900341
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

Earlier   Later