3:34 a.m.
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.
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(a)redhat.com