| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-24 | |||
| 16:21:00 | bauzas | #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Naming bikeshed in there. | |
| 16:21:06 | bauzas | #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have | |
| 16:21:39 | bauzas | I provided a comment for https://review.opendev.org/c/openstack/project-config/+/837595 | |
| 16:21:43 | bauzas | please review it | |
| 16:21:58 | gibi | done :) | |
| 16:22:38 | bauzas | thanks | |
| 16:22:50 | bauzas | at least I'm French so in general I'm not good at naming things | |
| 16:23:06 | bauzas | but at least I try to find a consensus | |
| 16:23:14 | gibi | thank you for that | |
| 16:23:39 | bauzas | I think all contributors know what nova-core means | |
| 16:23:52 | bauzas | hopefully | |
| 16:24:15 | gibi | that is a fair assumption | |
| 16:24:35 | bauzas | for other repos, we could name the label differently of course, like 'osvif-core' if this is named by gerrit | |
| 16:25:21 | bauzas | ie. nova-specs-core review promise | |
| 16:25:31 | bauzas | os-vif-core etc. | |
| 16:25:41 | bauzas | but this is a naming bikeshed | |
| 16:26:24 | bauzas | anyway, moving on | |
| 16:26:32 | bauzas | #topic Stable Branches | |
| 16:26:40 | bauzas | in general I ask elodilles | |
| 16:26:46 | bauzas | but this time, let me do it | |
| 16:26:52 | bauzas | #info ussuri and older branches are still blocked, newer branches should be OK | |
| 16:27:03 | bauzas | melwitt had a point | |
| 16:27:33 | elodilles | just an update for that ^^^ i think ussuri is blocked but the older branches are not blocked anymore | |
| 16:27:47 | bauzas | #link https://etherpad.opendev.org/p/nova-stable-branch-ci stable branches CI issues tracking, feel free to update with stable branch CI issues | |
| 16:27:58 | bauzas | elodilles: woah | |
| 16:28:11 | bauzas | kudos to the team then | |
| 16:28:13 | elodilles | bauzas: l-c branches were merged | |
| 16:28:32 | elodilles | bauzas: i don't say they don't have intermittent failures though o:) | |
| 16:28:43 | bauzas | elodilles: I thought most of the issues were related to volume detach things, which are unrelated to l-c | |
| 16:28:44 | elodilles | but at least they are not blocked | |
| 16:28:48 | bauzas | ah | |
| 16:29:23 | bauzas | elodilles: but then, why ussuri is blocked while older not ? | |
| 16:29:47 | elodilles | ussuri and train were where tempest were not pinned, | |
| 16:29:58 | elodilles | and where tempest is running with py36 | |
| 16:30:08 | elodilles | if i'm not mistaken that's it | |
| 16:30:21 | elodilles | and gmann's train fix has landed | |
| 16:31:04 | bauzas | ok thanks | |
| 16:31:05 | elodilles | originally we thought that ussuri does not need a fix as it has zuulv3 jobs already, but that's not true unfortunately | |
| 16:31:21 | bauzas | gmann told me he couldn't attend this meeting, so let's discuss this again next week | |
| 16:31:33 | elodilles | i mean, it has zuulv3 jobs, but still we are facing with the same issue | |
| 16:31:42 | elodilles | bauzas: ++ | |
| 16:31:43 | gibi | so I think the next step is still to gather the intermitten failures and try to fix them | |
| 16:32:02 | bauzas | gibi: yeah, we'll track those on a weekly basis thanks to the etherpad | |
| 16:32:12 | gibi | ack | |
| 16:32:31 | elodilles | thanks melwitt for starting the etherpad \o/ | |
| 16:32:37 | bauzas | yup, melwitt++ | |
| 16:34:29 | bauzas | anything to discuss about those intermittent issues btw. ? | |
| 16:35:30 | elodilles | i guess we still need to collect them to have the full picture | |
| 16:35:36 | bauzas | yup | |
| 16:36:32 | gibi | yepp | |
| 16:37:11 | elodilles | maybe one note: for placement we don't have periodic-stable on wallaby and older | |
| 16:37:45 | bauzas | :/ | |
| 16:37:49 | gibi | elodilles: do you suspect some instability in placement? | |
| 16:38:14 | elodilles | gibi: nope, but the gate is broken in wallaby and older in placement | |
| 16:38:16 | gibi | or is this just proactively running some jobbs | |
| 16:38:25 | gibi | broken?! | |
| 16:38:27 | elodilles | gibi: see melwitt's etherpad | |
| 16:38:28 | gibi | that is bad :/ | |
| 16:38:46 | elodilles | though probably they are some known issues to fix | |
| 16:39:09 | gibi | I agree to add some periodic there then | |
| 16:39:25 | elodilles | gibi: ack, i can backport the patch that added the periodic | |
| 16:39:39 | elodilles | * periodic-stable | |
| 16:40:18 | bauzas | gibi: agreed too | |
| 16:41:04 | bauzas | moving on ? | |
| 16:41:14 | elodilles | bauzas: ++ | |
| 16:41:24 | bauzas | #topic Open discussion | |
| 16:41:29 | bauzas | (whoami-rajat) Discuss regarding the design of rebuild volume backed instance feature | |
| 16:41:35 | bauzas | whoami-rajat: your turn | |
| 16:41:35 | whoami-rajat | Hi | |
| 16:41:39 | whoami-rajat | thanks | |
| 16:41:52 | whoami-rajat | #link https://review.opendev.org/c/openstack/nova-specs/+/840155 | |
| 16:42:20 | whoami-rajat | So I started working on this feature in yoga (this was proposed/reproposed several times before) and the spec got approved | |
| 16:42:41 | whoami-rajat | now while reproposing it, sean-k-mooney has some concerns regarding the new parameter we are introducing ``reimage_boot_volume`` | |
| 16:43:01 | whoami-rajat | it's a request parameter to tell the API, we are performing rebuild on a volume backed instance and not an ephemeral disk | |
| 16:43:13 | sean-k-mooney | yep | |
| 16:43:28 | whoami-rajat | initially the idea was not to have feature parity between both workflows but later there were many concerns with this operation being destructive | |
| 16:43:38 | whoami-rajat | even if you follow past specs, the concern has been discussed | |
| 16:44:15 | whoami-rajat | so lyarwood suggested to add this parameter ``reimage_boot_volume`` so any user who would like to opt in for this (as it has data loss risk) would only be able to do it | |
| 16:44:22 | sean-k-mooney | i really think that havign feature partiy btween bfv=True|false is imporant | |
| 16:44:38 | sean-k-mooney | i dont think the data loss argument holds | |
| 16:44:57 | sean-k-mooney | my reason is tha thtis is a deliberate instance action to rebuild the root disk | |
| 16:45:06 | gibi | rebuild is destructive for image bases instances too | |
| 16:45:11 | sean-k-mooney | yep | |
| 16:45:30 | sean-k-mooney | and rebuild is not the same as evacuate | |
| 16:45:31 | whoami-rajat | yes but the destructive operation is performed by cinder in this case where the volume resides on the cinder side | |
| 16:45:45 | sean-k-mooney | for evacuate we shoudl preserve the data | |
| 16:45:48 | bauzas | that's the whole purpose of this spec | |
| 16:45:58 | sean-k-mooney | for rebuild via the api we shoudl reimage the root volume | |
| 16:46:01 | bauzas | rebuild on BFV wasn't destructive, right? | |
| 16:46:14 | sean-k-mooney | rebuild was rejected | |
| 16:46:16 | sean-k-mooney | for bfv | |
| 16:46:17 | whoami-rajat | we didn't support rebuild on BFV | |
| 16:46:34 | sean-k-mooney | so the wole point is to allow rebuild with bfv | |
| 16:46:50 | bauzas | if so, there is a clear implication of what rebuild means for the root disk | |
| 16:47:13 | bauzas | we blocked because we were unable to rebuild the root disk if bfv | |
| 16:47:19 | sean-k-mooney | and technialy extra ephmeral disks | |
| 16:47:28 | sean-k-mooney | bauzas: correct | |
| 16:48:05 | bauzas | then, I don't see a need for differenciating BFV and non-BFV from an API pov | |
| 16:48:20 | bauzas | both will be destructive for the root disk | |
| 16:48:33 | sean-k-mooney | if so we also do not need an api microversion correct | |