Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-11-02 Thread Kashyap Chamarthy 
On Sat, Oct 31, 2015 at 09:11:31AM +0900, Davanum Srinivas wrote:
> Matt,
> 
> 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.
> http://lists.openstack.org/pipermail/openstack-announce/2015-October/000701.html
> 
> No, we are not reverting. Here's my current thought as a review:
> https://review.openstack.org/#/c/240371

Sigh, I was already worrying if this was going to break some tooling
somewhere.

Thanks, Dims for the quick response, and Matt for spotting it.

-- 
/kashyap

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-30 Thread Davanum Srinivas 
Matt,

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.
http://lists.openstack.org/pipermail/openstack-announce/2015-October/000701.html

No, we are not reverting. Here's my current thought as a review:
https://review.openstack.org/#/c/240371

-- Dims

On Sat, Oct 31, 2015 at 12:06 AM, Matt Riedemann  wrote:

>
>
> On 10/29/2015 5:22 PM, Sean Dague wrote:
>
>> Right, the crux of the problem is the move by the library from SIGUSR1
>> -> SIGUSR2 with no overlap and deprecation period breaks the ability to
>> have any tooling use this without atomically updating that tooling, and
>> this library, in all environments, all at the same time.
>>
>> We need the SIGUSR1 handler added back in, deprecated, and not removed
>> for a couple cycles.
>>
>> -Sean
>>
>>
>> On 10/30/2015 06:46 AM, Davanum Srinivas wrote:
>>
>>> Matt,
>>>
>>> Yes, Sean already opened a critical bug
>>> - https://bugs.launchpad.net/oslo.reports/+bug/1510740
>>>
>>> Please note that this change was added to oslo.reports *after* the
>>> liberty release in support of Mitaka. So i am not sure why we need to
>>> add it to liberty release notes. Also this is a consequence of NOT
>>> having version caps which was a decision a while ago as well.
>>>
>>> -- DIms
>>>
>>> On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
>>> > wrote:
>>>
>>>
>>>
>>>  On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:
>>>
>>>  Background
>>>  --
>>>
>>>  Oslo Guru Meditation (error) Reports (GMR)[*] are a useful
>>> debugging
>>>  mechanism that allows one to capture the current state of a Nova
>>>  process/executable (e.g. `nova-compute`, `nova-api`, etc).
>>>
>>>  The way to generate the error report is to supply the
>>> 'User-defined
>>>  signal', SIGUSR1, when killing a Nova process.  E.g.
>>>
>>>   $ kill -USR1 `pgrep nova-compute`
>>>
>>>  which results in GMR being printed to your standard error
>>> ('stderr')
>>>  stream, wherever it ends up being redirected to (e.g. to a
>>>  corresponding
>>>  Nova process-specific log file, otherwise, on systemd-enabled
>>>  systems,
>>>  to its journal).
>>>
>>>
>>>  Change in Mitaka (and above)
>>>  
>>>
>>>   From the upcoming Mitaka release onwards, the default expected
>>> UNIX
>>>  signal to generate GMR has been changed[1] from USR1 to USR2
>>>  (another
>>>  User-defined singal), because the USR1 is reserved by Apache
>>>  'mod_wsgi'
>>>  for its own purpose.
>>>
>>>  So, to generate GMR, from Mitaka release:
>>>
>>>   $ kill -USR2 `pgrep nova-compute`
>>>
>>>  A corresponding Nova documentation change[2] has been submitted
>>> to
>>>  reflect this new reality.
>>>
>>>
>>>  [1] https://review.openstack.org/#/c/223133/ --
>>>  guru_meditation_report:
>>>   Use SIGUSR2 instead of SIGUSR1
>>>  [2] https://review.openstack.org/#/c/227779/ -- doc: gmr:
>>> Update
>>>   instructions to generate GMR error reports
>>>
>>>
>>>  [*] References
>>>  --
>>>
>>>  Related reading:
>>>
>>>  - http://docs.openstack.org/developer/nova/gmr.html
>>>  - http://docs.openstack.org/developer/oslo.reports/usage.html
>>>  - https://wiki.openstack.org/wiki/GuruMeditationReport
>>>  -
>>>
>>> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
>>>
>>>
>>>  Looks like this broke some tooling in the gate job runs where gmr's
>>>  are created at the end of the service logs when the services exit.
>>>  Here is a mitaka change with grenade on the liberty side with the
>>>  gmr at the end:
>>>
>>>
>>> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz
>>>
>>>  And on the new side it's gone:
>>>
>>>
>>> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz
>>>
>>>  So obviously an upgrade impact, I'm hoping we get this into the
>>>  liberty release notes as something to change when people move up to
>>>  oslo.reports 1.6.0.
>>>
>>>  We should also get the gate tooling fixed around this, I'm not sure
>>>  where that was configured/triggered though, sdague probably knows.
>>>
>>>  --
>>>
>>>  Thanks,
>>>
>>>  Matt Riedemann
>>>
>>>
>>>
>>>
>>>  __
>>>  OpenStack Development Mailing List (not for usage questions)
>>>  Unsubscribe:
>>>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-30 Thread Matt Riedemann 



