[cinder][all] Cinder to EOL all EM branches
Hi All,
This is a followup to my last email[1] where a lot of discussion happened around the nature of EM branches and was/is it a successful model or not.
This was also discussed during the Vancouver summit + PTG event and also recently in the TC meeting concluding that we will start a discussion again on ML regarding the EM model.
However, my original intent of the mail was not to start a wider discussion about the EM model (which is a good discussion but not my intent) but a way to take feedback on Cinder team's decision to EOL the current EM branches and if it affects any operators, vendors etc.
This mail is another reminder and a way to acquire more feedback on the above decision so the Cinder team can plan the process accordingly. We already have patches proposed to EOL all EM branches[2].
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-June/033980.htm... [2] https://review.opendev.org/q/topic:cinder-eol-june2023
Thanks Rajat Dhasmana
---- On Wed, 05 Jul 2023 06:17:18 -0700 Rajat Dhasmana wrote ---
Hi All,
This is a followup to my last email[1] where a lot of discussion happenedaround the nature of EM branches and was/is it a successful model or not. This was also discussed during the Vancouver summit + PTG event and alsorecently in the TC meeting concluding that we will start a discussion again onML regarding the EM model. However, my original intent of the mail was not to start a wider discussion aboutthe EM model (which is a good discussion but not my intent) but a way to takefeedback on Cinder team's decision to EOL the current EM branches and if itaffects any operators, vendors etc. This mail is another reminder and a way to acquire more feedback on the abovedecision so the Cinder team can plan the process accordingly. We already havepatches proposed to EOL all EM branches[2].
Thanks Rajat for pushing the EM discussion. But the consensus on EM future as community and Cinder moving all EM to EOL are closely related. Even though we were not able to get any solution to existing EM issue and TC is working on that and hopefully we will come to the agreement soon (even it might be killing the EM process).
If Cinder make all their EM to EOL, it will end up other integrated projects to do the same because of how complex the testing will be and if any CVE need fix in project A also need fix in Cinder repo.
IMO, we should wait for overall decision on EM so that we can keep consistency to our operator. Whatever the agreement will be, it will be same for all projects and give a clear consistency to Operators.
-gmann
[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-June/033980.htm... ThanksRajat Dhasmana
On 2023-07-05 11:14:21 -0700 (-0700), Ghanshyam Mann wrote: [...]
Even though we were not able to get any solution to existing EM issue and TC is working on that and hopefully we will come to the agreement soon (even it might be killing the EM process).
[...]
IMO, we should wait for overall decision on EM so that we can keep consistency to our operator. Whatever the agreement will be, it will be same for all projects and give a clear consistency to Operators.
[...]
While I appreciate that this decision on the part of the Cinder contributors puts the overall OpenStack community in a bit of a quandary, it would be good to let them know how long they're being asked to wait for official feedback from the TC, so that they can proceed with their original plan (backed by existing stable maintenance policy) if the debate continues to drag out. Can the TC please commit to reaching a conclusion by some specific deadline?
Thanks for making that point Jeremy.
As a courtesy to allow the TC to provide a resolution with coordinated guidelines for EOL-ing branches across projects, we please ask that you wait until the end of July at the latest.
If no consensus has been reached on approving a new EM policy has been reached until the end of July, it is within your power, as the policy is written today, to EOL all branches based on an internal team decision.
As every TC policy resolution requires staying open for at least 1 week, and taking into account 1-2 weeks of deliberation, that is the earliest that we can reasonably approve a new policy.
Thank you, Kristi Nikolla
On Jul 5, 2023, at 4:18 PM, Jeremy Stanley fungi@yuggoth.org wrote:
On 2023-07-05 11:14:21 -0700 (-0700), Ghanshyam Mann wrote: [...]
Even though we were not able to get any solution to existing EM issue and TC is working on that and hopefully we will come to the agreement soon (even it might be killing the EM process).
[...]
IMO, we should wait for overall decision on EM so that we can keep consistency to our operator. Whatever the agreement will be, it will be same for all projects and give a clear consistency to Operators.
[...]
While I appreciate that this decision on the part of the Cinder contributors puts the overall OpenStack community in a bit of a quandary, it would be good to let them know how long they're being asked to wait for official feedback from the TC, so that they can proceed with their original plan (backed by existing stable maintenance policy) if the debate continues to drag out. Can the TC please commit to reaching a conclusion by some specific deadline? -- Jeremy Stanley
---- On Thu, 06 Jul 2023 10:05:29 -0700 Nikolla, Kristi wrote ---
Thanks for making that point Jeremy.
As a courtesy to allow the TC to provide a resolution with coordinated guidelines for EOL-ing branches across projects, we please ask that you wait until the end of July at the latest.
If no consensus has been reached on approving a new EM policy has been reached until the end of July, it is within your power, as the policy is written today, to EOL all branches based on an internal team decision.
As every TC policy resolution requires staying open for at least 1 week, and taking into account 1-2 weeks of deliberation, that is the earliest that we can reasonably approve a new policy.
Also, we will be discussing it in next TC meeting in Tuesday video call. if no consensus in that meeting, I will send more call invite so that we can discuss this in speedy way.
Everyone are welcome to join the TC call in that discussion.
- https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
-gmann
Thank you, Kristi Nikolla
On Jul 5, 2023, at 4:18 PM, Jeremy Stanley fungi@yuggoth.org> wrote:
On 2023-07-05 11:14:21 -0700 (-0700), Ghanshyam Mann wrote: [...]
Even though we were not able to get any solution to existing EM issue and TC is working on that and hopefully we will come to the agreement soon (even it might be killing the EM process).
[...]
IMO, we should wait for overall decision on EM so that we can keep consistency to our operator. Whatever the agreement will be, it will be same for all projects and give a clear consistency to Operators.
[...]
While I appreciate that this decision on the part of the Cinder contributors puts the overall OpenStack community in a bit of a quandary, it would be good to let them know how long they're being asked to wait for official feedback from the TC, so that they can proceed with their original plan (backed by existing stable maintenance policy) if the debate continues to drag out. Can the TC please commit to reaching a conclusion by some specific deadline? -- Jeremy Stanley
On 7/6/23 1:05 PM, Nikolla, Kristi wrote: [snip]
As a courtesy to allow the TC to provide a resolution with coordinated guidelines for EOL-ing branches across projects, we please ask that you wait until the end of July at the latest.
[snip]
This seems reasonable to me. The Cinder project has announced its intentions, namely, that we will not fix the gates for any of the branches currently in EM, and that the EOL tags will (eventually) be made at the hashes indicated in the proposed release patches:
https://review.opendev.org/q/topic:cinder-eol-june2023
If anyone in the wider OpenStack Community has a desire to have backports merged into these branches, or to keep these branches open longer, now would be a good time to step up and do all appropriate work to make that happen.
cheers, brian
Here's an update on how this issue is shaping up.
As a reminder, the issue is that the Cinder project team has proposed to EOL and delete all current EM branches (that is, stable/train through stable/xena) due to the complexity of coordinating a fix for CVE-2023-2088 across all affected projects in the EM branches. Given the badness of CVE-2023-2088, the team did not want any unfixed branches sitting around for people to use.
In the meantime, there has been a Forum session at the recent OpenInfra Summit and ongoing discussion in the TC culminating in the following proposal that I believe is coming close to agreement:
"Unmaintained status replaces Extended Maintenance" https://review.opendev.org/c/openstack/governance/+/888771
Here's my understanding of how the new Unmaintained status (and its transition plan) impacts the Cinder team's proposal to EOL all the EM branches.
1. stable/train and stable/ussuri can be tagged EOL and deleted. (For cinder, at least, stein and older are already EOL.)
2. stable/victoria, stable/wallaby, and stable/xena will immediately transition from EM to Unmaintained status. This means that the Cinder project team has *no obligations* with respect to maintaining these branches or their gates. (Technically, we never did, but now it will be completely clear.) The branches will be renamed to unmaintained/victoria, unmaintained/wallaby, and unmaintained/xena to make their Unmaintained status unmistakable.
The maintenance of the Unmaintained branches will fall to a cinder-unmaintained-core team, whose exact composition is still under discussion on [0], but which will be completely separate from the cinder-core and cinder-stable-maint teams. The cinder-core and cinder-stable-maint members have no obligation to participate in cinder-unmaintained-core (though they can if they want to).
3. The existence and ultimate EOL and deletion of unmaintained/{victoria,wallaby,xena} will follow the Unmaintained branch policy. A sketch of what this means over the next few cycles is mapped out in this etherpad: https://etherpad.opendev.org/p/24gf87QcmV6xF4StbLQx
This email you are reading right now only concerns the way the new Unmaintained status proposal affects the Cinder project's plans with respect to the current Extended Maintenance branches. I encourage everyone to read the full proposal [0] to understand how Unmaintained status will be applied across all projects going forward.
My personal opinion is that Unmaintained status and its transition plan addresses the concerns of the Cinder project team with respect to the current EM branches; the Cinder team will decide the team's position on this issue at today's weekly meeting (1400 UTC) [1].
cheers, brian
[0] https://review.opendev.org/c/openstack/governance/+/888771 [1] https://etherpad.opendev.org/p/cinder-bobcat-meetings
On 7/6/23 2:01 PM, Brian Rosmaita wrote:
On 7/6/23 1:05 PM, Nikolla, Kristi wrote: [snip]
As a courtesy to allow the TC to provide a resolution with coordinated guidelines for EOL-ing branches across projects, we please ask that you wait until the end of July at the latest.
[snip]
This seems reasonable to me. The Cinder project has announced its intentions, namely, that we will not fix the gates for any of the branches currently in EM, and that the EOL tags will (eventually) be made at the hashes indicated in the proposed release patches:
https://review.opendev.org/q/topic:cinder-eol-june2023
If anyone in the wider OpenStack Community has a desire to have backports merged into these branches, or to keep these branches open longer, now would be a good time to step up and do all appropriate work to make that happen.
cheers, brian
On Wed, Jul 26, 2023 at 2:56 PM Brian Rosmaita rosmaita.fossdev@gmail.com wrote:
Here's an update on how this issue is shaping up.
As a reminder, the issue is that the Cinder project team has proposed to EOL and delete all current EM branches (that is, stable/train through stable/xena) due to the complexity of coordinating a fix for CVE-2023-2088 across all affected projects in the EM branches. Given the badness of CVE-2023-2088, the team did not want any unfixed branches sitting around for people to use.
In the meantime, there has been a Forum session at the recent OpenInfra Summit and ongoing discussion in the TC culminating in the following proposal that I believe is coming close to agreement:
"Unmaintained status replaces Extended Maintenance" https://review.opendev.org/c/openstack/governance/+/888771
For clarity, will this new model affect all the OpenStack projects or is it an alternative to the current EM model based on each project election?
Best regards,
Alfredo
Here's my understanding of how the new Unmaintained status (and its transition plan) impacts the Cinder team's proposal to EOL all the EM branches.
- stable/train and stable/ussuri can be tagged EOL and deleted. (For
cinder, at least, stein and older are already EOL.)
- stable/victoria, stable/wallaby, and stable/xena will immediately
transition from EM to Unmaintained status. This means that the Cinder project team has *no obligations* with respect to maintaining these branches or their gates. (Technically, we never did, but now it will be completely clear.) The branches will be renamed to unmaintained/victoria, unmaintained/wallaby, and unmaintained/xena to make their Unmaintained status unmistakable.
The maintenance of the Unmaintained branches will fall to a cinder-unmaintained-core team, whose exact composition is still under discussion on [0], but which will be completely separate from the cinder-core and cinder-stable-maint teams. The cinder-core and cinder-stable-maint members have no obligation to participate in cinder-unmaintained-core (though they can if they want to).
- The existence and ultimate EOL and deletion of
unmaintained/{victoria,wallaby,xena} will follow the Unmaintained branch policy. A sketch of what this means over the next few cycles is mapped out in this etherpad: https://etherpad.opendev.org/p/24gf87QcmV6xF4StbLQx
This email you are reading right now only concerns the way the new Unmaintained status proposal affects the Cinder project's plans with respect to the current Extended Maintenance branches. I encourage everyone to read the full proposal [0] to understand how Unmaintained status will be applied across all projects going forward.
My personal opinion is that Unmaintained status and its transition plan addresses the concerns of the Cinder project team with respect to the current EM branches; the Cinder team will decide the team's position on this issue at today's weekly meeting (1400 UTC) [1].
cheers, brian
[0] https://review.opendev.org/c/openstack/governance/+/888771 [1] https://etherpad.opendev.org/p/cinder-bobcat-meetings
On 7/6/23 2:01 PM, Brian Rosmaita wrote:
On 7/6/23 1:05 PM, Nikolla, Kristi wrote: [snip]
As a courtesy to allow the TC to provide a resolution with coordinated guidelines for EOL-ing branches across projects, we please ask that you wait until the end of July at the latest.
[snip]
This seems reasonable to me. The Cinder project has announced its intentions, namely, that we will not fix the gates for any of the branches currently in EM, and that the EOL tags will (eventually) be made at the hashes indicated in the proposed release patches:
https://review.opendev.org/q/topic:cinder-eol-june2023
If anyone in the wider OpenStack Community has a desire to have backports merged into these branches, or to keep these branches open longer, now would be a good time to step up and do all appropriate work to make that happen.
cheers, brian
On 2023-07-26 18:41:05 +0200 (+0200), Alfredo Moralejo Alonso wrote: [...]
For clarity, will this new model affect all the OpenStack projects or is it an alternative to the current EM model based on each project election?
[...]
All OpenStack projects. The proposed idea is to get rid of the "Extended Maintenance" phase for stable/.* branches completely, so once normal maintenance ends for a branch it is renamed to unmaintained/.* to more clearly communicate the lack of official maintenance by its corresponding developer/reviewer team. Make sure you read the current text of the proposed resolution at https://review.opendev.org/888771 though. It does say "The phase of Extended Maintenance for a branch is renamed to Unmaintained." and makes no mention of introducing per-project schedules for the end of the "maintained" phase.
Since end of "maintained" is project-wide per the chart at https://releases.openstack.org/ it stands to reason that projects will continue to coordinate the end date of that phase. For example, 2023.1 a.k.a. "Antelope" is expected to end its maintained phase around 2024-09-22, so if the current proposal were to be approved by the TC, that means that around 2024-09-22 the stable/2023.1 branches of all branched projects would be deleted and new unmaintained/2023.1 branches created from their prior state. Anyone pulling from the old stable/2023.1 branches would get an error from Git that the remote no longer exists, and they would need to start checking out unmaintained/2023.1 instead if they intended to continue using that source past the end of the maintained phase.
On 2023-07-26 17:11:07 +0000 (+0000), Jeremy Stanley wrote: [...]
once normal maintenance ends for a branch it is renamed to unmaintained/.*
[...]
Just to correct my own phrasing here, it's technically not "renaming" the branch since Git doesn't have the concept of remote branch rename tracking. As I state correctly later in my reply, it's actually deletion of the stable branch and creation of a new unmaintained branch with the same history. Git clients will see the old branch cease to exist on the remote, and the appearance of a new branch which they can choose to checkout/track/pull if they wish.
---- On Wed, 26 Jul 2023 10:11:07 -0700 Jeremy Stanley wrote ---
On 2023-07-26 18:41:05 +0200 (+0200), Alfredo Moralejo Alonso wrote: [...]
For clarity, will this new model affect all the OpenStack projects or is it an alternative to the current EM model based on each project election?
[...]
All OpenStack projects. The proposed idea is to get rid of the "Extended Maintenance" phase for stable/.* branches completely, so once normal maintenance ends for a branch it is renamed to unmaintained/.* to more clearly communicate the lack of official maintenance by its corresponding developer/reviewer team. Make sure you read the current text of the proposed resolution at https://review.opendev.org/888771 though. It does say "The phase of Extended Maintenance for a branch is renamed to Unmaintained." and makes no mention of introducing per-project schedules for the end of the "maintained" phase.
Since end of "maintained" is project-wide per the chart at https://releases.openstack.org/ it stands to reason that projects will continue to coordinate the end date of that phase. For example, 2023.1 a.k.a. "Antelope" is expected to end its maintained phase around 2024-09-22, so if the current proposal were to be approved by the TC, that means that around 2024-09-22 the stable/2023.1 branches of all branched projects would be deleted and new unmaintained/2023.1 branches created from their prior state. Anyone pulling from the old stable/2023.1 branches would get an error from Git that the remote no longer exists, and they would need to start checking out unmaintained/2023.1 instead if they intended to continue using that source past the end of the maintained phase.
As Jeremy mentioned, it will apply to all the projects and replace the existing "Extended Maintenance" model. Once we merge the TC resolution, we will also update the project-team-guide document for details.
Along with the "stable/2023.1 -> unmaintained/2023.1" transition (which is our SLURP release model), TC resolution proposes the plan for the existing EM branches also (currently, those are stable/rocky till stable/xena ). Considering they are 6-month upgradable releases only (pre-SLURP model releases), the current proposal for existing EM branches is to automatically move only the three latest EM branches to unmaintained, which will be:
1. stable/xena -> unmaintained/xena 2. stable/wallaby -> unmaintained/wallaby 3. stable/victoria -> unmaintained/victoria
If the project team finds that there are no maintainers or interest in those three branches, it is possible to move them to EOL.
This is the in-progress proposal, feel free to comment on Gerrit if you have any feedback or improvement points in this.
-gmann
-- Jeremy Stanley
---- On Wed, 26 Jul 2023 10:29:37 -0700 Ghanshyam Mann wrote ---
---- On Wed, 26 Jul 2023 10:11:07 -0700 Jeremy Stanley wrote ---
On 2023-07-26 18:41:05 +0200 (+0200), Alfredo Moralejo Alonso wrote: [...]
For clarity, will this new model affect all the OpenStack projects or is it an alternative to the current EM model based on each project election?
[...]
All OpenStack projects. The proposed idea is to get rid of the "Extended Maintenance" phase for stable/.* branches completely, so once normal maintenance ends for a branch it is renamed to unmaintained/.* to more clearly communicate the lack of official maintenance by its corresponding developer/reviewer team. Make sure you read the current text of the proposed resolution at https://review.opendev.org/888771 though. It does say "The phase of Extended Maintenance for a branch is renamed to Unmaintained." and makes no mention of introducing per-project schedules for the end of the "maintained" phase.
Since end of "maintained" is project-wide per the chart at https://releases.openstack.org/ it stands to reason that projects will continue to coordinate the end date of that phase. For example, 2023.1 a.k.a. "Antelope" is expected to end its maintained phase around 2024-09-22, so if the current proposal were to be approved by the TC, that means that around 2024-09-22 the stable/2023.1 branches of all branched projects would be deleted and new unmaintained/2023.1 branches created from their prior state. Anyone pulling from the old stable/2023.1 branches would get an error from Git that the remote no longer exists, and they would need to start checking out unmaintained/2023.1 instead if they intended to continue using that source past the end of the maintained phase.
As Jeremy mentioned, it will apply to all the projects and replace the existing "Extended Maintenance" model. Once we merge the TC resolution, we will also update the project-team-guide document for details.
Along with the "stable/2023.1 -> unmaintained/2023.1" transition (which is our SLURP release model), TC resolution proposes the plan for the existing EM branches also (currently, those are stable/rocky till stable/xena ). Considering they are 6-month upgradable releases only (pre-SLURP model releases), the current proposal for existing EM branches is to automatically move only the three latest EM branches to unmaintained, which will be:
- stable/xena -> unmaintained/xena
- stable/wallaby -> unmaintained/wallaby
- stable/victoria -> unmaintained/victoria
If the project team finds that there are no maintainers or interest in those three branches, it is possible to move them to EOL.
To clarify, after moving them to 'unmaintained' if there is no maintainers/interest, then the project team can propose moving them to EOL (but let's see how it goes and we should give enough time to communicate it to operators/users).
-gmann
This is the in-progress proposal, feel free to comment on Gerrit if you have any feedback or improvement points in this.
-gmann
-- Jeremy Stanley
On Wed, Jul 26, 2023 at 7:46 PM Ghanshyam Mann gmann@ghanshyammann.com wrote:
---- On Wed, 26 Jul 2023 10:29:37 -0700 Ghanshyam Mann wrote ---
---- On Wed, 26 Jul 2023 10:11:07 -0700 Jeremy Stanley wrote ---
On 2023-07-26 18:41:05 +0200 (+0200), Alfredo Moralejo Alonso wrote: [...]
For clarity, will this new model affect all the OpenStack projects or is it an alternative to the current EM model based on each project election?
[...]
All OpenStack projects. The proposed idea is to get rid of the "Extended Maintenance" phase for stable/.* branches completely, so once normal maintenance ends for a branch it is renamed to unmaintained/.* to more clearly communicate the lack of official maintenance by its corresponding developer/reviewer team. Make sure you read the current text of the proposed resolution at https://review.opendev.org/888771 though. It does say "The phase of Extended Maintenance for a branch is renamed to Unmaintained." and makes no mention of introducing per-project schedules for the end of the "maintained" phase.
Since end of "maintained" is project-wide per the chart at https://releases.openstack.org/ it stands to reason that projects will continue to coordinate the end date of that phase. For example, 2023.1 a.k.a. "Antelope" is expected to end its maintained phase around 2024-09-22, so if the current proposal were to be approved by the TC, that means that around 2024-09-22 the stable/2023.1 branches of all branched projects would be deleted and new unmaintained/2023.1 branches created from their prior state. Anyone pulling from the old stable/2023.1 branches would get an error from Git that the remote no longer exists, and they would need to start checking out unmaintained/2023.1 instead if they intended to continue using that source past the end of the maintained phase.
As Jeremy mentioned, it will apply to all the projects and replace the
existing
"Extended Maintenance" model. Once we merge the TC resolution, we will also update the project-team-guide document for details.
Along with the "stable/2023.1 -> unmaintained/2023.1" transition (which
is
our SLURP release model), TC resolution proposes the plan for the
existing EM
branches also (currently, those are stable/rocky till stable/xena ).
Considering they
are 6-month upgradable releases only (pre-SLURP model releases), the
current proposal
for existing EM branches is to automatically move only the three latest
EM branches to
unmaintained, which will be:
- stable/xena -> unmaintained/xena
- stable/wallaby -> unmaintained/wallaby
- stable/victoria -> unmaintained/victoria
If the project team finds that there are no maintainers or interest in
those three branches, it is
possible to move them to EOL.
To clarify, after moving them to 'unmaintained' if there is no maintainers/interest, then the project team can propose moving them to EOL (but let's see how it goes and we should give enough time to communicate it to operators/users).
-gmann
Thanks both for the explanations!
Alfredo
This is the in-progress proposal, feel free to comment on Gerrit if you
have any feedback or improvement
points in this.
-gmann
-- Jeremy Stanley
participants (6)
-
Alfredo Moralejo Alonso
-
Brian Rosmaita
-
Ghanshyam Mann
-
Jeremy Stanley
-
Nikolla, Kristi
-
Rajat Dhasmana