Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2026-03-09
16:19:12 Uggla So if you think it is not ready, or risky, it will be for next cycle.
16:19:18 opendevreview Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979694
16:19:21 sean-k-mooney at this point if its not a regressioin intoduced this cycle i would wait until we have cut RC1
16:19:30 dansmith sean-k-mooney: ++
16:19:44 sean-k-mooney that happeinginn on thurday if i recall correctly
16:20:15 Uggla sean-k-mooney yes.
16:20:22 dansmith I'll have to look at the other fixes here like the volume stuff but I suspect they're all fairly latent state tracking things that aren't hugely recent/relevant
16:21:24 Uggla dansmith ok
16:22:03 Uggla I have nothing else. So we can move on unless someone wants to add something else.
16:22:41 opendevreview Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696
16:23:32 Uggla #topic Stable Branches
16:23:52 elodilles thanks o/
16:23:58 elodilles #info stable/2026.1 branch were cut for libraries
16:24:05 elodilles #info stable/2026.1 branch will be cut for nova and placement this week, along with RC1 releases
16:24:16 elodilles #info nova stable gates should be OK, but placement and osc-placement have blocked stable gates (setuptools/pkg_resources issue), see details in tracking pad
16:24:30 elodilles i forgot about these in the past weeks ^^^^ :S
16:24:37 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:24:49 elodilles Uggla: that's all from me about stable things
16:25:08 Uggla thx elodilles.
16:25:18 opendevreview Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696
16:26:10 Uggla #topic vmwareapi 3rd-party CI efforts Highlights
16:26:25 fwiesel Hi, no updates from my side.
16:26:41 Uggla ok thx fwiesel
16:27:37 Uggla skipping next point as gibi is not available. And eventlet was merge already.
16:27:50 Uggla #topic Nova using openstack sdk for neutron
16:28:01 lajoskatona o/
16:28:31 lajoskatona No progress since last week, as we agreed to push these patches early 26.2
16:28:55 dansmith ++ early in a cycle is the time for stuff like this :)
16:29:06 lajoskatona +1
16:29:50 Uggla yep it is what we mentionned last week. We will try to merge lajoskatona sdk client stuff earmy next cycle.
16:30:22 dansmith cool
16:30:57 Uggla #topic Open discussion
16:31:07 Uggla We have a topic from melwitt
16:32:13 melwitt hi, yes, wanted to discuss about the possibility of an exception for vtpm live migration remaining patches
16:32:51 melwitt the 'host' security mode for live migration has merged but the 'deployment' mode is still outstanding
16:33:34 melwitt the 'deployment' mode is the one where the nova service user owns the barbican secrets.
16:33:37 dansmith I haven't reviewed above what we've merged... well, except for the fixup patch
16:33:57 bauzas it will be difficult to review it for 3 days left given the RC1 deadline
16:34:13 dansmith looks like the last review from anyone on that patch was almost two years ago (Aug 2024)
16:35:04 dansmith yeah, I'm not sure how we could even consider this an FFE candidate given it's not like "reviewed but just didn't make the deadline"...
16:35:40 dansmith and as sean-k-mooney just said above, candidates for things right now should really be "regression introduced this cycle"
16:35:59 sean-k-mooney im a littel sad the deployment mode was not done first
16:36:10 sean-k-mooney but ya i think it woudl be better to finish it early next cycle
16:36:40 dansmith really? i think host is the most useful mode
16:36:53 sean-k-mooney deployment requried the least code chage
16:37:01 dansmith I guess we don't know until ops start deciding but I guess I think host is what most of them will want
16:37:05 sean-k-mooney that why i asked for it to be first since it did nto need to object change
16:37:19 sean-k-mooney but i didnt object to the current order
16:37:28 sean-k-mooney just suggested the other one was less invaisve
16:37:42 dansmith *shrug* I was more focused on getting host in because I _suspect_ it's the thing people will want
16:37:51 dansmith but yeah I get your point
16:38:37 melwitt yeah, the less change makes sense as a subset of that is what would be needed for 'user' mode live migration as well
16:38:40 sean-k-mooney anyway i woudl not be against re reviewing the spec and appoving it and contining to review/merge the feature
16:38:52 sean-k-mooney even before we offically release 2026.1
16:39:06 sean-k-mooney i just think we should take the checkpoint with rc1 and create the sable branch first
16:39:15 dansmith sean-k-mooney: you mean once rc1 is cut and master becomes 2026.2 right?
16:39:27 sean-k-mooney yep
16:39:39 dansmith yeah, agree, I don't see how it could be any other way
16:39:48 sean-k-mooney im not commeting on the readyness of the remaining patches because the last time i looked in detail was december
16:40:27 bauzas at least operators can support vtpm live migration by G, which is cool
16:40:32 dansmith last actual review on the deployment patch was you, from Aug 2024 :)
16:40:37 dansmith sean-k-mooney: ^
16:40:39 bauzas they will only set it per host
16:41:13 bauzas for the deployment support, we can make it a short-term priority for Hibiscus given the existing momentum
16:41:18 sean-k-mooney :) i deployed something in decemer and played with the series a bit before going on PTO but i have entirlly ejected that form my memory
16:41:40 dansmith sean-k-mooney: even though I get your point about minimal code change for deployment, it's still the largest perceptual change of the lot
16:41:52 dansmith sean-k-mooney: it puts the users not in control of their TPM key
16:41:57 sean-k-mooney yep
16:42:11 dansmith _that_ is why it seemed it should go last to me
16:42:39 sean-k-mooney yep i get that
16:42:48 opendevreview Thibaut Démaret proposed openstack/nova-specs master: Spec for default SSD rotation rate on instance disks https://review.opendev.org/c/openstack/nova-specs/+/979696
16:43:19 sean-k-mooney if we are agreed that this is not in socpe of a FFE are we ok to repoease and review the spec/code once rc1 is cut and master is 2026.2
16:43:43 sean-k-mooney i mean the repopposal can happen now
16:44:00 sean-k-mooney just are we ok with that directionally so we can move on to other topic or is there anything else to raise
16:44:01 dansmith yeah, are we going to just kick the whole spec to 2026.2 or trim it down to just the "...add deployment" part?
16:44:09 bauzas we can trim it if we want
16:44:13 dansmith but that detail aside, yep, good to move on
16:44:38 dansmith I think it might be nice to mark the first two modes as completed in this cycle
16:44:51 dansmith and then just deployment for 2026.2... I know that's more work for melwitt tho...
16:44:53 sean-k-mooney trim is proably better but i dont have a strong prefence either way
16:44:56 melwitt I wondered about that too. to maybe trim and then make a new blueprint also or?
16:45:27 sean-k-mooney yep that proably for the best
16:46:00 melwitt yeah I was thinking about that about being able to mark the host mode as completed tihs cycle. ok, I will do this
16:46:05 dansmith ++
16:46:10 sean-k-mooney that wasy we can close the curent oen and leave a not the the deployment part was defereed
16:46:46 melwitt ++
16:47:22 melwitt ok, thanks all for the discussion
16:48:14 Uggla melwitt just ping me when the trim is ok.
16:48:33 melwitt will do, thanks Uggla
16:48:49 Uggla so I could adjust BP and spec move patch.
16:50:04 Uggla ok I guess we are good with this topic.
16:50:30 Uggla Does someone want to discuss something else.
16:50:34 nicolairuckel Is https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/2TF4CXQUCP4Y24PAKZQGM2D5BONL5Z34/ covered by https://review.opendev.org/c/openstack/placement/+/979685? Unfortunately, that bug blocks my backports of the vTPM and NVRAM patches. :/
16:51:49 tkajinam nicolairuckel, I think that config_format problems is different but it was fixed by https://review.opendev.org/c/zuul/zuul-jobs/+/979136
16:51:56 Uggla melwitt can you answer ^ ?
16:52:08 tkajinam nicolairuckel, but we still need 979685 to fix doc job in 2025.2
16:52:20 elodilles yepp, what tkajinam says. i can second that
16:52:34 nicolairuckel thanks, I missed the first fix
16:53:08 elodilles nicolairuckel: i'll review your backport when i get there o:)
16:53:40 nicolairuckel After 979685 I can restart the CI jobs?

Earlier   Later