<div dir="ltr">Matt,<div><br></div><div>0.6.0 and 0.7.0 were released for Mitaka! not Liberty. Though yes, because of not having pins any library we release for Mitaka will end up being used with Liberty as well.</div><div><a href="http://lists.openstack.org/pipermail/openstack-announce/2015-October/000701.html">http://lists.openstack.org/pipermail/openstack-announce/2015-October/000701.html</a><br></div><div><br></div><div>No, we are not reverting. Here's my current thought as a review:</div><div><a href="https://review.openstack.org/#/c/240371">https://review.openstack.org/#/c/240371</a><br></div><div><br></div><div>-- Dims</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 31, 2015 at 12:06 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 10/29/2015 5:22 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Right, the crux of the problem is the move by the library from SIGUSR1<br>
-> SIGUSR2 with no overlap and deprecation period breaks the ability to<br>
have any tooling use this without atomically updating that tooling, and<br>
this library, in all environments, all at the same time.<br>
<br>
We need the SIGUSR1 handler added back in, deprecated, and not removed<br>
for a couple cycles.<br>
<br>
-Sean<div><div class="h5"><br>
<br>
On 10/30/2015 06:46 AM, Davanum Srinivas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Matt,<br>
<br>
Yes, Sean already opened a critical bug<br>
- <a href="https://bugs.launchpad.net/oslo.reports/+bug/1510740" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.reports/+bug/1510740</a><br>
<br>
Please note that this change was added to oslo.reports *after* the<br>
liberty release in support of Mitaka. So i am not sure why we need to<br>
add it to liberty release notes. Also this is a consequence of NOT<br>
having version caps which was a decision a while ago as well.<br>
<br>
-- DIms<br>
<br>
On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann<br>
<<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a> <mailto:<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>>> wrote:<br>
<br>
<br>
<br>
On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:<br>
<br>
Background<br>
----------<br>
<br>
Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging<br>
mechanism that allows one to capture the current state of a Nova<br>
process/executable (e.g. `nova-compute`, `nova-api`, etc).<br>
<br>
The way to generate the error report is to supply the 'User-defined<br>
signal', SIGUSR1, when killing a Nova process. E.g.<br>
<br>
$ kill -USR1 `pgrep nova-compute`<br>
<br>
which results in GMR being printed to your standard error ('stderr')<br>
stream, wherever it ends up being redirected to (e.g. to a<br>
corresponding<br>
Nova process-specific log file, otherwise, on systemd-enabled<br>
systems,<br>
to its journal).<br>
<br>
<br>
Change in Mitaka (and above)<br>
----------------------------<br>
<br>
From the upcoming Mitaka release onwards, the default expected UNIX<br>
signal to generate GMR has been changed[1] from USR1 to USR2<br>
(another<br>
User-defined singal), because the USR1 is reserved by Apache<br>
'mod_wsgi'<br>
for its own purpose.<br>
<br>
So, to generate GMR, from Mitaka release:<br>
<br>
$ kill -USR2 `pgrep nova-compute`<br>
<br>
A corresponding Nova documentation change[2] has been submitted to<br>
reflect this new reality.<br>
<br>
<br>
[1] <a href="https://review.openstack.org/#/c/223133/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/223133/</a> --<br>
guru_meditation_report:<br>
Use SIGUSR2 instead of SIGUSR1<br>
[2] <a href="https://review.openstack.org/#/c/227779/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/227779/</a> -- doc: gmr: Update<br>
instructions to generate GMR error reports<br>
<br>
<br>
[*] References<br>
--------------<br>
<br>
Related reading:<br>
<br>
- <a href="http://docs.openstack.org/developer/nova/gmr.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/nova/gmr.html</a><br>
- <a href="http://docs.openstack.org/developer/oslo.reports/usage.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/oslo.reports/usage.html</a><br>
- <a href="https://wiki.openstack.org/wiki/GuruMeditationReport" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/GuruMeditationReport</a><br>
-<br>
<a href="https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/" rel="noreferrer" target="_blank">https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/</a><br>
<br>
<br>
Looks like this broke some tooling in the gate job runs where gmr's<br>
are created at the end of the service logs when the services exit.<br>
Here is a mitaka change with grenade on the liberty side with the<br>
gmr at the end:<br>
<br>
<a href="http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz" rel="noreferrer" target="_blank">http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz</a><br>
<br>
And on the new side it's gone:<br>
<br>
<a href="http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz" rel="noreferrer" target="_blank">http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz</a><br>
<br>
So obviously an upgrade impact, I'm hoping we get this into the<br>
liberty release notes as something to change when people move up to<br>
oslo.reports 1.6.0.<br>
<br>
We should also get the gate tooling fixed around this, I'm not sure<br>
where that was configured/triggered though, sdague probably knows.<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
--<br>
Davanum Srinivas :: <a href="https://twitter.com/dims" rel="noreferrer" target="_blank">https://twitter.com/dims</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div></blockquote>
<br>
Is there going to be a revert of <a href="https://review.openstack.org/#/c/223133/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/223133/</a> ? This has already baked into a couple of oslo.reports releases:<br>
<br>
Tag Name<br>
0.6.0<br>
0.7.0<br>
<br>
And we've updated docs in at least nova for it.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a></div>
</div>