<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 12:25 PM, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">From what I've seen of the IRC discussion it sounds like we're doing<br>
this, but can we at least agree that it is a bad way to handle service<br>
replacement?<br>
<br>
First, we are completely replacing a service on a minor upgrade, which<br>
even if it is a 100% compatible drop-in replacement may have<br>
implications for deployers around things like their monitoring setup.<br>
To me this is a pretty big violation of user expectations around what<br>
happens in a minor upgrade.<br></blockquote><div><br></div><div>I completely understand the concern here and I fully agree that doing this in a minor update is not something that stable branch policy agrees with, even if its fully backward compatible. I'm open to suggestions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Second, if I'm understanding the problem we're trying to solve here, it<br>
means that on major upgrades we are leaving the controller services<br>
upgraded but unconfigured for the duration of the upgrade.  That means<br>
if something happens and pacemaker restarts a service then all hell may<br>
break loose.  I've actually run into this problem on undercloud upgrades<br>
because the package update restarts the services automatically, and if<br>
we haven't run puppet yet sometimes the old configs don't work with the<br>
new service.<br></blockquote><div><br></div><div><br></div><div>This is exactly the problem. If we can come up with a way to handle this, we dont need to backport. Would it be possible to run puppet after the controller upgrade runs and then re-run after compute upgrades again? Considering puppet runs should be idempotent?</div><div><br></div><div> It would be good to prioritize handling this use case as sooner or later we will run into this again.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I understand that there are technical reasons things work the way they<br>
do today, but I also want to be on record that this is a problem to be<br>
solved, not a precedent to be followed in the future.<br>
<span class=""><br></span></blockquote><div><br></div><div>Thanks,</div><div>~ Prad</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
On 05/16/2016 09:34 AM, Pradeep Kilambi wrote:<br>
> Hi Everyone:<br>
><br>
> I wanted to start a discussion around considering backporting Aodh to<br>
> stable/liberty for upgrades. We have been discussing quite a bit on<br>
> whats the best way for our users to upgrade ceilometer alarms to Aodh<br>
> when moving from liberty to mitaka. A quick refresh on what changed, In<br>
> Mitaka, ceilometer alarms were replaced by Aodh. So only way to get<br>
> alarms functionality is use aodh. Now when the user kicks off upgrades<br>
> from liberty to Mitaka, we want to make sure alarms continue to function<br>
> as expected during the process which could take multiple days. To<br>
> accomplish this I propose the following approach:<br>
><br>
> * Backport Aodh functionality to stable/liberty. Note, Aodh<br>
> functionality is backwards compatible, so with Aodh running, ceilometer<br>
> api and client will redirect requests to Aodh api. So this should not<br>
> impact existing users who are using ceilometer api or client.<br>
><br>
> * As part of Aodh deployed via heat stack update, ceilometer alarms<br>
> services will be replaced by openstack-aodh-*. This will be done by the<br>
> puppet apply as part of stack convergence phase.<br>
><br>
> * Add checks in the Mitaka pre upgrade steps when overcloud install<br>
> kicks off to check and warn the user to update to liberty + aodh to<br>
> ensure aodh is running. This will ensure heat stack update is run and,<br>
> if alarming is used, Aodh is running as expected.<br>
><br>
> The upgrade scenarios between various releases would work as follows:<br>
><br>
</span>> *Liberty -> Mitaka<br>
> *<br>
<span class="">> * Upgrade starts with ceilometer alarms running<br>
> * A pre-flight check will kick in to make sure Liberty is upgraded to<br>
> liberty + aodh with stack update<br>
> * Run heat stack update to upgrade to aodh<br>
> * Now ceilometer alarms should be removed and Aodh should be running<br>
> * Proceed with mitaka upgrade<br>
> * End result, Aodh continue to run as expected<br>
><br>
</span>> *Liberty + aodh -> Mitaka:<br>
<span class="">> *<br>
> * Upgrade starts with Aodh running<br>
> * A pre-flight check will kick in to make sure Liberty is upgraded to<br>
> Aodh with stack update<br>
> * Confirming Aodh is indeed running, proceed with Mitaka upgrade with<br>
> Aodh running<br>
> * End result, Aodh continue to be run as expected<br>
><br>
><br>
> This seems to be a good way to get the upgrades working for aodh. Other<br>
> less effective options I can think of are:<br>
><br>
> 1. Let the Mitaka upgrade kick off and do "yum update" which replace<br>
> aodh during migration, alarm functionality will be down until puppet<br>
> converge runs and configures Aodh. This means alarms will be down during<br>
> upgrade which is not ideal.<br>
><br>
> 2. During Mitaka upgrades, replace with Aodh and add a bash script that<br>
> fully configures Aodh and ensures aodh is functioning. This will involve<br>
> significant work and results in duplicating everything puppet does today.<br>
><br>
> If there are any suggestions please let me know. I'm open to any<br>
> approach that can save us time and effort to get this working.<br>
><br>
> Otherwise if we can agree to consider Aodh backported to Liberty i think<br>
> this will save us time.<br>
><br>
> Let me know what you guys think.<br>
><br>
> Cheers,<br>
> - Prad<br>
><br>
><br>
><br>
><br>
><br>
</span>> __________________________________________________________________________<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>
<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>
</blockquote></div><br></div></div>