Open Stack

On Tue, Oct 6, 2020 at 3:54 PM Jeremy Stanley <fungi at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201006/d6b3be2d/attachment.html>