Open Stack

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.

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

-- 
-- James Slagle
--