Open Stack

On 5/28/20 12:03 PM, Ghanshyam Mann wrote:
> Hello Everyone,
>
> Ocata is in the 'Extended Maintenance' phase[1] but its gate is broken and difficult to fix now.
>
> The main issue started for gate is about Tempest and its deps constraint is correctly used on Ocata or not.
> We fixed most of those issues when things started failing during py2 drop[2].
>
> But now things are broken due to newer stestr is installed in Ocata jobs[2]. As Sean also mentioned in this
> backport[4] that stestr is not constraint in Ocata[5] as it was not in g-r that time so cannot be added in u-c.

We actually did just recently merge a patch to add it:

https://review.opendev.org/#/c/725213/

There were some other breakages that had to be fixed before we could get
it to land, so that took a little longer than expected. That said...

>
> Tempest old tag cannot be fixed to have that with cap on the tempest side.
>
> The only option left to unblock the gate is to remove the integration testing from Ocata gate. But it will untested after that
> as we cannot say unit testing is enough to mark it tested.  At least from QA perspective, I would not say it is tested
> if there is no integration job running there.
>
> Keeping it untested (no integration testing) and saying it is Maintained in the community can be very confusing things.
> I think its time to move it to the 'Unmaintained' phase and then EOL. Thought?

I do think it is getting to the point where it is becoming increasingly
difficult to keep stable/ocata happy, and time is better spent on more
recent stable branches.

When we discussed changing the stable policy to allow for Extended
Maintenance, part of that was that we would support EM as long as
someone was able to keep things working and tested. I think we've gotten
to the point where that is no longer the case with ocata.

This is the first branch that has made it this long before going EOL, so
it has been useful to see what other issues came up that were not
discussed. One thing that it's made me realize is there is a lot more
codependency than we maybe realized in those early discussions. The
policy and discussions that I remember were really about whether each
project would continue to put in the effort to keep things running. But
it really requires a lot more than just an individual project team to do
that. If any one of the "core" projects starts to have an issue, that
really means all of the projects have an issue. So it would not be
possible for, just as an example, Cinder to decide to transition its
stable/ocata branch to EOL, but Nova to keep maintaining their
stable/ocata branch.

There is also the cross-cutting concerns of requirements management and
tempest. I think these two areas have been where the most issues have
cropped up, and therefore requiring the most work to keep things
running. Kudos to gmann and the tempest team for getting things to work
after we've dropped py27. But requirements is a very small team (as is
tempest/QA), and things are breaking that require some thought and time
to work through the right way to handle issues in a stable branch, so a
lot of the effort is falling to these smaller groups to try to prop
things up.

I know I personally don't have extra time to be working on these, and no
real motivation other than I like to see Zuul comments be green. Now
that we've gotten the stestr issue hopefully resolved, I don't think I
can spend any more time on stable/ocata issues. Others are free to pitch
in, but I really think it is in the community's best interest if we just
decide we've done enough (Ocata would have gone EOL over 2 years ago
under the old policy) and it's time to call it and mark those branches EOL.

Sean