<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le jeu. 22 nov. 2018 à 05:55, Tony Breeds <<a href="mailto:tony@bakeyournoodle.com">tony@bakeyournoodle.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>
HI folks,<br>
    I admit my initial response to this was mor pragmatic 'take the<br>
bakport' but as I thought it through I saw more problems with that<br>
approach.<br>
<br>
On Wed, Nov 21, 2018 at 03:47:25PM +0100, Herve Beraud wrote:<br>
<br>
> Since these changes was introduced into oslo.service master, nova facing<br>
> some issues into the master CI process, due to the threading changes, and<br>
> they was fixed by these patches ( <a href="https://review.openstack.org/#/c/615724/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/615724/</a>,<br>
> <a href="https://review.openstack.org/#/c/617989/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/617989/</a> ) into master.<br>
> <br>
> Few weeks ago I have backport to oslo.service some changes (<br>
> <a href="https://review.openstack.org/#/c/614489/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/614489/</a> ) from master to stable/rocky to<br>
> also fix the problem in the rocky release.<br>
<br>
Okay that was a mistake, backporting a patch from master to stable that<br>
is known to break consumers, I admit this isn't explicitly called out in<br>
the stable policy but it is kind of the spirit of the stable policy.<br>
<br>
The quickest fix would be to revert 614489, release 1.31.7 and blacklist<br>
1.31.6.<br>
<br>
Yes this leaves the High CPU usage bug open on rocky.  That isn't great<br>
but it also isn't terrible.<br>
<br>
> When this backport was merged we have created a new release of oslo.service<br>
> (1.31.6) ( <a href="https://review.openstack.org/#/c/616505/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/616505/</a> ) (stable/rocky<br>
> version).<br>
> <br>
> Then the openstack proposal bot submit a patch to requirements on stable<br>
> rocky to update the oslo.service version with the latest version (1.31.6)<br>
> but if we'll use it we'll then break the CI<br>
> <a href="https://review.openstack.org/#/c/618834/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/618834/</a> so this patch is currently blocked<br>
> to avoid nova CI error.<br>
<br>
Huzzah for cross-project gateing!<br>
<br>
> # Issue<br>
> <br>
> Since the oslo.services threading changes were backported to rocky we risk<br>
> to  faces the same issues inside the nova rocky CI if we update the<br>
> requirements.<br>
> <br>
> In parallel in oslo.service we have started to backport a new patch who<br>
> introduces fixture  ( <a href="https://review.openstack.org/#/c/617989/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/617989/</a> ) from<br>
> master to rocky, and also we start to backport on nova rocky branch (<br>
> <a href="https://review.openstack.org/619019" rel="noreferrer" target="_blank">https://review.openstack.org/619019</a>, <a href="https://review.openstack.org/619022" rel="noreferrer" target="_blank">https://review.openstack.org/619022</a> )<br>
> patches who use oslo.service.fixture and who solve the nova CI issue. The<br>
> patch on oslo.service exposes a public oslo_service.fixture.SleepFixture<br>
> for this purpose. It can be maintained opaquely as internals change without<br>
> affecting its consumers.<br>
> <br>
> The main problem is that the patch bring a new functionality to a stable<br>
> branch (oslo.service rocky) but this patch help to fix the nova issue.<br>
> <br>
> Also openstack proposal bot submit a patch to requirements on stable rocky<br>
> to update the oslo.service version with the latest version (1.31.6) but if<br>
> we'll use it we'll then break the CI<br>
> <a href="https://review.openstack.org/#/c/618834/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/618834/</a> since the oslo service 1.31.6 is<br>
> incompatible with novas stable rocky unittest due to the threading changes.<br>
> <br>
> # Questions and proposed solutions<br>
> <br>
> This thread try to summarize the current situation.<br>
> <br>
> We need to find how to be able to proceed, so this thread aim to allow to<br>
> discuss between team to find the best way to fix.<br>
> <br>
> 1. Do we need to continue to try to backport fixture on oslo.service to fix<br>
> the CI problem (<a href="https://review.openstack.org/#/c/617989/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/617989/</a>) ?<br>
<br>
Doing this is a violation of the stable policy.  I get that the new<br>
feature is just a testing only fixture but that doesn't really matter<br>
it's still a feature.  To use it consumers would need to raise<br>
the value for oslo.service in lower-constraints.txt which is a policy<br>
violation.<br>
<br>
The is an additional complication that this backport adds fixtures to<br>
requirements.txt for oslo.service, at the very least this would mean<br>
we're into a minor semver bump (1.32.X, which is already taken).  This<br>
also means the vendors need to ensure that there is a 'fixtures' package<br>
available.  Now I expect that all packagers have such a thing but there<br>
is a small chance that it exists as a build only package and needs to be<br>
exposed/published.  We're previously said to vendors we wouldn't do that<br>
on stable branches.<br></blockquote><div><br></div><div>I agree this solution come with a minor bump and issues to keep the semver coherent.<br></div><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 2. Do we need to find an another approach like mocking<br>
> oslo.service.loopingcall._Event.wait in nova instead of mocking<br>
> oslo_service.loopingcall._ThreadingEvent.wait (example:<br>
> <a href="https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py</a>)<br>
> ?<br>
> This is only a fix on the nova side and it allows us to update oslo.service<br>
> requirements and allows us to fix the high CPU usage issue. I've submit<br>
> this patch (<a href="https://review.openstack.org/619246" rel="noreferrer" target="_blank">https://review.openstack.org/619246</a>) who implement the<br>
> description above.<br>
> <br>
> Personaly I think we need to find an another approach like the mocking<br>
> remplacement (c.f 2).<br>
> <br>
> We need to decide which way we use and to discuss about other solutions.<br>
<br>
I think the only way forward is the revert, release and block path.  The<br>
existing open reviews just add more policy violations.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yours Tony.<br>
</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></div>