From: Raoul Scarazzini <rasca@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
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
> $ 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
========================================================================
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@redhat.com
[...]
> - 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
> $ 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@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@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@undercloud ~]$ sudo su -
[root@undercloud stack]# cd /etc/yum.repos.d
[root@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@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@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
# 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@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@undercloud ~]$ sudo su -
[root@undercloud stack]# cd /etc/yum.repos.d
[root@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@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@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@redhat.com