[openstack-dev] [tripleo] Future of the tripleo-quickstart-utils project

Emilien Macchi emilien at redhat.com
Wed May 17 02:01:32 UTC 2017

Hey Raoul,

Thanks for putting this up in the ML. Replying inline:

On Tue, May 16, 2017 at 4:59 PM, Raoul Scarazzini <rasca at redhat.com> wrote:
> Hi everybody,
> as discussed in today's TripleO meeting [1] here's a brief recap of the
> tripleo-quickstart-utils topic.
> ### TL;DR ###
> We are trying to understand whether is good or not to put the contents
> of [2] somewhere else for a wider exposure.
> ### Long version ###
> tripleo-quickstart-utils project started after splitting the
> ha-validation stuff from the tripleo-quickstart-extras repo [3],
> basically because the specificity of the topic was creating a leak of
> reviewers.
> Today this repository have three roles:
> 1 - validate-ha: to do ha specific tests depending on the version. This
> role relies on a micro bash framework named ha-test-suite available in
> the same repo, under the utils directory;

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

> 2 - stonith-config: to configure STONITH inside an HA env;

IMHO (and tell me if I'm wrong), this role is something you want to
apply at Day 1 during your deployment, right?
If that's the case, I think the playbooks could really live in THT
where we already have automation to deploy & configure Pacemaker with
Heat and Puppet.
Some tasks might be useful for the upgrade operations but we also have
upgrade_tasks that use Ansible, so possibly easily re-usable.

If it's more Day 2 operations, then we should investigate by creating
a new repository for tripleo with some playbooks useful for Day 2, but
AFIK we've managed to avoid that until now.

> 3 - instance-ha: to configure high availability for instances on the
> compute nodes;

Same as stonith. It sounds like some tasks done during initial
deployment to enable instakce HA and then during upgrade to disable /
enable configurations. I think it could also be done by THT like
stonith configuration.

> Despite of the name, this is not just a tripleo-quickstart related
> project, it is also usable on every TripleO deployed environment, and is
> meant to support all the TripleO OpenStack versions from kilo to pike
> for all the roles it sells;

Great, it means we could easily re-use the bits, modulo some technical

> 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.

> That's basically the meaning of the word "utils" in the name of the repo.
> What I would like to understand is if you see this as something useful
> that can be placed somewhere more near to upstream TripleO project, to
> reach a wider audience for further contribution/evolution.
IIRC, everything in this repo could be moved to existing projects in
TripleO that are already productized, so little efforts would be done.

> ###
> [1]
> http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2017-05-16-14.00.log.html
> [2] https://github.com/redhat-openstack/tripleo-quickstart-utils
> [3]
> https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/validate-ha
> [4]
> https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/docs/multi-virtual-undercloud
> ###
> Thanks for your time,

Thanks for bringing this up!

> --
> Raoul Scarazzini
> rasca at redhat.com
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Emilien Macchi

More information about the OpenStack-dev mailing list