Transition to SIGUSR2 in oslo.reports breaks upgrade

[Sean Dague]

oslo.reports moved from registering SIGUSR1 as it's handler to SIGUSR2 without an overlap period. This means that it's not possible to have a tool which can create oslo report dumps during an upgrade environment. If you make the tool send SIGUSR2 it will kill the old services. If you keep with SIGUSR1 you lose data.

We need a transition plan.

Which means we need to have a deprecation period for SIGUSR1 (my preference is 2 cycles). It's true that under mod_wsgi this isn't going to work, but it won't break folks that are currently working. Then once all components in an environment is on the new thing we can move to new tools that us SIGUSR2.

This can been seen failing here - https://review.openstack.org/#/c/238479/

[Davanum Srinivas (DIMS) (dims-v)]

I think we should have an option which someone can toggle to
* handle SIGUSR1
* handle SIGUSR2
* handle both SIGUSR1 and SIGUSR2

For Mitaka, we should probably use option #3 as the default and then switch the default to #2 in later releases. Is this a good idea? or a bad idea?

[Matt Riedemann (mriedem)]

Are we going to revert https://review.openstack.org/#/c/223133/ ? It's already in 0.6.0 and 0.7.0 and we've updated some docs in at least nova for using this with SIGUSR2.

[Davanum Srinivas (DIMS) (dims-v)]

Fixed in https://review.openstack.org/#/c/240371/