<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>For resume we decide to use:</div><div>- #4 (<a href="https://review.openstack.org/#/c/619360/">https://review.openstack.org/#/c/619360/</a>)</div><div>- #3 (<a href="https://review.openstack.org/#/c/619342/">https://review.openstack.org/#/c/619342/</a>)<br></div><div><br></div><div>Also I've propose the oslo.service 1.31.7 since #3 have been merged (<a href="https://review.openstack.org/#/c/619342/">https://review.openstack.org/#/c/619342/</a>) :<br></div><div><a href="https://review.openstack.org/#/c/620913/">https://review.openstack.org/#/c/620913/</a></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 29 nov. 2018 à 14:56, Herve Beraud <<a href="mailto:hberaud@redhat.com">hberaud@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>FYI Introducing oslo.service 1.31.7 with the latest merged changes.</div><div>These refers to #3.<br></div><div><a href="https://review.openstack.org/#/c/620913/" target="_blank">https://review.openstack.org/#/c/620913/</a><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 28 nov. 2018 à 00:31, Ben Nemec <<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 11/26/18 9:47 AM, Zane Bitter wrote:<br>
> On 22/11/18 6:43 PM, Tony Breeds wrote:<br>
>>> ### 3 - Maintain a private interface for ThreadingEvent only on <br>
>>> stable/rocky<br>
>>> impacted projects: oslo.service<br>
>>> related reviews:<br>
>>> -<a href="https://review.openstack.org/619342/" rel="noreferrer" target="_blank">https://review.openstack.org/619342/</a><br>
>>><br>
>>> pros:<br>
>>> - straightforward<br>
>>> cons:<br>
>>> - Changing the loopingcall module semantics as it is different type<br>
>>> - stable only patches<br>
>>> - misunderstoud service customer between Threading, eventlet, etc.. and<br>
>>> master behavior<br>
>> A variation of this (without adding the debtcollector requirement) might<br>
>> work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) would<br>
>> work and doesn't introduce any new policy violations.<br>
>><br>
>> Adding debcollector is great but introduces at least the semver issues<br>
>> from option #1<br>
> <br>
> Hey Tony, can you explain the debtcollector issue a bit more? Is it just <br>
> that we generally promise to not adding anything to requirements.txt on <br>
> stable branches? In this case, debtcollector, appears to already be a <br>
> transitive dependency of something that oslo.service already requires <br>
> (it appears in lower-constraints.txt, at least), so I was assuming that <br>
> there wouldn't be any real-world consequences. Does that change things?<br>
<br>
Technically adding a new dep requires a minor version update per our <br>
release guidelines. I guess it gets a little fuzzy when you're adding a <br>
dep that's already part of the transitive set, but I'm guessing that's <br>
what Tony was referring to.<br>
<br>
That said, as I mentioned on the review I don't feel any particular need <br>
to debtcollector this. It's in a private module that nobody should ever <br>
have been using and we're only doing this because we prioritize fixing <br>
the bug over absolute API purity. :-)<br>
<br>
In any case, I'm +1 on doing this to avoid creating weird version <br>
dependencies on a stable branch.<br>
<br>
> <br>
> TBH it would be trivial to do something equivalent without adding the <br>
> new requirement, so I guess the easiest thing is if I just update the <br>
> patch to do that.<br>
> <br>
>>> ### 4 - Don't use private interface in oslo.service<br>
>>> impacted projects: nova<br>
>>> related reviews:<br>
>>> -<a href="https://review.openstack.org/#/c/619360/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/619360/</a><br>
>>><br>
>>> pros:<br>
>>> - straightforward<br>
>>> cons:<br>
>>> - this could work but it is not the same sematics as before as the <br>
>>> type has<br>
>>> changed<br>
>>> - stable only patches<br>
>>> - misunderstoud service customer between Threading, eventlet, etc.. and<br>
>>> master behavior<br>
>> I think this is more or less the same as Option #3 in terms of impact.<br>
>> If that's right it could be acceptable.<br>
> <br>
> It's slightly higher impact, because you wouldn't be able to upgrade <br>
> oslo.service past 1.31.5 and still run the unit tests on old versions of <br>
> Nova. Whereas with option #3 you could just upgrade oslo.service to <br>
> 1.31.7, or just upgrade Nova, and either way everything would work.<br>
> <br>
> Not that we shouldn't do this *as well*, but IMHO we still need to do #3.<br>
> <br>
<br>
I like doing this as well. If we need an argument as to why it's okay to <br>
do this stable-only patch, it would be that this is essentially a <br>
backport of the original Nova fix proposed before we decided to do the <br>
fixture. In retrospect maybe we should have gone ahead and merged that <br>
simple, backportable fix and done the fixture as a followup, but in <br>
spirit this has the same effect.<br>
<br>
-Ben<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_3730169126480947691gmail_signature" data-smartmail="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>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="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>