Open Stack

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