Open Stack

Hi,

On Mon, Mar 29, 2021 at 08:53:58AM -0500, Ghanshyam Mann wrote:
>  ---- On Mon, 29 Mar 2021 06:14:06 -0500 Akihiro Motoki <amotoki at gmail.com> wrote ----
>  > On Mon, Mar 29, 2021 at 8:07 PM Slawek Kaplonski <skaplons at redhat.com> wrote:
>  > >
>  > > Hi,
>  > >
>  > > On Mon, Mar 29, 2021 at 11:52:59AM +0200, Herve Beraud wrote:
>  > > > Hello,
>  > > >
>  > > > The main question is, does the previous Victoria version [1] will be
>  > > > compatible with the latest neutron changes and with the latest engine
>  > > > facade introduced during Wallaby?
>  > >
>  > > It won't be compatible. Networking-midonet from Victoria will not work properly
>  > > with Neutron Wallaby.
>  > >
>  > > >
>  > > > Releasing an unfixed engine facade code is useless, so we shouldn't release
>  > > > a new version of networking-midonet, because the project code won't be
>  > > > compatible with the rest of our projects (AFAIK neutron), unless, the
>  > > > previous version will not compatible either, and, unless, not releasing a
>  > > > Wallaby version leave the project branch uncut and so leave the
>  > > > corresponding series unmaintainable, and so unfixable a posteriori.
>  > > >
>  > > > If we do not release a new version then we will use a previous version of
>  > > > networking-midonet. This version will be the last Victoria version [1].
>  > > >
>  > > > I suppose that this version (the victoria version) isn't compatible with
>  > > > the new facade engine either, isn't it?
>  > >
>  > > Correct. It's not compatible.
>  > >
>  > > >
>  > > > So release or not release a new version won't solve the facade engine
>  > > > problem, isn't?
>  > >
>  > > Yes.
>  > >
>  > > >
>  > > > You said that neutron evolved and networking-midonet didn't, hence even if
>  > > > we release networking-midonet in the current state it will fail too, isn't
>  > > > it?
>  > >
>  > > Also yes :)
>  > >
>  > > >
>  > > > However, releasing a new version and branching on it can give you the
>  > > > needed maintenance window to allow you to fix the issue later, when your
>  > > > gates will be fixed and then patches backported. git tags are cheap.
>  > > >
>  > > > We should notice that since Victoria some patches have been merged in
>  > > > Wallaby so even if they aren't ground breaking changes they are changes
>  > > > that it is worth to release.
>  > > >
>  > > > From a release point of view I think it's worth it to release a new version
>  > > > and to cut Wallaby. We are close to the it's deadline. That will land the
>  > > > available delta between Victoria and Wallaby. That will allow to fix the
>  > > > engine facade by opening a maintenance window. If the project is still
>  > > > lacking maintainers in a few weeks / months, this will allow a more smooth
>  > > > deprecation of this one.
>  > > >
>  > > > Thoughts?
>  > >
>  > > Based on Your feedback I agree that we should release now what we have. Even if
>  > > it's broken we can then fix it and backport fixes to stable/wallaby branch.
>  > >
>  > > @Akihiro: are You ok with that too?
>  > 
>  > I was writing another reply and did not notice this mail.
>  > While I still have a doubt on releasing the broken code (which we are
>  > not sure can be fixed soon or not),
>  > I am okay with either decision.
> 
> Yeah, releasing broken code and especially where we do not if there will be
> maintainer to fix it or not seems risky for me too.
> 
> One option is to deprecate it for wallaby which means follow the deprecation steps
> mentioned in project-team-guide[1]. If maintainers show up then it can be un-deprecated. 
> With that, we will not have any compatible wallaby version which I think is a better
> choice than releasing the broken code.

We were asking about that some time ago already and then some new maintainers
stepped in. But as now there is that problem again with networking-midonet I'm
fine to deprecate it (or ask about it again at least).
But isn't it too late in the cycle now? Last time when we were doing that it was
before milestone-2 IIRC. Now we are almost at the end of the cycle. Should we do
it still now?
If yes, how much time do we really have to e.g. ask for some new maintainers?

> 
> Releasing the broken code now with the hope of someone will come up and fix it with
> backport makes me a little uncomfortable and if it did not get fix then we will live
> with broken release forever. 
> 
> 
> [1]https://docs.openstack.org/project-team-guide/repository.html#deprecating-a-repository
> 
> -gmann
> 
>  > 
>  > >
>  > > >
>  > > > [1]
>  > > > https://opendev.org/openstack/releases/src/branch/master/deliverables/victoria/networking-midonet.yaml
>  > > >
>  > > > Le lun. 29 mars 2021 à 10:32, Slawek Kaplonski <skaplons at redhat.com> a
>  > > > écrit :
>  > > >
>  > > > > Hi,
>  > > > >
>  > > > > We have opened release patch for networking-midonet [1] but our concern
>  > > > > about
>  > > > > that project is that its gate is completly broken since some time thus we
>  > > > > don't really know if the project is still working and valid to be released.
>  > > > > In Wallaby cycle Neutron for example finished transition to the engine
>  > > > > facade,
>  > > > > and patch to adjust that in networking-midonet is still opened [2] (and
>  > > > > red as
>  > > > > there were some unrelated issues with most of the jobs there).
>  > > > >
>  > > > > In the past we had discussion about networking-midonet project and it's
>  > > > > status
>  > > > > as the official Neutron stadium project. Then some new folks stepped in to
>  > > > > maintain it but now it seems a bit like (again) it lacks of maintainers.
>  > > > > I know that it is very late in the cycle now so my question to the TC and
>  > > > > release teams is: should we release stable/wallaby with its current state,
>  > > > > even if it's broken or should we maybe don't release it at all until its
>  > > > > gate
>  > > > > will be up and running?
>  > > > >
>  > > > > [1] https://review.opendev.org/c/openstack/releases/+/781713
>  > > > > [2] https://review.opendev.org/c/openstack/networking-midonet/+/770797
>  > > > >
>  > > > > --
>  > > > > Slawek Kaplonski
>  > > > > Principal Software Engineer
>  > > > > Red Hat
>  > > >
>  > > >
>  > > >
>  > > > --
>  > > > Hervé Beraud
>  > > > Senior Software Engineer at Red Hat
>  > > > irc: hberaud
>  > > > https://github.com/4383/
>  > > > https://twitter.com/4383hberaud
>  > > > -----BEGIN PGP SIGNATURE-----
>  > > >
>  > > > wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
>  > > > Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
>  > > > RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
>  > > > F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
>  > > > 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
>  > > > glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
>  > > > m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
>  > > > hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
>  > > > qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
>  > > > F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
>  > > > B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
>  > > > v6rDpkeNksZ9fFSyoY2o
>  > > > =ECSj
>  > > > -----END PGP SIGNATURE-----
>  > >
>  > > --
>  > > Slawek Kaplonski
>  > > Principal Software Engineer
>  > > Red Hat
>  > 
>  > 
> 

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210329/4fd37cf8/attachment-0001.sig>