[rdo-list] Instack-virt-setup vs TripleO QuickStart in regards of managing HA PCS/Corosync cluster via pcs CLI

[Boris Derzhavets]

________________________________
From: Raoul Scarazzini <rasca at 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-ha.html

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 at 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 at hotmail.com <mailto:bderzhavets at 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 at redhat.com <mailto:rdo-list at redhat.com>
>     https://www.redhat.com/mailman/listinfo/rdo-list
>     <https://www.redhat.com/mailman/listinfo/rdo-list>
>
>     To unsubscribe: rdo-list-unsubscribe at redhat.com
>     <mailto:rdo-list-unsubscribe at redhat.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160822/c5e423e5/attachment.html>