Open Stack

On Tue, Jul 19, 2016 at 2:44 PM, James Slagle <james.slagle at gmail.com>
wrote:

> 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?
>

Harry Rybacki and I are working on this now.  I think we have something
that is reasonable for when shell can be used and when ansible modules are
required.  I think he can make all this work public and everyone in TripleO
can keep tabs on the progress.


>
> 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.
>

+1 I think this can be handled in a couple ways depending on how many
additional git repos are acceptable to TripleO upstream.

So maybe if I provide an example this will make more sense.  I think bare
metal will work as an example.

There is a need for the code that drives CI for virt to be able to drive CI
for bare metal.  Certainly the bare metal use case will not be used nearly
as much as the virt workflow and I suspect we don't want code conflicts,
merge issues coming from the bare metal use case that may interrupt or
block the mainline virt use case.  I think TripleO still cares what the
bare metal code looks like, how it's developed, and if we can use it w/ 3rd
party CI and extra checks.  It's important to maintain bare metal roles in
TripleO but it's easier if they are in another git repository.   It also
demonstrates the composability of the CI.

Another use case would be anything that may be downstream specific.  I
can't think of a great example atm, but there are use cases that CI should
be able to drive that will probably never be part of the mainstream tripleo
ci jobs.

I believe we can solve this by having just two git repos in the long run.
I think one git repo would be for any code path that is used directly in a
job in tripleo-ci itself.  The second repo would contain multiple ansible
roles, call it tripleo-ci-extras.  The second repo would contain any extra
roles that need to be plugged in for a use case that is not in a tripleo-ci
job itself.  This would allow TripleO to manage and review the code w/o
impacting the day to day business of tripleo-ci.

Something like:

github.com/openstack/tripleo-ci-extras

/ansible-role-upgrades
/ansible-role-image-build
/ansible-role-baremetal-undercloud
/ansible-role-baremetal-undercloud-post
/ansible-role-baremetal-overcloud
  /defaults
  /tasks/
  /templates
  setup.cfg


> 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?
>

That is also a possibility.  I think we'd have to take a hard look at some
of these roles and determine whether or not it's worth having it's own git
repo.
Most are fairly generic imho.  For instance the image-build role can build
images for tripleo, rdo, or rhos, the bare metal roles don't have any
environment specific code they just expect the settings provided to the job
to describe the environment in a particular way.   The upgrade role can be
used for any tripleo version upstream or downstream.

IMHO I think bare metal, upgrades, and image builds would be good
candidates for their own upstream git repo.  Many of the other roles could
be combined in a single git repo to avoid the pain of git repo explosion.
I think we can work w/ either approach, the most important thing is to
start removing the duplication as you said!

Hopefully this makes sense, let me know if clarification is needed.  Thanks
for your comments Slagle!

Thanks!



>
> --
> -- James Slagle
> --
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160719/cac78d05/attachment.html>