<div dir="ltr">Thanks<span class="gmail-qu" tabindex="-1"><span name="Radosław Piliszek" class="gmail-gD"><span style="font-weight:normal"><font size="2"> Radosław</font></span> </span></span>for the heads up, I validated the new release.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 4 janv. 2020 à 10:39, Radosław Piliszek <<a href="mailto:radoslaw.piliszek@gmail.com">radoslaw.piliszek@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks, Ben. That doc preamble really made me think not to cross the<br>
holy ground of release proposals. :-)<br>
<br>
I proposed release [1] and added you and Hervé as reviewers.<br>
<br>
[1] <a href="https://review.opendev.org/701080" rel="noreferrer" target="_blank">https://review.opendev.org/701080</a><br>
<br>
-yoctozepto<br>
<br>
czw., 2 sty 2020 o 21:20 Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> napisał(a):<br>
><br>
><br>
><br>
> On 12/30/19 9:52 AM, Radosław Piliszek wrote:<br>
> > Thanks, Sean! I knew I was missing something really basic!<br>
> > I was under the impression that 9.x is Stein, like it happens with<br>
> > main projects (major=branch).<br>
> > I could not find any doc explaining oslo.messaging versioning, perhaps<br>
> > Oslo could release 9.5.1 off the stein branch?<br>
><br>
> Oslo for the most part follows semver, so we only bump major versions<br>
> when there is a breaking change. We bump minor versions each release so<br>
> we can do bugfix releases on the previous stable branch without stepping<br>
> on master releases.<br>
><br>
> The underlying cause of this is likely that I'm way behind on releasing<br>
> the Oslo stable branches. It's high on my todo list now that most people<br>
> are back from holidays and will be around to help out if a release<br>
> breaks something.<br>
><br>
> However, anyone can propose a release[0][1] (contrary to what [0]<br>
> suggests), so if the necessary fix is already on stable/stein and just<br>
> hasn't been released yet please feel free to do that. You'll just need a<br>
> +1 from either myself or hberaud (the Oslo release liaison) before the<br>
> release team will approve it.<br>
><br>
> 0: <a href="https://releases.openstack.org/reference/using.html#requesting-a-release" rel="noreferrer" target="_blank">https://releases.openstack.org/reference/using.html#requesting-a-release</a><br>
> 1:<br>
> <a href="https://releases.openstack.org/reference/using.html#using-new-release-command" rel="noreferrer" target="_blank">https://releases.openstack.org/reference/using.html#using-new-release-command</a><br>
><br>
> ><br>
> > The issue remains that, even though oslo backports bugfixes into their<br>
> > stable branches, kolla (and very possibly other deployment solutions)<br>
> > no longer benefit from them.<br>
> ><br>
> > -yoctozepto<br>
> ><br>
> > pon., 30 gru 2019 o 16:01 Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>> napisał(a):<br>
> >><br>
> >> On Sun, Dec 29, 2019 at 09:41:45PM +0100, Radosław Piliszek wrote:<br>
> >>> Hi Folks,<br>
> >>><br>
> >>> as the subject goes, my installation has been hit by an old bug:<br>
> >>> <a href="https://bugs.launchpad.net/oslo.messaging/+bug/1828841" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.messaging/+bug/1828841</a><br>
> >>> (bug details not important, linked here for background)<br>
> >>><br>
> >>> I am using Stein, deployed with recent Kolla-built source-based images<br>
> >>> (with only slight modifications compared to vanilla ones).<br>
> >>> Kolla's procedure for building source-based images considers upper<br>
> >>> constraints, which, unfortunately, turned out to be lagging behind a<br>
> >>> few releases w.r.t. oslo.messaging at least.<br>
> >>> The fix was in 9.7.0 released on May 21, u-c still point to 9.5.0 from<br>
> >>> Feb 26 and the latest of Stein is 9.8.0 from Jul 18.<br>
> >>><br>
> >>> It seems oslo.messaging is missing from the automatic updates that bot proposes:<br>
> >>> <a href="https://review.opendev.org/#/q/owner:%22OpenStack+Proposal+Bot%22+project:openstack/requirements+branch:stable/stein" rel="noreferrer" target="_blank">https://review.opendev.org/#/q/owner:%22OpenStack+Proposal+Bot%22+project:openstack/requirements+branch:stable/stein</a><br>
> >>><br>
> >>> Per:<br>
> >>> <a href="https://opendev.org/openstack/releases/src/branch/master/doc/source/reference/reviewer_guide.rst#release-jobs" rel="noreferrer" target="_blank">https://opendev.org/openstack/releases/src/branch/master/doc/source/reference/reviewer_guide.rst#release-jobs</a><br>
> >>> this upper-constraint proposal should be happening for all releases.<br>
> >>><br>
> >><br>
> >> This is normal and what is expected.<br>
> >><br>
> >> Requirements are only updated for the branch in which those releases happen. So<br>
> >> if there is a release of oslo.messaging for stable/train, only the stable/train<br>
> >> upper constraints are updated for that new release. The stable/stein branch<br>
> >> will not be affected because that shows what the tested upper constraints were<br>
> >> for that branch.<br>
> >><br>
> >> The last stable/stein release for oslo.messaging was 9.5.0:<br>
> >><br>
> >> <a href="https://opendev.org/openstack/releases/src/branch/master/deliverables/stein/oslo.messaging.yaml#L49" rel="noreferrer" target="_blank">https://opendev.org/openstack/releases/src/branch/master/deliverables/stein/oslo.messaging.yaml#L49</a><br>
> >><br>
> >> And 9.5.0 is what is set in the stable/stein upper-constraints:<br>
> >><br>
> >> <a href="https://opendev.org/openstack/requirements/src/branch/stable/stein/upper-constraints.txt#L146" rel="noreferrer" target="_blank">https://opendev.org/openstack/requirements/src/branch/stable/stein/upper-constraints.txt#L146</a><br>
> >><br>
> >> To get that raised, whatever necessary bugfixes that are required in<br>
> >> oslo.messaging would need to be backported per-cycle until stable/stein (as in,<br>
> >> if it was in current master, it would need to be backported and merged to<br>
> >> stable/train first, then stable/stein), and once merged a stable release would<br>
> >> need to be proposed for that branch's version of the library.<br>
> >><br>
> >> Once that stable release is done, that will propose the update to the upper<br>
> >> constraint for the given branch.<br>
> >><br>
> >>> I would be glad if someone investigated why it happens(/ed) and<br>
> >>> audited whether other OpenStack projects don't need updating as well<br>
> >>> to avoid running on old deps when new are awaiting for months. :-)<br>
> >>> Please note this might apply to other branches as well.<br>
> >>><br>
> >>> PS: for some reason oslo.messaging Stein release notes (<br>
> >>> <a href="https://docs.openstack.org/releasenotes/oslo.messaging/stein.html" rel="noreferrer" target="_blank">https://docs.openstack.org/releasenotes/oslo.messaging/stein.html</a> )<br>
> >>> are stuck at 9.5.0 as well, this could be right (I did not inspect the<br>
> >>> sources) but I am adding this in PS so you have more things to<br>
> >>> correlate if they need be.<br>
> >>><br>
> >><br>
> >> Again, as expected. The last stable/stein release was 9.5.0, so that is correct<br>
> >> that the release notes for stein only show up to that point.<br>
> ><br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Hervé Beraud</div><div>Senior Software Engineer<br></div><div>Red Hat - Openstack Oslo</div><div>irc: hberaud</div><div>-----BEGIN PGP SIGNATURE-----<br><br>wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+<br>Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+<br>RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP<br>F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G<br>5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g<br>glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw<br>m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ<br>hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0<br>qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y<br>F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3<br>B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O<br>v6rDpkeNksZ9fFSyoY2o<br>=ECSj<br>-----END PGP SIGNATURE-----<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div>