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@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@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@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@redhat.com
> <
mailto:rdo-list-unsubscribe@redhat.com>
>
>