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

Wed Aug 24 12:21:01 UTC 2016

________________________________
From: Raoul Scarazzini <rasca at redhat.com>
Sent: Wednesday, August 24, 2016 11:34 AM
To: Boris Derzhavets; Wesley Hayutin; Attila Darazs
Cc: rdo-list
Subject: Re: [rdo-list] Instack-virt-setup vs TripleO QuickStart in regards of managing HA PCS/Corosync cluster via pcs CLI

On 24/08/2016 09:54, Boris Derzhavets wrote:
[...]
> - Which version are you using? The latest? So are you installing from
> master?
>>
> No idea. My actions :-
>
> $  rm -fr .ansible .quickstart tripleo-quickstart
> $  git clone https://github.com/openstack/tripleo-quickstart
[https://avatars0.githubusercontent.com/u/324574?v=3&s=400]<https://github.com/openstack/tripleo-quickstart>

GitHub - openstack/tripleo-quickstart: Ansible based ...<https://github.com/openstack/tripleo-quickstart>
github.com
tripleo-quickstart - Ansible based project for setting up TripleO virtual environments

> $  cd tripleo*
> $ ssh root@$VIRTHOST uname -a
> $ vi /config/general_config/ha.yml  ==> to tune && save
> $ bash quickstart.sh --config ./config/general_config/ha.yml   $VIRTHOST

OK, it can be useful to see what's inside ha.yml, but the command you
mentioned does not specify a branc, so it uses "master", so Newton, so
you're using a totally different setup from mitaka, especially from a
cluster perspective.
========================================================================
Addressing your requests
========================================================================
[boris at fedora24wks tripleo-quickstart]$ cat ./config/general_config/ha.yml
# Deploy an HA openstack environment.
#
# This will require (6144 * 4) == approx. 24GB for the overcloud
# nodes, plus another 8GB for the undercloud, for a total of around
# 32GB.
control_memory: 6144
compute_memory: 6144
default_vcpu: 2

undercloud_memory: 8192

# Giving the undercloud additional CPUs can greatly improve heat's
# performance (and result in a shorter deploy time).
undercloud_vcpu: 2

# Create three controller nodes and one compute node.
overcloud_nodes:
  - name: control_0
    flavor: control
  - name: control_1
    flavor: control
  - name: control_2
    flavor: control

  - name: compute_0
    flavor: compute
  - name: compute_1
    flavor: compute
# We don't need introspection in a virtual environment (because we are
# creating all the "hardware" we really know the necessary
# information).
step_introspect: true

# Tell tripleo about our environment.
network_isolation: true
extra_args: >-
  --control-scale 3 --compute-scale 2 --neutron-network-type vxlan
  --neutron-tunnel-types vxlan
  --ntp-server pool.ntp.org
test_tempest: false
test_ping: true
enable_pacemaker: true

$ bash quickstart.sh --config ./config/general_config/ha.yml   $VIRTHOST

EXIT ( undrecloud has been built )

##################################
Virtual Environment Setup Complete
##################################

Access the undercloud by:

    ssh -F /home/boris/.quickstart/ssh.config.ansible undercloud

There are scripts in the home directory to continue the deploy:

    overcloud-deploy.sh will deploy the overcloud
    overcloud-deploy-post.sh will do any post-deploy configuration
    overcloud-validate.sh will run post-deploy validation

Alternatively, you can ignore these scripts and follow the upstream docs,
starting from the overcloud deploy section:

    http://ow.ly/1Vc1301iBlb

##################################
Virtual Environment Setup Complete
##################################

[boris at fedora24wks tripleo-quickstart]$ ssh -F /home/boris/.quickstart/ssh.config.ansible undercloud
Warning: Permanently added '192.168.1.74' (ECDSA) to the list of known hosts.
Warning: Permanently added 'undercloud' (ECDSA) to the list of known hosts.
Last login: Wed Aug 24 12:13:16 2016 from gateway

[stack at undercloud ~]$ sudo su -

[root at undercloud stack]# cd /etc/yum.repos.d
[root at undercloud yum.repos.d]# ls -l
total 40
-rw-r--r--. 1 root root 1664 Dec  9  2015 CentOS-Base.repo
-rw-r--r--. 1 root root 1057 Aug 24 02:58 CentOS-Ceph-Hammer.repo
-rw-r--r--. 1 root root 1309 Dec  9  2015 CentOS-CR.repo
-rw-r--r--. 1 root root  649 Dec  9  2015 CentOS-Debuginfo.repo
-rw-r--r--. 1 root root  290 Dec  9  2015 CentOS-fasttrack.repo
-rw-r--r--. 1 root root  630 Dec  9  2015 CentOS-Media.repo
-rw-r--r--. 1 root root 1331 Dec  9  2015 CentOS-Sources.repo
-rw-r--r--. 1 root root 1952 Dec  9  2015 CentOS-Vault.repo
-rw-r--r--. 1 root root  162 Aug 24 02:58 delorean-deps.repo
-rw-r--r--. 1 root root  220 Aug 24 02:58 delorean.repo

[root at undercloud yum.repos.d]# cat delorean-deps.repo
[delorean-mitaka-testing]
name=dlrn-mitaka-testing
baseurl=http://buildlogs.centos.org/centos/7/cloud/$basearch/openstack-mitaka/
enabled=1
gpgcheck=0
priority=2

[root at undercloud yum.repos.d]# cat delorean.repo
[delorean]
name=delorean-openstack-rally-3909299306233247d547bad265a1adb78adfb3d4
baseurl=http://trunk.rdoproject.org/centos7-mitaka/39/09/3909299306233247d547bad265a1adb78adfb3d4_4e6dfa3c
enabled=1
gpgcheck=0

Thanks
Boris.
===================================================================================
> When I get prompt to login to undercloud
> /etc/yum.repos.d/  contains delorean.repo ( on fresh undercloud QS build )
> files pointing to Mitaka Delorean trunks.
> Just check for yourself.

Where can I check? On the link you posted I cannot find these files from
the quickstart installation...

> - Are the two versions the same while using quickstart and
> instack-virt-setup?
> No the versions are different ( points in delorean.repos differ )

This could have a great impact while comparing results.

> - Do we have some logs to look at?
> Sorry, it was not my concern.
> My primary target was identify sequence of steps
> which brings PCS Cluster to proper state with 100% warranty.

This is strictly related on all the stuff I've mentioned above. Things
must work without workarounds like cleanup or similar things. If
something breaks and we're using correct setup steps then we're in front
of a bug.
But to analyze a bug we need logs.

> Again, I think here we're hitting a version issure.
> I tested  QuickStart ( obtained just at the same time on different box)
> delorean.repo files in instack-virt-setup build of VENV
> It doesn't change much final overcloud cluster behavior.
> I am aware of this link is outdated ( due to  Wesley  Hayutin respond )
> https://bluejeans.com/s/a5ua/
> However , my current understanding of QuickStart CI ( not TripleO CI )
>  is based on this video
> I believe the core reason is the way how Tripleo QS assembles undercloud
> for VENV build.
> It makes HA Controllers cluster pretty stable and always recoverable
> (VENV case)

The VENV should not matter at all in terms of cluster configuration on
the overcloud.

> It is different from official way at least in meantime.
> I've already wrote TripleO QS nowhere issues :-
> $ openstack overcloud images build --all  ===> that is supposed to be
> removed
> as far as I understand  TripleO Core team intend.
> Boris.

As I said there's a lot of mix inside the repo and thins makes the debug
really difficult.

--
Raoul Scarazzini
rasca at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20160824/0086c031/attachment.html>