Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-08-22
16:30:30 sean-k-mooney it was not approved this cycle i think
16:30:32 kgube the spec has been merged
16:30:34 sean-k-mooney maybe last cyle
16:30:40 dansmith okay I can't find it
16:31:12 sean-k-mooney oh it was
16:31:13 kgube https://review.opendev.org/c/openstack/nova-specs/+/877233
16:31:20 sean-k-mooney https://specs.openstack.org/openstack/nova-specs/specs/2023.2/approved/use-extend-volume-completion-action.html
16:31:24 gibi https://review.opendev.org/c/openstack/nova-specs/+/877233
16:31:41 dansmith got it, wrong topic
16:32:02 kgube Anyway, the Cinder team has been slow with reviews
16:32:04 gibi does the nova side of this breaks anything without the cinder dependency?
16:32:04 sean-k-mooney ok well we can review what is the status of the cinder side
16:32:21 sean-k-mooney i dont belive so
16:32:22 kgube The is a +1, but not from the core
16:32:27 dansmith if the cinder side isn't going to be merged ASAP, I think we probably need to punt
16:32:36 dansmith and not waste time reviewing the nova side in the last two weeks
16:32:58 kgube hm, okay
16:33:57 gibi I agree
16:34:22 sean-k-mooney so if we merged the nova code the cinder volume would never be in extending so it would not break anything but i also dont like ahvign dead code espeicly when it has an api microverion
16:35:13 sean-k-mooney so ya i think we would likely want to merge both in the same release
16:35:42 sean-k-mooney strictly speaking old nova and new cinder or old cinder and new nova shoudl work with each other
16:36:13 dansmith yeah, but since it requires an api change,
16:36:44 dansmith I think we should not presumptively merge this because cinder might change their definition of what the event means, when it comes, etc and then we end up with a thing we have to technically support for no reason
16:36:47 sean-k-mooney + compute service change and min version check
16:36:51 kgube It's a bit frustrating because the Cinder change has been ready for review for weeks, and even on top of their feature tracking etherpad: https://etherpad.opendev.org/p/cinder-2023.2-bobcat-features
16:36:57 dansmith I think we've always expected these to merge in the dependent service first
16:37:10 kgube but I guess they have been very busy
16:37:16 dansmith sean-k-mooney: right, there are REST API changes, implicit RPC ones, service versions, etc
16:37:18 sean-k-mooney certenly with neutron we have
16:37:35 dansmith kgube: yeah, I definitely understand your frustration
16:37:40 gibi kgube: yes, this is frustrating
16:37:58 sean-k-mooney kgube: do you have depends on or tempest/devestack covergae to show this working by any chance
16:38:33 sean-k-mooney this is feeling more like an early pre milestone 1 type of change then the next two weeks
16:39:00 sean-k-mooney but if you have already staged the patches with depends on and can show this working in ci then that more compleing
16:39:37 kgube sean-k-mooney: It is covered by the existing online volume extend tests if you run them on an affected driver
16:39:47 dansmith no devstack change that I see
16:40:05 sean-k-mooney we do not have a cinder nfs job in novas gate
16:40:06 dansmith kgube: right, but we need to see them running against the proper driver and this change
16:40:46 sean-k-mooney the depend on relation ship si not quite right althoguh its close
16:40:52 dansmith I guess the nfs job on this patch maybe? https://review.opendev.org/c/openstack/cinder/+/873889/7?tab=change-view-tab-header-zuul-results-summary
16:40:54 kgube There is a devstack-nfs job
16:40:58 sean-k-mooney https://review.opendev.org/c/openstack/cinder/+/873686/9 woudl be the patch to make the nfs driver work
16:41:23 dansmith that patch has depends-on relationships to cinder itself, which is weird
16:41:38 sean-k-mooney ya so that patch should depend on either the nova patch
16:41:45 sean-k-mooney ro the nova patch should ideally depend on it
16:41:53 dansmith well, not reall,y
16:42:01 dansmith because you need to run a cinder patch to see that job
16:42:11 sean-k-mooney the nova patch depens on the cinder client patch which depends on https://review.opendev.org/c/openstack/cinder/+/873557/8
16:42:13 dansmith it looks like every patch in the stack depends on the thing below it or something?
16:42:16 dansmith confusing
16:42:31 dansmith this one depends on the nova patch: https://review.opendev.org/c/openstack/nova/+/873560
16:42:32 sean-k-mooney ya that will work but its not how its ment to be used
16:42:37 dansmith and the top cinder one depends on that one
16:42:48 dansmith so it's a bit convoluted
16:42:48 sean-k-mooney oh the netapp one
16:42:55 dansmith anyway kgube disconnected
16:42:58 sean-k-mooney ya so the issue is that the api change patch is first
16:43:03 dansmith so we can probably end it here and discuss later
16:43:05 sean-k-mooney and then the driver patches ar after that
16:43:10 sean-k-mooney sure
16:43:40 gibi OK
16:43:47 gibi is the any other topic before we close?
16:44:03 kgube sorry, I got disconnected
16:44:35 dansmith kgube: we were just deciphering the patch dependency network to figure out how to see a job running the whole stack
16:44:45 dansmith which I think is there, but it's convoluted
16:44:51 dansmith either way I think the answer is the same :/
16:45:17 kgube yeah, I was afraid of that
16:45:23 kgube but I can understand it
16:45:58 sean-k-mooney i dont know if cinder has the same policy as nova
16:46:11 sean-k-mooney but for nova we merge the api change last in a series
16:46:22 sean-k-mooney so the fact that is first in the cidner one is also a little odd
16:47:10 gibi I don't see any other topic being raised. So I will close the meeting and you can continue untangling the dep tree on the channel
16:47:10 kgube Well the nova change needs the new volume action
16:47:15 gibi #endmeeting
16:47:15 opendevmeet Meeting ended Tue Aug 22 16:47:15 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:47:15 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-08-22-16.00.html
16:47:15 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-08-22-16.00.txt
16:47:15 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-08-22-16.00.log.html
16:47:36 kgube and everything else is dependent on the support in nova
16:47:42 sean-k-mooney also an fyi every time you use depends on it makes zuul clone an addtional copy of the relevent repo then it does a merge of all repos with the same name
16:48:23 sean-k-mooney so while you can use a depend on in the same repo in some cases its generally not a good idea as it causes a much more complex git merge to be done
16:49:20 kgube oh, okay, so I don't need them if the changes are already ordered in a branch
16:49:45 kgube ?
16:49:58 dansmith kgube: right, a single stack of patches are necessarily dependent and ordered
16:50:15 dansmith kgube: you do need them cross-repo (i.e. cinder->nova) but not within a single branch in cinder
16:50:30 kgube dansmith: alright, thanks!
16:50:40 dansmith also, the newer way to depends-on is to use a URL to the actual change, which also makes it easier for us to see "this is the nova dependency"
16:50:58 dansmith I thought zuul actually stopped supporting the change-id way, but I guess it still works (or at least the tagging does)
16:51:29 kgube that is also good to know. I kinda just copied it from other changes that I saw
16:52:10 sean-k-mooney the reason i mentioned the depend on mechanics is i have seen it cause merge conflict in the ci jobs that done repoduce locally
16:52:15 sean-k-mooney which can be very hard to debug
16:52:23 dansmith kgube: here's an example of how it should work these days: https://review.opendev.org/c/openstack/nova/+/650172
16:52:27 sean-k-mooney i.e. using depend on in the same repo
16:53:19 kgube dansmith: thanks!
16:59:26 spencerh` sean-k-mooney: I am curious about the history with nova and libvirt tsc frequency. Is there a link to a discussion or is it possible to summarize concerns? Not expecting to get this in this cycle, but this patch has been critical for us.
16:59:35 sean-k-mooney kgube: the VolumesExtendAttachedTest test in tempest in the nfs job is skiped by hte way
16:59:49 sean-k-mooney kgube: so its not actully being tested by that job
17:00:13 sean-k-mooney spencerh`: bascially it comes done to the fact it will break live migration
17:00:30 sean-k-mooney we do not have the ablity to schdule based on the clock rate fo the hsot cpus
17:01:10 sean-k-mooney and if we allwo you to set the tsc_frequency via a host config option then we need rpc change to check comaptiablity

Earlier   Later