[openstack-dev] [TripleO] Aodh upgrades - Request backport exception for stable/liberty
prad at redhat.com
Mon May 16 14:34:29 UTC 2016
I wanted to start a discussion around considering backporting Aodh to
stable/liberty for upgrades. We have been discussing quite a bit on whats
the best way for our users to upgrade ceilometer alarms to Aodh when moving
from liberty to mitaka. A quick refresh on what changed, In Mitaka,
ceilometer alarms were replaced by Aodh. So only way to get alarms
functionality is use aodh. Now when the user kicks off upgrades from
liberty to Mitaka, we want to make sure alarms continue to function as
expected during the process which could take multiple days. To accomplish
this I propose the following approach:
* Backport Aodh functionality to stable/liberty. Note, Aodh functionality
is backwards compatible, so with Aodh running, ceilometer api and client
will redirect requests to Aodh api. So this should not impact existing
users who are using ceilometer api or client.
* As part of Aodh deployed via heat stack update, ceilometer alarms
services will be replaced by openstack-aodh-*. This will be done by the
puppet apply as part of stack convergence phase.
* Add checks in the Mitaka pre upgrade steps when overcloud install kicks
off to check and warn the user to update to liberty + aodh to ensure aodh
is running. This will ensure heat stack update is run and, if alarming is
used, Aodh is running as expected.
The upgrade scenarios between various releases would work as follows:
*Liberty -> Mitaka*
* Upgrade starts with ceilometer alarms running
* A pre-flight check will kick in to make sure Liberty is upgraded to
liberty + aodh with stack update
* Run heat stack update to upgrade to aodh
* Now ceilometer alarms should be removed and Aodh should be running
* Proceed with mitaka upgrade
* End result, Aodh continue to run as expected
*Liberty + aodh -> Mitaka:*
* Upgrade starts with Aodh running
* A pre-flight check will kick in to make sure Liberty is upgraded to Aodh
with stack update
* Confirming Aodh is indeed running, proceed with Mitaka upgrade with Aodh
* End result, Aodh continue to be run as expected
This seems to be a good way to get the upgrades working for aodh. Other
less effective options I can think of are:
1. Let the Mitaka upgrade kick off and do "yum update" which replace aodh
during migration, alarm functionality will be down until puppet converge
runs and configures Aodh. This means alarms will be down during upgrade
which is not ideal.
2. During Mitaka upgrades, replace with Aodh and add a bash script that
fully configures Aodh and ensures aodh is functioning. This will involve
significant work and results in duplicating everything puppet does today.
If there are any suggestions please let me know. I'm open to any approach
that can save us time and effort to get this working.
Otherwise if we can agree to consider Aodh backported to Liberty i think
this will save us time.
Let me know what you guys think.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev