Open Stack

On Mon, Jan 30, 2017 at 03:07:42PM +0100, Gabriele Cerami wrote:
> On 30 Jan, Paul Belanger wrote:
> 
> > Before you go out an implement some sort of in-repo configuration for testing, I
> > strongly encourage you to read up on our Zuulv3 spec[3], as we are providing
> > this functionality.  What is comes down to, you'll be able to focus on writing
> > tests, where zuul does all the test configuration and provisioning.
> > 
> > [3] https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html
> 
> This is not about provisioning, we concluded we don't want to deal with
> that, quickstart just offers a simple virthost provisioning to improve
> user experience, but users (or other tools) have to deal with any more
> complex topology that may be needed.
> But as this tool was implemented with reproducibility in mind, we don't
> want to consider just uptream as its consumer.
> 
> This effort on the configuration just aims in associating a job name to
> a defined set of features we want to test during tripleo deployment.
> For example:
> When quickstart is called to test a periodic HA ovb on newton, what's
> the best way to build and pass a configuration to quickstart that
> contains all the variables to activate exactly all the features we want
> to test ?
> Passing the right configuration will require some automation, and maybe
> zuul can help at least upsteam, but creating the configuration is a
> manual process, and the results should be consumable by anyone.
> We are focusing on this second part, and I can't see any overlap in zuul
> for that.
> 
I would still encourage you to look at the work we are doing for zuulv3. While
you don't have to directly depend on it for local reproducibility, we do have
some plans to make the concept of 'reproduce.sh' able to run the ansible
playbooks we have created today.

As for passing data, we do something like this today. Zuul has a set of
variables[4] we need to pass into ansible, and Monty came up with a great way to
achieve this using the environment keyword[5].

Continuing on this topic, there even was a patch recently to nodepool to write
out facts for primary / sub nodes, which we could then load into zuul and read
dynamic configuration.

I'm not saying zuul will fix all the things, just talk a look into it before
implementing something only for TripleO.

[4] http://logs.openstack.org/24/425924/2/gate/gate-neutron-pep8-ubuntu-xenial/184b89e/_zuul_ansible/vars.yaml
[5] http://logs.openstack.org/24/425924/2/gate/gate-neutron-pep8-ubuntu-xenial/184b89e/_zuul_ansible/playbook