On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney <smooney@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
--