On 10/29/2015 4:46 PM, Davanum Srinivas wrote:

Matt,

Yes, Sean already opened a critical bug -
https://bugs.launchpad.net/oslo.reports/+bug/1510740

Please note that this change was added to oslo.reports *after* the
liberty release in support of Mitaka. So i am not sure why we need to
add it to liberty release notes. Also this is a consequence of NOT
having version caps which was a decision a while ago as well.

-- DIms

On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
> wrote:



On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:

Background
--

Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
mechanism that allows one to capture the current state of a Nova
process/executable (e.g. `nova-compute`, `nova-api`, etc).

The way to generate the error report is to supply the 'User-defined
signal', SIGUSR1, when killing a Nova process.  E.g.

  $ kill -USR1 `pgrep nova-compute`

which results in GMR being printed to your standard error ('stderr')
stream, wherever it ends up being redirected to (e.g. to a
corresponding
Nova process-specific log file, otherwise, on systemd-enabled
systems,
to its journal).


Change in Mitaka (and above)


  From the upcoming Mitaka release onwards, the default expected
UNIX
signal to generate GMR has been changed[1] from USR1 to USR2
(another
User-defined singal), because the USR1 is reserved by Apache
'mod_wsgi'
for its own purpose.

So, to generate GMR, from Mitaka release:

  $ kill -USR2 `pgrep nova-compute`

A corresponding Nova documentation change[2] has been submitted to
reflect this new reality.


[1] https://review.openstack.org/#/c/223133/ --
guru_meditation_report:
  Use SIGUSR2 instead of SIGUSR1
