Open Stack

Considering recent OSSA issues did not release fixes for Ocata[1][2],
I think we should really consider making the maintenance status more
clear and/or per project.

I know that Adam proposed this a while ago for Octavia, but it seems
to be stuck pending reviews.[3]

Michael

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014717.html
[2] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013251.html
[3] https://review.opendev.org/#/c/719097/


On Thu, May 28, 2020 at 2:26 PM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>
> ---- On Thu, 28 May 2020 13:30:29 -0500 Sean McGinnis <sean.mcginnis at gmx.com> wrote ----
>  > 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.
>
> +1, Even QA has the policy and that is what we all agreed on about not supporting the
> stable branches once it is Extended Maintainance but you know when we see things are
> broken we fix those. I think that is the usual nature I think :) But I agree that its time to
> move forward for Ocata.
>
> Also once Ocata is gone, it will easy to freeze the devstack-gate. Ocata is last stable where
> we do not have zuulv3 native base jobs and Pike onwards we can backport everything converted
> in zuulv3.
>
>  >
>  > 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.
>
> Yeah, we have extended it too much I think maybe due to  the first one to go to
> 'Unmaintained' after Extended maintenance things started.
>
> -gmann
>
>  >
>  > Sean
>  >
>  >
>  >
>