Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-11-07
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
16:54:03 bauzas and this is per-computes ?
16:54:06 dansmith gibi: cool, ++ for specless BP from me
16:54:16 gibi bauzas: this is per compute for the incoming migrations
16:54:19 sean-k-mooney dont we look up the remote systme "connection" info via fiels in the obejct
16:54:22 sean-k-mooney that are stored in teh db
16:54:28 gibi it is in the migration object
16:54:32 gibi we store the IP there today
16:54:34 gibi as a string
16:54:39 dansmith but it's just a string, AFAIK
16:54:43 sean-k-mooney right so will the content of that change
16:54:44 bauzas yeah
16:54:46 gibi now it will be either IP or a hostname
16:54:54 sean-k-mooney ok that is what i was wondering about
16:55:12 bauzas and we said it was opt-in
16:55:18 sean-k-mooney ok provided we dont assume that its an ip anywhere today
16:55:19 bauzas so this is not a breaking upgrade change
16:55:23 sean-k-mooney and given its opt in
16:55:30 gibi it is opt-in the default of the new config is to use my_ip as before
16:55:30 sean-k-mooney i think im fine with that as specless
16:55:35 bauzas yeah, so I'm favor of approving it
16:55:44 bauzas any concerns ?
16:56:07 sean-k-mooney the only thing we need to do is docuemnt that you shoudl not set the new config option until the cloud is fully upgraded
16:56:21 sean-k-mooney it will likely work with the hostname

Earlier   Later