Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack
services that run on a controller node are completely stateless.
Therefore, I don't see any reason to use corosync/pacemaker for management
of these resources.
I see following reasons for managing neutron agents by
Hi Sergey! Comments inline.
On 11/20/2014 05:25 AM, Sergey Vasilenko wrote:
Nor should it, IMO. Other than the Neutron dhcp-agent, all OpenStack
services that run on a controller node are completely stateless.
Therefore, I don't see any reason to use corosync/pacemaker for
Hi everyone
Actually, we changed a lot in 5.1 HA and there are some changes in 6.0
also. Right now we are using assymetric cluster and use location
constraints to control resources. We started using xml diffs as the most
reliable and supported approach as it does not depend on pcs/crmsh
Hi crew,
Please see my inline comments.
Hi Everyone,
I was reading the blueprints mentioned here and thought I'd take the
opportunity to introduce myself and ask a few questions.
For those that don't recognise my name, Pacemaker is my baby - so I take a
keen interest helping people have a
On 11/18/2014 07:25 PM, Andrew Woodward wrote:
On Tue, Nov 18, 2014 at 3:18 PM, Andrew Beekhof abeek...@redhat.com wrote:
* Openstack services are not managed by Pacemaker
Oh?
fuel doesn't (currently) set up API services in pacemaker
Nor should it, IMO. Other than the Neutron dhcp-agent,
On 20 Nov 2014, at 6:55 am, Sergii Golovatiuk sgolovat...@mirantis.com
wrote:
Hi crew,
Please see my inline comments.
Hi Everyone,
I was reading the blueprints mentioned here and thought I'd take the
opportunity to introduce myself and ask a few questions.
For those that don't
Hi Everyone,
I was reading the blueprints mentioned here and thought I'd take the
opportunity to introduce myself and ask a few questions.
For those that don't recognise my name, Pacemaker is my baby - so I take a keen
interest helping people have a good experience with it :)
A couple of items
Some comments inline
On Tue, Nov 18, 2014 at 3:18 PM, Andrew Beekhof abeek...@redhat.com wrote:
Hi Everyone,
I was reading the blueprints mentioned here and thought I'd take the
opportunity to introduce myself and ask a few questions.
For those that don't recognise my name, Pacemaker is my
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 used to do the API waiting in the puppet resource
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
+1 for ha-pacemaker-improvements
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Fri, Nov 14, 2014 at 11:51 PM, Dmitry Borodaenko
dborodae...@mirantis.com wrote:
Good plan, but I really hate the name of this blueprint. I think we
should stop lumping different unrelated HA
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
12 matches
Mail list logo
