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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
