Open Stack

Le lun. 29 mars 2021 à 15:54, Ghanshyam Mann <gmann at ghanshyammann.com> a
écrit :

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

If the team agrees with that I really prefer this approach.


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

-- 
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-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210329/717091e4/attachment-0001.html>