[2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
  instructions to generate GMR error reports


[*] References
--

Related reading:

- http://docs.openstack.org/developer/nova/gmr.html
- http://docs.openstack.org/developer/oslo.reports/usage.html
- https://wiki.openstack.org/wiki/GuruMeditationReport
-

https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/


Looks like this broke some tooling in the gate job runs where gmr's
are created at the end of the service logs when the services exit.
Here is a mitaka change with grenade on the liberty side with the
gmr at the end:


http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz

And on the new side it's gone:


http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz

So obviously an upgrade impact, I'm hoping we get this into the
liberty release notes as something to change when people move up to
oslo.reports 1.6.0.

We should also get the gate tooling fixed around this, I'm not sure
where that was configured/triggered though, sdague probably knows.

--

Thanks,

Matt Riedemann



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Davanum Srinivas :: https://twitter.com/dims


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



I guess upper-constraints in stable/liberty is 0.5.0 for oslo.reports 
[1] so people shouldn't be using anything newer than than with liberty 
deployments. So nothing needed in the release notes there I suppose.


But I agree we should probably have a deprecation cycle on this.

[1] 
https://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt#L197


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-30 Thread Matt Riedemann 



On 10/29/2015 5:22 PM, Sean Dague wrote:

Right, the crux of the problem is the move by the library from SIGUSR1
-> SIGUSR2 with no overlap and deprecation period breaks the ability to
have any tooling use this without atomically updating that tooling, and
this library, in all environments, all at the same time.

We need the SIGUSR1 handler added back in, deprecated, and not removed
for a couple cycles.

-Sean

On 10/30/2015 06:46 AM, Davanum Srinivas wrote:

Matt,

Yes, Sean already opened a critical bug
- https://bugs.launchpad.net/oslo.reports/+bug/1510740

Please note that this change was added to oslo.reports *after* the
liberty release in support of Mitaka. So i am not sure why we need to
add it to liberty release notes. Also this is a consequence of NOT
having version caps which was a decision a while ago as well.

-- DIms

On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
> wrote:



 On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:

 Background
 --

 Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
 mechanism that allows one to capture the current state of a Nova
 process/executable (e.g. `nova-compute`, `nova-api`, etc).

 The way to generate the error report is to supply the 'User-defined
 signal', SIGUSR1, when killing a Nova process.  E.g.

  $ kill -USR1 `pgrep nova-compute`

 which results in GMR being printed to your standard error ('stderr')
 stream, wherever it ends up being redirected to (e.g. to a
 corresponding
 Nova process-specific log file, otherwise, on systemd-enabled
 systems,
 to its journal).


 Change in Mitaka (and above)
 

  From the upcoming Mitaka release onwards, the default expected UNIX
 signal to generate GMR has been changed[1] from USR1 to USR2
 (another
 User-defined singal), because the USR1 is reserved by Apache
 'mod_wsgi'
 for its own purpose.

 So, to generate GMR, from Mitaka release:

  $ kill -USR2 `pgrep nova-compute`

 A corresponding Nova documentation change[2] has been submitted to
 reflect this new reality.


 [1] https://review.openstack.org/#/c/223133/ --
 guru_meditation_report:
  Use SIGUSR2 instead of SIGUSR1
 [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
  instructions to generate GMR error reports


 [*] References
 --

 Related reading:

 - http://docs.openstack.org/developer/nova/gmr.html
 - http://docs.openstack.org/developer/oslo.reports/usage.html
 - https://wiki.openstack.org/wiki/GuruMeditationReport
 -
 
https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/


 Looks like this broke some tooling in the gate job runs where gmr's
 are created at the end of the service logs when the services exit.
 Here is a mitaka change with grenade on the liberty side with the
 gmr at the end:

 
http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz

 And on the new side it's gone:

 
http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz

 So obviously an upgrade impact, I'm hoping we get this into the
 liberty release notes as something to change when people move up to
 oslo.reports 1.6.0.

 We should also get the gate tooling fixed around this, I'm not sure
 where that was configured/triggered though, sdague probably knows.

 --

 Thanks,

 Matt Riedemann



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Davanum Srinivas :: https://twitter.com/dims


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Is there going to be a revert of 
https://review.openstack.org/#/c/223133/ ?  This has already baked into 
a couple of oslo.reports releases:

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-29 Thread Matt Riedemann 



On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:

Background
--

Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
mechanism that allows one to capture the current state of a Nova
process/executable (e.g. `nova-compute`, `nova-api`, etc).

The way to generate the error report is to supply the 'User-defined
signal', SIGUSR1, when killing a Nova process.  E.g.

 $ kill -USR1 `pgrep nova-compute`

which results in GMR being printed to your standard error ('stderr')
stream, wherever it ends up being redirected to (e.g. to a corresponding
Nova process-specific log file, otherwise, on systemd-enabled systems,
to its journal).


Change in Mitaka (and above)


 From the upcoming Mitaka release onwards, the default expected UNIX
signal to generate GMR has been changed[1] from USR1 to USR2 (another
User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
for its own purpose.

So, to generate GMR, from Mitaka release:

 $ kill -USR2 `pgrep nova-compute`

A corresponding Nova documentation change[2] has been submitted to
reflect this new reality.


[1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
 Use SIGUSR2 instead of SIGUSR1
[2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
 instructions to generate GMR error reports


[*] References
--

Related reading:

- http://docs.openstack.org/developer/nova/gmr.html
- http://docs.openstack.org/developer/oslo.reports/usage.html
- https://wiki.openstack.org/wiki/GuruMeditationReport
- 
https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/



Looks like this broke some tooling in the gate job runs where gmr's are 
created at the end of the service logs when the services exit. Here is a 
mitaka change with grenade on the liberty side with the gmr at the end:


http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz

And on the new side it's gone:

http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz

So obviously an upgrade impact, I'm hoping we get this into the liberty 
release notes as something to change when people move up to oslo.reports 
1.6.0.


We should also get the gate tooling fixed around this, I'm not sure 
where that was configured/triggered though, sdague probably knows.


--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-29 Thread Davanum Srinivas 
Matt,

Yes, Sean already opened a critical bug -
https://bugs.launchpad.net/oslo.reports/+bug/1510740

Please note that this change was added to oslo.reports *after* the liberty
release in support of Mitaka. So i am not sure why we need to add it to liberty
release notes. Also this is a consequence of NOT having version caps which
was a decision a while ago as well.

-- DIms

On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann 
wrote:

>
>
> On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:
>
>> Background
>> --
>>
>> Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
>> mechanism that allows one to capture the current state of a Nova
>> process/executable (e.g. `nova-compute`, `nova-api`, etc).
>>
>> The way to generate the error report is to supply the 'User-defined
>> signal', SIGUSR1, when killing a Nova process.  E.g.
>>
>>  $ kill -USR1 `pgrep nova-compute`
>>
>> which results in GMR being printed to your standard error ('stderr')
>> stream, wherever it ends up being redirected to (e.g. to a corresponding
>> Nova process-specific log file, otherwise, on systemd-enabled systems,
>> to its journal).
>>
>>
>> Change in Mitaka (and above)
>> 
>>
>>  From the upcoming Mitaka release onwards, the default expected UNIX
>> signal to generate GMR has been changed[1] from USR1 to USR2 (another
>> User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
>> for its own purpose.
>>
>> So, to generate GMR, from Mitaka release:
>>
>>  $ kill -USR2 `pgrep nova-compute`
>>
>> A corresponding Nova documentation change[2] has been submitted to
>> reflect this new reality.
>>
>>
>> [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
>>  Use SIGUSR2 instead of SIGUSR1
>> [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
>>  instructions to generate GMR error reports
>>
>>
>> [*] References
>> --
>>
>> Related reading:
>>
>> - http://docs.openstack.org/developer/nova/gmr.html
>> - http://docs.openstack.org/developer/oslo.reports/usage.html
>> - https://wiki.openstack.org/wiki/GuruMeditationReport
>> -
>> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
>>
>>
> Looks like this broke some tooling in the gate job runs where gmr's are
> created at the end of the service logs when the services exit. Here is a
> mitaka change with grenade on the liberty side with the gmr at the end:
>
>
> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz
>
> And on the new side it's gone:
>
>
> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz
>
> So obviously an upgrade impact, I'm hoping we get this into the liberty
> release notes as something to change when people move up to oslo.reports
> 1.6.0.
>
> We should also get the gate tooling fixed around this, I'm not sure where
> that was configured/triggered though, sdague probably knows.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-29 Thread Sean Dague 
Right, the crux of the problem is the move by the library from SIGUSR1
-> SIGUSR2 with no overlap and deprecation period breaks the ability to
have any tooling use this without atomically updating that tooling, and
this library, in all environments, all at the same time.

We need the SIGUSR1 handler added back in, deprecated, and not removed
for a couple cycles.

-Sean

On 10/30/2015 06:46 AM, Davanum Srinivas wrote:
> Matt,
> 
> Yes, Sean already opened a critical bug
> - https://bugs.launchpad.net/oslo.reports/+bug/1510740
> 
> Please note that this change was added to oslo.reports *after* the
> liberty release in support of Mitaka. So i am not sure why we need to
> add it to liberty release notes. Also this is a consequence of NOT
> having version caps which was a decision a while ago as well.
> 
> -- DIms
> 
> On Fri, Oct 30, 2015 at 4:47 AM, Matt Riedemann
> > wrote:
> 
> 
> 
> On 10/21/2015 7:43 AM, Kashyap Chamarthy wrote:
> 
> Background
> --
> 
> Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> mechanism that allows one to capture the current state of a Nova
> process/executable (e.g. `nova-compute`, `nova-api`, etc).
> 
> The way to generate the error report is to supply the 'User-defined
> signal', SIGUSR1, when killing a Nova process.  E.g.
> 
>  $ kill -USR1 `pgrep nova-compute`
> 
> which results in GMR being printed to your standard error ('stderr')
> stream, wherever it ends up being redirected to (e.g. to a
> corresponding
> Nova process-specific log file, otherwise, on systemd-enabled
> systems,
> to its journal).
> 
> 
> Change in Mitaka (and above)
> 
> 
>  From the upcoming Mitaka release onwards, the default expected UNIX
> signal to generate GMR has been changed[1] from USR1 to USR2
> (another
> User-defined singal), because the USR1 is reserved by Apache
> 'mod_wsgi'
> for its own purpose.
> 
> So, to generate GMR, from Mitaka release:
> 
>  $ kill -USR2 `pgrep nova-compute`
> 
> A corresponding Nova documentation change[2] has been submitted to
> reflect this new reality.
> 
> 
> [1] https://review.openstack.org/#/c/223133/ --
> guru_meditation_report:
>  Use SIGUSR2 instead of SIGUSR1
> [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
>  instructions to generate GMR error reports
> 
> 
> [*] References
> --
> 
> Related reading:
> 
> - http://docs.openstack.org/developer/nova/gmr.html
> - http://docs.openstack.org/developer/oslo.reports/usage.html
> - https://wiki.openstack.org/wiki/GuruMeditationReport
> -
> 
> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> 
> 
> Looks like this broke some tooling in the gate job runs where gmr's
> are created at the end of the service logs when the services exit.
> Here is a mitaka change with grenade on the liberty side with the
> gmr at the end:
> 
> 
> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/old/screen-n-cpu.txt.gz
> 
> And on the new side it's gone:
> 
> 
> http://logs.openstack.org/97/227897/13/check/gate-grenade-dsvm/27723a9/logs/new/screen-n-cpu.txt.gz
> 
> So obviously an upgrade impact, I'm hoping we get this into the
> liberty release notes as something to change when people move up to
> oslo.reports 1.6.0.
> 
> We should also get the gate tooling fixed around this, I'm not sure
> where that was configured/triggered though, sdague probably knows.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-21 Thread Davanum Srinivas 
Sean,

If you are using the GMR code from oslo-incubator, please switch over to
the new oslo.service. I don't see any pending reviews.

Thanks,
-- Dims

On Wed, Oct 21, 2015 at 1:29 PM, Sean McGinnis 
wrote:

> On Wed, Oct 21, 2015 at 02:43:39PM +0200, Kashyap Chamarthy wrote:
> > Background
> > --
> >
> > Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> > mechanism that allows one to capture the current state of a Nova
> > process/executable (e.g. `nova-compute`, `nova-api`, etc).
> >
> > The way to generate the error report is to supply the 'User-defined
> > signal', SIGUSR1, when killing a Nova process.  E.g.
> >
> > $ kill -USR1 `pgrep nova-compute`
> >
> > which results in GMR being printed to your standard error ('stderr')
> > stream, wherever it ends up being redirected to (e.g. to a corresponding
> > Nova process-specific log file, otherwise, on systemd-enabled systems,
> > to its journal).
> >
> >
> > Change in Mitaka (and above)
> > 
> >
> > From the upcoming Mitaka release onwards, the default expected UNIX
> > signal to generate GMR has been changed[1] from USR1 to USR2 (another
> > User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
> > for its own purpose.
> >
> > So, to generate GMR, from Mitaka release:
> >
> > $ kill -USR2 `pgrep nova-compute`
> >
> > A corresponding Nova documentation change[2] has been submitted to
> > reflect this new reality.
>
>
> Do you know if anyone is working on updating all projects that GMR was
> added to? Or should we each look at our own projects and make the
> necessary changes?
>
>
> >
> >
> > [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
> > Use SIGUSR2 instead of SIGUSR1
> > [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
> > instructions to generate GMR error reports
> >
> >
> > [*] References
> > --
> >
> > Related reading:
> >
> > - http://docs.openstack.org/developer/nova/gmr.html
> > - http://docs.openstack.org/developer/oslo.reports/usage.html
> > - https://wiki.openstack.org/wiki/GuruMeditationReport
> > -
> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> >
> > --
> > /kashyap
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-21 Thread Sean McGinnis 
On Wed, Oct 21, 2015 at 01:58:46PM -0400, Davanum Srinivas wrote:
> Sean,
> 
> If you are using the GMR code from oslo-incubator, please switch over to
> the new oslo.service. I don't see any pending reviews.
> 
> Thanks,
> -- Dims

Thanks Dims. I remembered the initial patch from May that added it
directly, but now I see it was updated in June.

There is a devref doc that needs to be updated. Other projects using GMR
might want to check if any instructions were added to their projects
that may need to be updated with this information.

Thanks!
Sean

> 
> On Wed, Oct 21, 2015 at 1:29 PM, Sean McGinnis 
> wrote:
> 
> > On Wed, Oct 21, 2015 at 02:43:39PM +0200, Kashyap Chamarthy wrote:
> > > Background
> > > --
> > >
> > > Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> > > mechanism that allows one to capture the current state of a Nova
> > > process/executable (e.g. `nova-compute`, `nova-api`, etc).
> > >
> > > The way to generate the error report is to supply the 'User-defined
> > > signal', SIGUSR1, when killing a Nova process.  E.g.
> > >
> > > $ kill -USR1 `pgrep nova-compute`
> > >
> > > which results in GMR being printed to your standard error ('stderr')
> > > stream, wherever it ends up being redirected to (e.g. to a corresponding
> > > Nova process-specific log file, otherwise, on systemd-enabled systems,
> > > to its journal).
> > >
> > >
> > > Change in Mitaka (and above)
> > > 
> > >
> > > From the upcoming Mitaka release onwards, the default expected UNIX
> > > signal to generate GMR has been changed[1] from USR1 to USR2 (another
> > > User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
> > > for its own purpose.
> > >
> > > So, to generate GMR, from Mitaka release:
> > >
> > > $ kill -USR2 `pgrep nova-compute`
> > >
> > > A corresponding Nova documentation change[2] has been submitted to
> > > reflect this new reality.
> >
> >
> > Do you know if anyone is working on updating all projects that GMR was
> > added to? Or should we each look at our own projects and make the
> > necessary changes?
> >
> >
> > >
> > >
> > > [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
> > > Use SIGUSR2 instead of SIGUSR1
> > > [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
> > > instructions to generate GMR error reports
> > >
> > >
> > > [*] References
> > > --
> > >
> > > Related reading:
> > >
> > > - http://docs.openstack.org/developer/nova/gmr.html
> > > - http://docs.openstack.org/developer/oslo.reports/usage.html
> > > - https://wiki.openstack.org/wiki/GuruMeditationReport
> > > -
> > https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> > >
> > > --
> > > /kashyap
> > >
> > >
> > __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-21 Thread Sean McGinnis 
On Wed, Oct 21, 2015 at 02:43:39PM +0200, Kashyap Chamarthy wrote:
> Background
> --
> 
> Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
> mechanism that allows one to capture the current state of a Nova
> process/executable (e.g. `nova-compute`, `nova-api`, etc).
> 
> The way to generate the error report is to supply the 'User-defined
> signal', SIGUSR1, when killing a Nova process.  E.g.
> 
> $ kill -USR1 `pgrep nova-compute`
> 
> which results in GMR being printed to your standard error ('stderr')
> stream, wherever it ends up being redirected to (e.g. to a corresponding
> Nova process-specific log file, otherwise, on systemd-enabled systems,
> to its journal).
> 
> 
> Change in Mitaka (and above)
> 
> 
> From the upcoming Mitaka release onwards, the default expected UNIX
> signal to generate GMR has been changed[1] from USR1 to USR2 (another
> User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
> for its own purpose.
> 
> So, to generate GMR, from Mitaka release:
> 
> $ kill -USR2 `pgrep nova-compute`
> 
> A corresponding Nova documentation change[2] has been submitted to
> reflect this new reality.


Do you know if anyone is working on updating all projects that GMR was
added to? Or should we each look at our own projects and make the
necessary changes?


> 
> 
> [1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
> Use SIGUSR2 instead of SIGUSR1 
> [2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
> instructions to generate GMR error reports
> 
> 
> [*] References
> --
> 
> Related reading:
> 
> - http://docs.openstack.org/developer/nova/gmr.html
> - http://docs.openstack.org/developer/oslo.reports/usage.html
> - https://wiki.openstack.org/wiki/GuruMeditationReport
> - 
> https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/
> 
> -- 
> /kashyap
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev