Open Stack

On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney <smooney at redhat.com> wrote:

> too me this feels like we are leaking downstream product lifecycle into
> upstream.
> even if redhat is overwhelmingly the majority contibutor of reviews and
> commits to
> ooo im not sure that changing the upstream lifestyle to align more closely
> with our product life
> cycle is the correct thing to do.
>

I wouldn't characterize it as "leaking". Instead, we are aiming to
accurately reflect what we intend to support as a community (not as any
company), based on who we have working on this project.

Unfortunately the reality is that no one (community or otherwise) should
use TripleO from rocky/stein/ussuri/victoria other than for dev/test in my
opinion. There's no upgrade path from any of those releases, and the
community isn't working on one. However, that is not clearly represented by
the project. While we don't intend to retrofit this policy to past
branches, part of proposing this change is to help clear that up going
forward.


> at least while tripleo is still in the Openstack namespaces and not the x
> namespaces.
>

I don't think I understand. At least..."what"? How is the OpenStack
namespace related to release models? How does the namespace (which is a
construct of how git repositories are organized aiui), have a relation to
what is included in an OpenStack release?


> Skipping upstream release is really quite a radical departure form the
> project original goals.
>

I disagree with how you remember the history, and I think this is an
overstatement.


> i think it would also be counter productive to our downstream efforts to
> move our testing close to upstream.
>
if ooo was to lose the ablity to test master for example we would not be
> able to use ooo in our downstream ci to test
> feature that we plan to release osp n+1 that are develop during an
> upstream cycle that wont be productised.
>

I don't follow the premise. How is it counterproductive to move our testing
close to upstream?
We'd always continue to test master. When it comes time for OpenStack to
branch, such as to create stable/xena in all the service projects, TripleO
may choose not to branch, and I think at that point, TripleO would no
longer have CI jobs running on stable/xena of those service projects.


>
> i do not work on ooo so at the end of the day this wont affect me much but
> to me skipping releases seam counter intuitive
> given the previous efforts to make ooo more usable for development and ci.
> Moving to independent
> to decouple the lifecycle seams more reasonable if the underlying goal is
> not to skip releases. you can release when ready
> rather then scrambling or wating for a deadline.


I think the "when ready" is part of the problem here. For example, one
might look at when we released stable/victoria and claim TripleO was ready.
However, when TripleO victoria was released, you could not upgrade from
ussuri to victoria. Likewise, you can't upgrade from victoria to wallaby.
Were we really ready to release? My take is that we shouldn't have released
at all. I think it sends a false signal.

An alternative to this entire proposal would be to double down on making
TripleO more fully support each OpenStack stable branch. That would mean
adding update/upgrade jobs for each stable branch, and doing the
development work to actually implement that support (if it's not tested,
it's broken), as well as likely adding other missing jobs instead of
de-emphasizing testing on these branches.

AIUI, we do not want to be adding additional CI jobs of that scale
upstream, especially given the complaints about node usage from TripleO
from earlier in this cycle. And, we do not have the humans to develop and
maintain this additional work.


> personally i think moving in the other direction so that ooo can release
> sooner
> not later would make the project more appealing as the delay in support of
> a release is often considered a detractor for tripleo vs
> other openstack installers.
>

I think moving to the independent model does enable us to consider
releasing sooner.


>
> i would hope that this change would not have any effect on the rdo
> packaging of non ooo packages.
> the rdo packages are used by other instalation methods (the puppet moduels
> for example) including i belive some of the larger chineese providers that
> have written there own installers. i think it would be damaging to centos
> if rdo was to skip upstream version of say nova. what might need to change
> is the packaging of ooo itself in rdo.
>
> tl;dr im not against the idea of ooo moving to independent model but i
> would hope that it will not affect RDO's packaging of non ooo projects and
> that
> ooo can still be used for ci of master and stable branches of for example
> nova.
>

We'd continue to always CI master.

Not all stable branches would remain covered by TripleO. For example, if
TripleO didn't branch and release for xena, you wouldn't have TripleO jobs
on nova stable/xena patches. Those jobs don't provide any meaningful
feedback for TripleO. Perhaps they do for nova as you are backporting a
change through every branch, and you're final destination is a branch where
TripleO is expected to be working, such as wallaby. You would want to know
if the change broke on xena for example, or if it were something on
wallaby. I can see how that would be useful for nova.

However, part of what we're saying is that TripleO is trying to simplify
what we are supporting and testing, so we can get better at supporting the
releases that are most important to our community. Yes, there is some
downstream influence here, in the same way that TripleO doesn't support
deploying with Ubuntu, because it is less important to our (TripleO)
community. I think that's ok, and I see nothing wrong with it.

If the service projects (such as nova) want to commit additional resources
and the upstream CI node count can handle the increase that properly
supporting each stable branch implies, then I think we can weigh that
option as well. However, the current status quo of more or less just
checking the boxes on each stable branch is wrong and sends a false message
in my opinion. That's a big part of what we're trying to correct.

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210609/8e2fac99/attachment.html>