| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-24 | |||
| 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 | |
| 16:48:39 | sean-k-mooney | and no api change at all | |
| 16:48:44 | sean-k-mooney | we just remove the block | |
| 16:48:50 | whoami-rajat | the destructive nature of this operation was the concern from many folks, I can't name everyone but this was approved in yoga so you can see | |
| 16:48:51 | bauzas | good question | |
| 16:48:53 | sean-k-mooney | when cinder is new enough | |
| 16:49:10 | whoami-rajat | dansmith, has been actively reviewing the changes I proposed last cycle so maybe he can weigh in | |
| 16:49:49 | bauzas | whoami-rajat: frankly, if we were about adding some parameter, it would be more for *not* recreating the volume | |
| 16:50:10 | dansmith | bauzas: the point of the spec/effort is to rebuild the root volume | |
| 16:50:17 | dansmith | i.e. to reimage it, but let cinder do the reimaging | |
| 16:50:29 | bauzas | dansmith: that's what I understand | |
| 16:50:38 | bauzas | so... | |
| 16:51:37 | bauzas | tbc, I don't see a need for an API param that'd say "yes, I want to rebuild by reimaging" | |
| 16:51:56 | bauzas | which would imply that the default would be "rebuild by not reimaging" | |
| 16:52:25 | sean-k-mooney | bauzas: no default would reject | |
| 16:52:49 | sean-k-mooney | bauzas: that was the behavior that i think lee suggested but i dont think i reviewd the previous iteration | |
| 16:52:57 | dansmith | I think user-initiated rebuild where we don't reimage root is pointless right? | |
| 16:53:06 | dansmith | as long as we don't rebuild on evacuate then we're good, | |
| 16:53:06 | sean-k-mooney | correct | |
| 16:53:13 | sean-k-mooney | ya | |
| 16:53:13 | bauzas | I agree | |
| 16:53:19 | dansmith | but this is specifically to make BFV behave like regular instances | |
| 16:53:48 | sean-k-mooney | right so evacuate shoudl continue to preseve the root disk if its on shared storage | |
| 16:53:50 | bauzas | correct me if I'm wrong, but I feel we are on the same page | |