[openstack-dev] [TripleO] Aodh upgrades - Request backport exception for stable/liberty

James Slagle james.slagle at gmail.com
Tue May 17 17:31:25 UTC 2016


On Tue, May 17, 2016 at 12:04 PM, Pradeep Kilambi <prad at redhat.com> wrote:
> Thanks Steve. I was under the impression we cannot run puppet at this
> stage. Hence my suggestion to run bash or some script here, but if we
> can find a way to easily wire the existing aodh puppet manifests into
> the upgrade process and get aodh up and running then even better, we
> dont have to duplicate what puppet gives us already and reuse that.

We could add any SoftwareDeployment resource(s) to the templates that
trigger either scripts or puppet.

>
>
>>> At most, it seems we'd have to surround the puppet apply with some
>>> pacemaker commands to possibly set maintenance mode and migrate
>>> constraints.
>>>
>>> The puppet manifest itself would just be the includes and classes for aodh.
>>
>> +1
>>
>>> One complication might be that the aodh packages from Mitaka might
>>> pull in new deps that required updating other OpenStack services,
>>> which we wouldn't yet want to do. That is probably worth confirming
>>> though.
>>
>> It seems like we should at least investigate this approach before going
>> ahead with the backport proposed - I'll -2 the backports pending further
>> discussion and investigation into this alternate approach.
>>
>
> Makes sense to me. I understand the hesitation behind backports. I'm
> happy to work with jistr and slagle to see if this is a viable
> alaternative. If we can get this working without too much effort, i'm
> all for dumping the backports and going with this.

Using a liberty overcloud-full image, I enabled the mitaka repos and
tried to install aodh:
http://paste.openstack.org/show/497395/

It looks like it will cleanly pull in just aodh packages, and there
aren't any transitive dependencies thatt require updating any other
OpenStack services.

That means that we ought to be able to take a liberty cloud and update
it to use aodh from mitaka. That could be step 1 of the upgrade. The
operator could pause there for as long as they wanted, and then
continue on with the rest of the upgrade of the other services to
Mitaka. It may even be possible to implement them as separate stack
updates.

Does that sound like it could work? Would we have to update some parts
of Ceilometer as well, or does Liberty Ceilometer and Mitaka Aodh work
together nicely?

-- 
-- James Slagle
--



More information about the OpenStack-dev mailing list