Open Stack

On Tue, Jul 12, 2016 at 03:39:41PM -0400, John Trowbridge 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 think I prefer the incremental conversion to use tripleo-quickstart - if
we're aiming to have that be the one recommended way to bootstrap a tripleo
environment, it should be what we test in CI IMO.

Personally I've avoided switching to tripleo-quickstart locally primarily
because it's not what we test in CI, so it's sometimes harder to reproduce
CI impacting problems (and there were a few dev workflow nits, which may
well have been fixed now) - so anything which can align what *all*
developers and upstream users test with what we CI gets a big +1 from me.

> Personally, I don't think we should do anything drastic with CI until
> after we release Newton, so we don't add any risk of impacting new
> features that haven't landed yet. I do think it would be a good goal for
> Ocata to have a CI system in TripleO that is consumable outside of
> TripleO. In any case, this email is simply to garner feedback if other's
> think this is a worthy thing to pursue and opinions on how we can get there.

Yeah I think this is sensible - unless there are some very low-risk
increments that we can take we should wait until newton ships, but there's
nothing to stop folks working on a series of WIP tripleo-ci patches in the
meantime (that repo is low-traffic enough that the rebase pain probably
won't be too bad?)

Thanks for starting this discussion!

Steve