On Tue, May 17, 2016 at 1:31 PM, James Slagle <[email protected]> wrote:
> On Tue, May 17, 2016 at 12:04 PM, Pradeep Kilambi <[email protected]> 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? > To install Aodh along side ceilometer in Liberty, we have to explicitly disable or remove ceilometer-alarms services before aodh is installed. Otherwise both the evaluators will step on each other for alarms. But other than that, they should work. ~ Prad > > -- > -- James Slagle > -- > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
