<div dir="ltr"><div>I agree this is not a feature in the normal sense.</div><div>Fixture is isolated from the rest and doesn't affecting the oslo.service consumers.</div><div>I have a slight preference for the second solution but I've no problems to use the first proposed solution (backport).</div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 21 nov. 2018 à 16:02, Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@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">On Wed, 2018-11-21 at 09:57 -0500, Doug Hellmann wrote:<br>
> Herve Beraud <<a href="mailto:hberaud@redhat.com" target="_blank">hberaud@redhat.com</a>> writes:<br>
> <br>
> > Hey all!<br>
> > <br>
> > Here is a thread to coordinate all the teams (oslo, nova, stable,<br>
> > requirements) working on the update of the oslo.service constraint in the<br>
> > Rocky requirements.<br>
> > <br>
> > # Summary<br>
> > <br>
> > Usage of threading event with eventlet caused inefficient code (causing<br>
> > many useless system calls and  high CPU usage).<br>
> > This issue was already fixed on oslo.service master and we also want to fix<br>
> > it in stable/rocky.<br>
> > <br>
> > Our main issue is how to fix the high CPU usage on stable/rocky without<br>
> > break the nova CI.<br>
> > <br>
> > Indeed, we already have backported the eventlet related fix to oslo.service<br>
> > but this fix requires also a nova update to avoid nova CI errors due to<br>
> > threading removal on oslo.service that introduce the nova CI errors.<br>
> > <br>
> > A fix was proposed and merged on oslo.service master to introduce a new<br>
> > feature (fixture) that avoid the nova CI errors, but<br>
> > backporting the master fix to Rocky introduces a new feature into a stable<br>
> > branch so this is also an issue.<br>
> > <br>
> > So we need to discuss with all the teams to find a proper solution.<br>
> > <br>
> > # History<br>
> > <br>
> > A few weeks ago this issue was opened on oslo.service (<br>
> > <a href="https://bugs.launchpad.net/oslo.service/+bug/1798774" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.service/+bug/1798774</a>) and it was fixed by<br>
> > this submited patch on the master branch (<br>
> > <a href="https://review.openstack.org/#/c/611807/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/611807/</a> ).<br>
> > <br>
> > This change use the proper event primitive to fix the performance issue.<br>
> > <br>
> > A new version of oslo.service was released (1.32.1)<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>
> > 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>
> > # 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>
> > 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>
> > -- <br>
> > Hervé Beraud<br>
> > Senior Software Engineer<br>
> > Red Hat - Openstack Oslo<br>
> > irc: hberaud<br>
> > -----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>
> Thank you for summarizing this issue, Hervé, and for working on the<br>
> patches we need.<br>
> <br>
> I think I would be happy with either solution. Using clean backports<br>
> seems less risky, and even though we are adding a new feature to<br>
> oslo.service it's only a unit test fixture. On the other hand if we want<br>
> to be very strict about not adding features in stable branches and we<br>
> are OK with creating a change to nova's unit tests that is not<br>
> backported from master, then that works for me, too.<br>
<br>
it should be noted this is not just a blocker for the nova ci<br>
if we dont fix the unit test it will break ditrobution that run<br>
the unitest as part of there packaging of nova downstream.<br>
i would prefer to backport the fixture personally and do a clean backport of the nova patches<br>
also rather then a stable only patch. while thecnically a feature i dont really consider a<br>
test fixture to be a feature in the normal sense and it is relitivly small and self contained.<br>
> <br>
> I have a slight preference for the first proposal, but not strong enough<br>
> to vote fight for it if the majority decides to go with the second<br>
> option.<br>
> <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>