[rdo-list] Multiple tools for deploying and testing TripleO

[James Slagle]

On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote:
> Please hear me out.
> TL;DR, Let's work upstream and make it awesome so that downstream can
> be awesome.
> 
> I've said this before but I'm going to re-iterate that I do not
> understand why there is so much effort spent around testing TripleO
> downstream.
> By downstream, I mean anything that isn't in TripleO or TripleO-CI proper.
> 
> All this work should be done upstream to make TripleO and it's CI
> super awesome and this would trickle down for free downstream.
> 
> The RDO Trunk testing pipeline is composed of two tools, today.
> The TripleO-Quickstart project [1] is a good example of an initiative
> that started downstream but always had the intention of being proposed
> upstream [2] after being "incubated" and fleshed out.

tripleo-quickstart was proposed to upstream TripleO as a replacement for the
virtual environment setup done by instack-virt-setup. 3rd party CI would be
used to gate tripleo-quickstart so that we'd be sure the virt setup was always
working. That was the extent of the CI scope defined in the spec. That work is
not yet completed (see work items in the spec).

Now it seems it is a much more all encompassing CI/automation/testing project
that is competing in scope with tripleo-ci itself.

I'm all for consolidation of these types of tools *if* there is interest.

However, IMO, incubating these things downstream and then trying to get them
upstream or get upstream to adopt them is not ideal or a good example. The same
topic came up and was pushed several times with khaleesi, and it just never
happened, it was continually DOA upstream.

I think it would be fairly difficult to get tripleo-ci to wholesale adopt
tripleo-quickstart at this stage. The separate irc channel from #tripleo is not
conducive to consolidation on tooling and direction imo.

The scope of quickstart is actually not fully understood by myself. I've also
heard from some in the upstream TripleO community as well who are confused by
its direction and are facing similar difficulties using its generated bash
scripts that they'd be facing if they were just using TripleO documentation
instead.

I do think that this sort of problem lends itself easily to one off
implementations as is quite evidenced in this thread. Everyone/group wants and
needs to automate something in a different way. And imo, none of these tools
are building end-user or operator facing interfaces, so they're not fully
focused on building something that "just works for everyone". Those interfaces
should be developed in TripleO user facing tooling anyway
(tripleoclient/openstackclient/etc).

So, I actually think it's ok in some degree that things have been automated
differently in different tools. Anecdotally, I suspect many users of TripleO in
production have their own automation tools as well. And none of the
implementations mentioned in this thread would likely meet their needs either.

However, if there is a desire to focus resources on consolidated tooling and
someone to drive it forward, then I definitely agree that the effort needs to
start upstream with a singular plan for tripleo-ci. From what I gather, that
would be some sort of alignment and reuse of tripleo-quickstart, and then we
could build from there.

That could start as a discussion and plan within that community with some
agreed on concensus around that plan. There was an initial thread on
openstack-dev related to this topic but it is stalled a bit. It could be
continually driven to resolution via specs, the tripleo meeting, email or irc
discussion until a plan is formed.

--
-- James Slagle
--