Open Stack

On Wed, 2021-06-09 at 09:58 -0400, James Slagle wrote:
> 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.
if that is the general consensus yes i think it would be good to update the docs
to highlight that. i had assumed that the goal of ooo was to have all upstream releases
be production ready independent of if that is productized downstream.
> 
> 
> > 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?
i was more thinking that perhaps if ooo was moving away form the corodianted releases
it might make more sense for it to move to a spereate top level project like starlinx
so rather then x/ namespace maybe a top level tripleo namesapace to better refalect
that while it deploy openstack it does not follow the ame release cadance. coupled with
the fact that ooo already those not follow the normal stable backport policies that other
openstack proejct follow and the recent dicussing about opting out of the global requirement
process it just felt like ooo was moving away form being a part of openstack to being a
related porjects like starlingx.

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

so for other project i guess the impact of that would be removing the triplo job
form our our ci piplines for the stable branch.

for nova we do not currently hav eany ooo based ci jobs but we had breifly discussed having 
ooo-standalone job to do some centos/ooo based testing at one point.
destack is generally the correct tool to test change to nova but if ooo was to skip stable release
i think it would mean it would not be a candiate for other project to use in there ci as an alternivie.
that is  a valid choice for the ooo to make but it effectlivy means we will never have a ooo voting jobs in nova
if ooo does start skiping upstream releases.

> 
> 
> > 
> > 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.
well honestly if i was using ooo as my deployment tool i would have expected upgrade support
to be completed prior to the reslease yes but i think this is not an artifact of the release
cycle but rather an artifact that upgrade support is not part of the DOD of enabling a new feature
in ooo. e.g. if master was required to be alwasy upgradable for previous release we would not have this
issue. that is a lot more work though.
> 
> 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.
yes. personally i would prefer if we went in this direction, again i know why
from a downstream persepctive we may not want to do this but  in my personal
capasity if i was evaluating a deployment tool n to n+1 update in place of upstream
release would be part of my minimum viable product.

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

ack i know we are both human an machine constrained to go this path.
actully supporting multinode standalone and upgrades of standalone deployments
would have signinficnatly reduced the ci time and resouces required but we also
dont have the resouces to eanable that :( 

we have been trying on and off to enable that for https://opendev.org/openstack/whitebox-tempest-plugin
so that we can better test changes before they hit downstream ci but i think that idea has more or less
stalled out.

> 
> 
> > 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.
yes today we use devstack to validate that which honestly is enough 99% of the time
where it can be chalanging is if the issue we are fixing is centos/ooo specific
granted we dont currently have ooo based ci on the project i work on so its not really
a decrese in capability. 

we had discussed possible using upstream ooo to start early validation of new feature
after the completion of an upstream cycle form a branch that would not be the bases of an downstream relesase.
we might be able to get the same effect just using master but the idea was to test earlier.
> 
> 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.
ack, that is fair and im not really concerned by that. i think its correct
to serve the need of the comunity that consume the project.
> 
> 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.
> 
ack. honestly without multinode standalone and upgrade support for the same i dont actully
think it would add much value above just having a devstack centos job when we are concerned
about cenost/rhel specific things.

the reason i reponed initally was mainly propted by the implication that a ooo change in direction woudl
nessatatye rdo to also change its release cycle but that is not what was being proposed or what will happen
so you can consider my question/comments more or less adressed.