Open Stack

On Thu, Jul 21, 2016 at 5:47 PM, James Slagle <james.slagle at gmail.com>
wrote:

> On Tue, Jul 19, 2016 at 5:15 PM, Wesley Hayutin <whayutin at redhat.com>
> wrote:
> >
> >
> > On Tue, Jul 19, 2016 at 2:44 PM, James Slagle <james.slagle at gmail.com>
> > wrote:
> >> 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.
>
> Yes, I saw his email shortly after sending my reply. There is a lot to
> digest there, but it sounds promising. Perhaps we could start with
> something small and iteratively consume the generated docs as well. We
> could replace the manual docs over time by including sphinx docs at
> the right places that were automatically generated.
>

Agree,
He has a small example project where I think you could track the work and
progress.
https://github.com/HarryRybacki/tripleo-documentor

We're hoping to have the undercloud and overcloud steps templated and built
in the very near future.


> >
> >>
> >>
> >> 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!
>
> Sure, I don't think this is something we have to decide right away. As
> common roles emerge we could hopefully standardize on those, and if it
> makes sense to split them out into their own repo at some point, we
> could do that to.
>

Ack and thanks.
Have a good night!

>
> --
> -- 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/20160721/256390fd/attachment.html>