6:29 a.m.
________________________________
From: Raoul Scarazzini <rasca(a)redhat.com Sent:
Monday, August 22, 2016 3:51 AM
To: Wesley Hayutin; Boris Derzhavets; Attila Darazs
Cc: David Moreau Simard; rdo-list
Subject: Re: [rdo-list] Instack-virt-setup vs TripleO QuickStart in regards of managing HA
PCS/Corosync cluster via pcs CLI
Hi everybody,
sorry for the late response but I was on PTO. I don't understand the
meaning of the cleanup commands, but maybe it's just because I'm not
getting the whole picture.
I have to confirm that fault was mine PCS CLI is working on
TripeO QuickStart
but requires pcs cluster restart on particular node which went down
via ` nova stop controller-X` and was brought up via `nova start controller-X`
Details here :-
http://bderzhavets.blogspot.ru/2016/08/emulation-rdo-triple0-quickstart-h...
VENV been set up with instack-virt-setup doesn't require ( on bounced Controller node
)
# pcs cluster stop
# pcs cluster start
Before issuing start.sh
#!/bash -x
pcs resource cleanup rabbitmq-clone ;
sleep 10
pcs resource cleanup neutron-server-clone ;
sleep 10
pcs resource cleanup openstack-nova-api-clone ;
sleep 10
pcs resource cleanup openstack-nova-consoleauth-clone ;
sleep 10
pcs resource cleanup openstack-heat-engine-clone ;
sleep 10
pcs resource cleanup openstack-cinder-api-clone ;
sleep 10
pcs resource cleanup openstack-glance-registry-clone ;
sleep 10
pcs resource cleanup httpd-clone ;
# . ./start.sh
In worse case scenario I have to issue start.sh twice from different Controllers
pcs resource cleanup openstack-nova-api-clone attempts to start corresponding
service , which is down at the moment. In fact two cleanups above start all
Nova Services && one neutron cleanup starts all neutron agents as well.
I was also kept track of Galera DB via `clustercheck`
Thanks.
Boris
I guess we're hitting a version problem here: if you deploy the actual
master (i.e. with quickstart) you'll get the environment with the
constraints limited to the core services because of [1] and [2] (so none
of the mentioned services exists in the cluster configuration).
Hope this helps,
[1] https://review.openstack.org/#/c/314208/
[2] https://review.openstack.org/#/c/342650/
--
Raoul Scarazzini
rasca(a)redhat.com
On 08/08/2016 14:43, Wesley Hayutin wrote:
> Attila, Raoul
> Can you please investigate this issue.
> Thanks!
> On Sun, Aug 7, 2016 at 3:52 AM, Boris Derzhavets
> <bderzhavets(a)hotmail.com <mailto:bderzhavets@hotmail.com>> wrote:
> TripleO HA Controller been installed via
instack-virt-setup has PCS
> CLI like :-
> pcs resource cleanup neutron-server-clone
> pcs resource cleanup openstack-nova-api-clone
> pcs resource cleanup openstack-nova-consoleauth-clone
> pcs resource cleanup openstack-heat-engine-clone
> pcs resource cleanup openstack-cinder-api-clone
> pcs resource cleanup openstack-glance-registry-clone
> pcs resource cleanup httpd-clone
> been working as expected on bare metal
> Same cluster been setup via
QuickStart (Virtual ENV) after bouncing
> one of controllers
> included in cluster ignores PCS CLI at least via my
experience (
> which is obviously limited
> either format of particular commands is wrong for
QuickStart )
> I believe that dropping (complete replacing )
instack-virt-setup is
> not a good idea in general. Personally, I believe that like in case
> with packstack it is always good
> to have VENV configuration been tested before going to
bare metal
> deployment.
> My major concern is maintenance and disaster recovery
tests , rather
> then deployment itself . What good is for me TripleO Quickstart
> running on bare metal if I cannot replace
> crashed VM Controller just been limited to Services HA
( all 3
> Cluster VMs running on single
> bare metal node )
> Thanks
> Boris.
>
------------------------------------------------------------------------
>
_______________________________________________
> rdo-list mailing list
> rdo-list(a)redhat.com <mailto:rdo-list@redhat.com >
https://www.redhat.com/mailman/listinfo/rdo-list
> <https://www.redhat.com/mailman/listinfo/rdo-list > To unsubscribe: rdo-list-unsubscribe(a)redhat.com
> <mailto:rdo-list-unsubscribe@redhat.com