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
<> 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]
> [2]
> [3]
> Regards,
> Aleksandr Didenko
> _______________________________________________
> OpenStack-dev mailing list

Dmitry Borodaenko

OpenStack-dev mailing list

Reply via email to