Open Stack

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.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201006/a8a50cda/attachment.sig>