Open Stack

On Tue, Jul 12, 2016 at 3:39 PM, John Trowbridge <trown at redhat.com> wrote:
> Howdy folks,
>
> In the TripleO meeting two weeks ago, it came up that tripleo-quickstart
> is being used as a CI tool in RDO. This came about organically, because
> we needed to use RDO CI to self-gate quickstart (it relies on having a
> baremetal virthost). It displaced another ansible based CI tool there
> (khaleesi) and most(all?) of the extra functionality from that tool
> (upgrades, scale, baremetal, etc.) has been moved into discrete ansible
> roles that are able to plugin to quickstart.[1]
>
> We are still left with two different tool sets, where one should suffice
> (and focus CI efforts in one place).
>
> I see two different ways to resolve this.
>
> 1. Actively work on making the tripleo-ci scripts consumable external to
> tripleo-ci. We have a project in RDO (WeiRDO)[2] that is consuming
> upstream CI for packstack and puppet, so it is not totally far-fetched
> to add support for TripleO jobs.
>
> Pros:
> - All CI development just happens directly in tripleo-ci and RDO just
> inherits that work.
>
> Cons:
> - This is totally untried, and therefore a totally unknown amount of work.
> - It is all or nothing in that there is no incremental path to get the
> CI scripts working outside of CI.
> - We have to rewrite a bunch of working ansible code in bash which IMO
> is the wrong direction for a modern CI system.
>
>
> 2. Actively work on making tripleo-ci consume the ansible work in
> tripleo-quickstart and the external role ecosystem around it.
>
> Pros:
> - This could be done incrementally, replacing a single function from
> tripleo.sh with an invocation of tripleo-quickstart that performs that
> function instead.
> - We would be able to pull in a lot of extra functionality via these
> external roles for free(ish).
>
> Cons:
> - Similarly unknown amount of work to completely switch.
> - CI development would be done in multiple repos, though each would have
> discrete and well defined functionality.

I agree we could consolidate as well. Having tripleo-ci integrated
with ansible would probably be helpful. Some of the work I've been
doing to support multinode jobs would benefit from being able to use
ansible to run some setup tasks on each of the nodes as part of the
job as well.

Part of the goal of tripleo.sh was to mirror the commands in the
documentation...that the same commands in the docs are in tripleo.sh.
I know that has somewhat failed, but it was the goal anyway.

Do you think integrating ansible into tripleo-ci changes that at all?
tripleo-ci would be using ansible in some places, which in turn runs
the commands (or their equivalent) that we actually document. Is the
documentation still showing the same commands it does now, or is it
showing running ansible as tripleo-ci would be doing?

I think I'm mostly in agreement with your #2 proposal, perhaps with
the exception of having to rely on external roles. I don't think I
would want to see tripleo-ci rely on ansible roles from a
redhat-openstack organization on github.

I know that we already have a lot of external dependencies in TripleO,
and that not everything has to come from git.openstack.org. However, I
think that we'd want to make the "source" for tripleo-ci be owned by
the TripleO project and hosted by OpenStack infrastructure as much as
possible. tripleo-quickstart already is, so I think it would be fine
to start proposing some changes to tripleo-ci that use
tripleo-quickstart to eliminate some duplication if everyone agrees
with that. Maybe the repo-setup would be a good first iterative step.

As for the external roles, I'm less of a fan of relying on these
directly if they're not part of TripleO. I think the project should
have ownership over how it's defined in CI to deploy/update/upgrade
overclouds, etc.

Are the roles generic enough that we could propose these as part of
TripleO directly as new repos, and is there interest in doing that?

-- 
-- James Slagle
--