Open Stack

On 6/9/21 3:58 PM, James Slagle wrote:
> 
> 
> On Wed, Jun 9, 2021 at 7:54 AM Sean Mooney <smooney at redhat.com
> <mailto: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.

Since TripleO does not follow the stable branch policy, isn't the same
possible as well today without switching to the independent release model?

>  
> 
> 
>     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
> --


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando