Good plan, but I really hate the name of this blueprint. I think we should stop lumping different unrelated HA improvements into a single blueprint with a generic name like that, especially when we already had a blueprint with essentially the same name (ha-pacemaker-improvements). There's nothing wrong with having 4 trivial but specific blueprints instead of one catch-all.
On Wed, Nov 12, 2014 at 4:10 AM, Aleksandr Didenko <adide...@mirantis.com> wrote: > HI, > > in order to make sure some critical Haproxy backends are running (like mysql > or keystone) before proceeding with deployment, we use execs like [1] or > [2]. > > We're currently working on a minor improvements of those execs, but there is > another approach - we can replace those execs with puppet resource providers > and move all the iterations/loops/timeouts logic there. Also we should fail > catalog compilation/run if those resource providers are not able to ensure > needed Haproxy backends are up and running. Because there is no point to > proceed with deployment if keystone is not running, for example. > > If no one objects, I can start implementing this for Fuel-6.1. We can > address it as a part of pacemaker improvements BP [3] or create a new BP. > > [1] > https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/manifests/cluster_ha.pp#L551-L572 > [2] > https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/openstack/manifests/ha/mysqld.pp#L28-L33 > [3] https://blueprints.launchpad.net/fuel/+spec/pacemaker-improvements > > Regards, > Aleksandr Didenko > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Dmitry Borodaenko _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
