Open Stack

On 17/05/2017 04:01, Emilien Macchi wrote:
> Hey Raoul,
> Thanks for putting this up in the ML. Replying inline:

Sorry for the long delay between the answers, a lot of things on going.

[...]
> I've looked at https://github.com/redhat-openstack/tripleo-quickstart-utils/blob/master/roles/validate-ha/tasks/main.yml
> and I see it's basically a set of tasks that validates that HA is
> working well on the overcloud.
> Despite little things that might be adjusted (calling bash scripts
> from Ansible), I think this role would be a good fit with
> tripleo-validations projects, which is "a collection of Ansible
> playbooks to detect and report potential issues during TripleO
> deployments".

Moving this stuff in the tripleo-validations project would impose a
massive change in the approach HA validation is made today.
The bash script way is something that was used to make someone able to
do the validation even without ansible. Anyone could write his test by
just adding the script inside the test (and recovery) dir.
This is the tech reason behind the choice, and today this is doing great
as it is.
So I think that until I can reserve a slot to make this "port" this can
stay where it is today.

>> 2 - stonith-config: to configure STONITH inside an HA env;
[...]> Great, it means we could easily re-use the bits, modulo some
technical
> adjustments.

Since we're moving into integrating stonith and (hopefully) instance HA
directly inside tripleo, then this can stay where it is today, it would
be useless giving effort in putting this since soon we will have the
same directly inside tripleo.

>> There's also a docs related to the Multi Virtual Undercloud project [4]
>> that explains how to have more than one virtual Undercloud on a physical
>> machine to manage more environments from the same place.
> I would suggest to move it to tripleo-docs, so we have a single place for doc.

Action item for me here: move this document under tripleo-docs. I'm
already preparing a review for this.

[...]
> IIRC, everything in this repo could be moved to existing projects in
> TripleO that are already productized, so little efforts would be done.
[...]> Thanks for bringing this up!

Agreed.

Bye,

-- 
Raoul Scarazzini
rasca at redhat.com