[tripleo][ci] RFC, supported releases of TripleO
Greetings,
I just wanted to give folks the opportunity to speak up before we make any changes. Please review https://releases.openstack.org/
As we are branching master -> victoria it looks like we can definitely remove stable/rocky from both upstream and RDO software factory. Any comments about rocky?
Stein is end of maintenance on 2020 November 11th. Any thoughts on dropping stein from upstream and rdo software factory?
Thanks! Please be specific if you have comments as to which release you are referring to.
Hi Wes,
Let me ask several questions especially about upstream maintenance.
- Will we retire stable/ocata and stable/pike, too ? It seems that these 2 branches are still open. Since we have really seen activity about these 2 branches recently. I think it is the time to retire these 2 stable branches as well.
- You didn't mention stable/queens but do you intend to keep it open ? If yes, how do we backport any fixes to queens after retiring R and S ? I suppose that we'll backport a change from master to V/U/T and then Q, with skipping R/S, but is it right ?
Thank you, Takashi
On Tue, Oct 6, 2020 at 12:18 AM Wesley Hayutin whayutin@redhat.com wrote:
Greetings,
I just wanted to give folks the opportunity to speak up before we make any changes. Please review https://releases.openstack.org/
As we are branching master -> victoria it looks like we can definitely remove stable/rocky from both upstream and RDO software factory. Any comments about rocky?
Stein is end of maintenance on 2020 November 11th. Any thoughts on dropping stein from upstream and rdo software factory?
Thanks! Please be specific if you have comments as to which release you are referring to.
On Tue, Oct 6, 2020 at 10:43 AM Takashi Kajinami tkajinam@redhat.com wrote:
Hi Wes,
Let me ask several questions especially about upstream maintenance.
- Will we retire stable/ocata and stable/pike, too ? It seems that these 2
branches are still open. Since we have really seen activity about these 2 branches recently. I think it is the time to retire these 2 stable branches as well.
you're right - while we no longer have any upstream ci running for pike/ocata - I just checked and it looks like we didn't tag the ocata/pike branches as eol - they are still active at [1][2] for example so yeah we should probably do that for these too.
[1] https://github.com/openstack/tripleo-heat-templates/branches [2] https://github.com/openstack/python-tripleoclient/branches
- You didn't mention stable/queens but do you intend to keep it open ? If
yes, how do we backport any fixes to queens after retiring R and S ?
I suppose that we'll backport a change from master to V/U/T and then Q,
with skipping R/S, but is it right ?
main reason for keeping queens is because it is part of the fast forward upgrade (ffu) ... i.e. newton->queens for ffu 1 and then queens->train for ffu 2. So indeed the backports will go as you described - to train then queens
hope it helps clarify somewhat
Thank you, Takashi
On Tue, Oct 6, 2020 at 12:18 AM Wesley Hayutin whayutin@redhat.com wrote:
Greetings,
I just wanted to give folks the opportunity to speak up before we make any changes. Please review https://releases.openstack.org/
As we are branching master -> victoria it looks like we can definitely remove stable/rocky from both upstream and RDO software factory. Any comments about rocky?
Stein is end of maintenance on 2020 November 11th. Any thoughts on dropping stein from upstream and rdo software factory?
Thanks! Please be specific if you have comments as to which release you are referring to.
On 2020-10-06 11:15:57 +0300 (+0300), Marios Andreou wrote: [...]
main reason for keeping queens is because it is part of the fast forward upgrade (ffu) ... i.e. newton->queens for ffu 1 and then queens->train for ffu 2. So indeed the backports will go as you described - to train then queens
[...]
Previous discussions highlighted the need for all stable release branches newer than a particular branch to have at least the same level of support or higher. This expectation was encoded into the Stable Branches chapter of the Project Team Guide:
https://docs.openstack.org/project-team-guide/stable-branches.html#processes
Further, fast forward upgrades aren't designed the way you're suggesting. You're expected to install each version of the software, so to go from Newton to Queens you need to install Ocata and Pike along the way to do the necessary upgrade steps, and then between Queens and Train you need to upgrade through Rocky and Stein. What's unique about FFU is simply that you don't need to start any services from the intermediate branch deployments, so the upgrades are performed "offline" so to speak.
Granted, no TripleO deliverables have the stable:follows-policy tag, so as long as you're only referring to which branches of TripleO repositories are switching to EOL you can probably do whatever you want (assuming the TC doesn't object). If TripleO's upgrade orchestration in stable/train is able to perform the Rocky and Stein intermediate deployments, it would presumably work. The service projects don't have the same luxury however, and so can only EOL a particular stable branch if all older branches are already EOL.
On Tue, Oct 6, 2020 at 3:54 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-10-06 11:15:57 +0300 (+0300), Marios Andreou wrote: [...]
main reason for keeping queens is because it is part of the fast forward upgrade (ffu) ... i.e. newton->queens for ffu 1 and then queens->train for ffu 2. So indeed the backports will go as you described - to train then queens
[...]
Previous discussions highlighted the need for all stable release branches newer than a particular branch to have at least the same level of support or higher. This expectation was encoded into the Stable Branches chapter of the Project Team Guide:
https://docs.openstack.org/project-team-guide/stable-branches.html#processes
Further, fast forward upgrades aren't designed the way you're suggesting. You're expected to install each version of the software, so to go from Newton to Queens you need to install Ocata and Pike along the way to do the necessary upgrade steps, and then between Queens and Train you need to upgrade through Rocky and Stein. What's unique about FFU is simply that you don't need to start any services from the intermediate branch deployments, so the upgrades are performed "offline" so to speak.
yes you are correct - I am at least a little familiar with ffu I used to be part of the tripleo upgrades squad around the time of queens->train "ffu 1". So indeed, you may need to merge branch specific upgrades tasks or fixes into the intermediate branches and likely this is why we have not tagged older branches (like ocata and pike) as EOL
I think there are two things in this thread. The first from weshay original mail, which doesn't clarify what 'removing stable/rocky' means - but I believe it means 'removing the ci jobs for stable/rocky' ...
I mentioned EOL and that branches are not tagged as such - to which you replied. I now understand both that we should not do that, and likely *why* ocata/pike aren't marked eol like some older branches.
Granted, no TripleO deliverables have the stable:follows-policy tag,
so as long as you're only referring to which branches of TripleO repositories are switching to EOL you can probably do whatever you
want (assuming the TC doesn't object). If TripleO's upgrade
orchestration in stable/train is able to perform the Rocky and Stein intermediate deployments, it would presumably work. The service projects don't have the same luxury however, and so can only EOL a
particular stable branch if all older branches are already EOL.
thanks for the pointers and clarification. I apologise for the confusion - as I wrote above, I was mistaken about marking branches eol. We will not be doing this.
This thread is about removing the upstream ci/rdo periodic jobs for those branches - rocky and stein to be specific
thanks, marios
-- Jeremy Stanley
On Tue, Oct 6, 2020 at 4:14 PM Marios Andreou marios@redhat.com wrote:
On Tue, Oct 6, 2020 at 3:54 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2020-10-06 11:15:57 +0300 (+0300), Marios Andreou wrote: [...]
main reason for keeping queens is because it is part of the fast forward upgrade (ffu) ... i.e. newton->queens for ffu 1 and then queens->train for ffu 2. So indeed the backports will go as you described - to train then queens
[...]
Previous discussions highlighted the need for all stable release branches newer than a particular branch to have at least the same level of support or higher. This expectation was encoded into the Stable Branches chapter of the Project Team Guide:
https://docs.openstack.org/project-team-guide/stable-branches.html#processes
Further, fast forward upgrades aren't designed the way you're suggesting. You're expected to install each version of the software, so to go from Newton to Queens you need to install Ocata and Pike along the way to do the necessary upgrade steps, and then between Queens and Train you need to upgrade through Rocky and Stein. What's unique about FFU is simply that you don't need to start any services from the intermediate branch deployments, so the upgrades are performed "offline" so to speak.
yes you are correct - I am at least a little familiar with ffu I used to be part of the tripleo upgrades squad around the time of queens->train "ffu 1".
nit... ^^^ newton to queens for ffu1 .... queens to train is ffu2
So indeed, you may need to merge branch specific upgrades tasks or fixes
into the intermediate branches and likely this is why we have not tagged older branches (like ocata and pike) as EOL
I think there are two things in this thread. The first from weshay original mail, which doesn't clarify what 'removing stable/rocky' means - but I believe it means 'removing the ci jobs for stable/rocky' ...
I mentioned EOL and that branches are not tagged as such - to which you replied. I now understand both that we should not do that, and likely *why* ocata/pike aren't marked eol like some older branches.
Granted, no TripleO deliverables have the stable:follows-policy tag,
so as long as you're only referring to which branches of TripleO repositories are switching to EOL you can probably do whatever you
want (assuming the TC doesn't object). If TripleO's upgrade
orchestration in stable/train is able to perform the Rocky and Stein intermediate deployments, it would presumably work. The service projects don't have the same luxury however, and so can only EOL a
particular stable branch if all older branches are already EOL.
thanks for the pointers and clarification. I apologise for the confusion - as I wrote above, I was mistaken about marking branches eol. We will not be doing this.
This thread is about removing the upstream ci/rdo periodic jobs for those branches - rocky and stein to be specific
so... thinking about it some more just now... i think we may need to keep some minimal ci for both rocky and stein.. in the same way we keep a smaller subset of our 'normal' jobs for queens. The reason is what fungi reminded me in his reply above... we may need to merge fixes into both rocky and stein - for example undercloud upgrade tasks or any other kind of upgrade task that will be used as part of ffu?
Unless all the ffu upgrade logic lives in the target (train in the ffu2 q->t) branch - but I doubt that for example the upgrade is at least upgraded sequentially i.e. execute the n upgrade tasks, then n+1 and so on to the target.
I will point the upgrades squad at this to comment and confirm about the q-->t ffu2
thanks
thanks, marios
-- Jeremy Stanley
participants (4)
-
Jeremy Stanley
-
Marios Andreou
-
Takashi Kajinami
-
Wesley Hayutin