Open Stack

Ok thanks. Then I think we can continue

Le lun. 15 mars 2021 à 16:50, Matthew Thode <mthode at mthode.org> a écrit :

> On 21-03-15 16:44:41, Slawek Kaplonski wrote:
> > Hi,
> >
> > On Mon, Mar 15, 2021 at 04:14:53PM +0100, Herve Beraud wrote:
> > > If projects that use neutron-lib want this specific version of
> neutron-lib
> > > then I guess that yes they need to update their requirements and then
> > > re-release... We already freezed releases bor lib and client-lib few
> days
> > > ago if the update is outside this scope (services or UI) then I think
> we
> > > could accept it, else it will require lot of re-release and I don't
> think
> > > we want to do that, especially now that branching of those is on the
> rails.
> > >
> > > Le lun. 15 mars 2021 à 15:22, Matthew Thode <mthode at mthode.org> a
> écrit :
> > >
> > > > On 21-03-15 12:37:16, Slawek Kaplonski wrote:
> > > > > Hi,
> > > > >
> > > > > I'm raising this RFE to ask if we can release, and include new
> version
> > > > of the
> > > > > neutron-lib in the Wallaby release.
> > > > > Neutron already migrated all our policy rules to use new personas
> like
> > > > > system-reader or system-admin. Recently Lance found bug [1] with
> those
> > > > new
> > > > > personas.
> > > > > Fix for that is now merged in neutron-lib [2].
> > > > > This fix required bump the oslo_context dependency in
> lower-constraints
> > > > and
> > > > > that lead us to bump many other dependencies versions. But in fact
> all
> > > > those
> > > > > new versions are now aligned with what we already have in the
> Neutron's
> > > > > requirements so in fact neutron-lib was tested with those new
> versions
> > > > of the
> > > > > packages every time it was run with Neutron master branch.
> > > > >
> > > > > I already proposed release patch for neutron-lib [3].
> > > > > Please let me know if I You need anything else regrarding this RFE.
> > > > >
> > > > > [1] https://launchpad.net/bugs/1918506
> > > > > [2] https://review.opendev.org/c/openstack/neutron-lib/+/780204
> > > > > [3] https://review.opendev.org/c/openstack/releases/+/780550
> > > > >
> > > > > --
> > > > > Slawek Kaplonski
> > > > > Principal Software Engineer
> > > > > Red Hat
> > > >
> > > > It looks like there are a lot of places neutron-lib is still used.
> My
> > > > question here is if those projects need to update their requirements
> and
> > > > re-release?
> >
> > Fix included in that new version is relatively small. It is in the part
> of code
> > which is used already by stadium projects which are using neutron_lib.
> But all
> > of them also depends on Neutron so if neutron will bump minimum version
> of the
> > neutron-lib, it will be "automatically" used by those stadium projects
> as well.
> > And regarding all other lower-constaints changes in that new neutron-lib
> - as I
> > said in my previous email, all those versions are already set as minimum
> in
> > neutron so all of that was in fact effectively used, and is tested.
> >
> > If we will not have this fix in neutron-lib in Wallaby, it basically
> means that
> > we will have broken support for those new personas like "system
> reader/admin".
> >
> > If that would be problem to make new neutron-lib release now, would it be
> > possible to cut stable/wallaby branch in neutron-lib, backport that fix
> there
> > and release new bugfix version of neutron-lib just after Wallaby will be
> > released? Will it be possible to bump neutron's required neutron-lib
> version
> > then?
> >
> > > >
> > > > --
> > > > Matthew Thode
> > > >
> > >
> > >
> > > --
> > > 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
>
> It sounds like other projects will NOT need a release after this is
> bumped.  If that is the case the release has my signoff as requirements
> PTL.
>
> --
> Matthew Thode
>


-- 
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/20210315/d6f698f7/attachment-0001.html>