<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 5:47 PM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On Tue, Jul 19, 2016 at 5:15 PM, Wesley Hayutin <<a href="mailto:whayutin@redhat.com">whayutin@redhat.com</a>> wrote:<br>
><br>
><br>
> On Tue, Jul 19, 2016 at 2:44 PM, James Slagle <<a href="mailto:james.slagle@gmail.com">james.slagle@gmail.com</a>><br>
> wrote:<br>
</span><span class="">>> Part of the goal of tripleo.sh was to mirror the commands in the<br>
>> documentation...that the same commands in the docs are in tripleo.sh.<br>
>> I know that has somewhat failed, but it was the goal anyway.<br>
>><br>
>> Do you think integrating ansible into tripleo-ci changes that at all?<br>
>> tripleo-ci would be using ansible in some places, which in turn runs<br>
>> the commands (or their equivalent) that we actually document. Is the<br>
>> documentation still showing the same commands it does now, or is it<br>
>> showing running ansible as tripleo-ci would be doing?<br>
><br>
><br>
> Harry Rybacki and I are working on this now.  I think we have something that<br>
> is reasonable for when shell can be used and when ansible modules are<br>
> required.  I think he can make all this work public and everyone in TripleO<br>
> can keep tabs on the progress.<br>
<br>
</span>Yes, I saw his email shortly after sending my reply. There is a lot to<br>
digest there, but it sounds promising. Perhaps we could start with<br>
something small and iteratively consume the generated docs as well. We<br>
could replace the manual docs over time by including sphinx docs at<br>
the right places that were automatically generated.<br></blockquote><div><br></div><div>Agree,</div><div>He has a small example project where I think you could track the work and progress.</div><div><a href="https://github.com/HarryRybacki/tripleo-documentor">https://github.com/HarryRybacki/tripleo-documentor</a><br></div><div><br></div><div>We're hoping to have the undercloud and overcloud steps templated and built in the very near future.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div><div class="h5"><br>
><br>
>><br>
>><br>
>> I think I'm mostly in agreement with your #2 proposal, perhaps with<br>
>> the exception of having to rely on external roles. I don't think I<br>
>> would want to see tripleo-ci rely on ansible roles from a<br>
>> redhat-openstack organization on github.<br>
>><br>
>> I know that we already have a lot of external dependencies in TripleO,<br>
>> and that not everything has to come from <a href="http://git.openstack.org" rel="noreferrer" target="_blank">git.openstack.org</a>. However, I<br>
>> think that we'd want to make the "source" for tripleo-ci be owned by<br>
>> the TripleO project and hosted by OpenStack infrastructure as much as<br>
>> possible. tripleo-quickstart already is, so I think it would be fine<br>
>> to start proposing some changes to tripleo-ci that use<br>
>> tripleo-quickstart to eliminate some duplication if everyone agrees<br>
>> with that. Maybe the repo-setup would be a good first iterative step.<br>
>><br>
>> As for the external roles, I'm less of a fan of relying on these<br>
>> directly if they're not part of TripleO. I think the project should<br>
>> have ownership over how it's defined in CI to deploy/update/upgrade<br>
>> overclouds, etc.<br>
><br>
><br>
> +1 I think this can be handled in a couple ways depending on how many<br>
> additional git repos are acceptable to TripleO upstream.<br>
><br>
> So maybe if I provide an example this will make more sense.  I think bare<br>
> metal will work as an example.<br>
><br>
> There is a need for the code that drives CI for virt to be able to drive CI<br>
> for bare metal.  Certainly the bare metal use case will not be used nearly<br>
> as much as the virt workflow and I suspect we don't want code conflicts,<br>
> merge issues coming from the bare metal use case that may interrupt or block<br>
> the mainline virt use case.  I think TripleO still cares what the bare metal<br>
> code looks like, how it's developed, and if we can use it w/ 3rd party CI<br>
> and extra checks.  It's important to maintain bare metal roles in TripleO<br>
> but it's easier if they are in another git repository.   It also<br>
> demonstrates the composability of the CI.<br>
><br>
> Another use case would be anything that may be downstream specific.  I can't<br>
> think of a great example atm, but there are use cases that CI should be able<br>
> to drive that will probably never be part of the mainstream tripleo ci jobs.<br>
><br>
> I believe we can solve this by having just two git repos in the long run.  I<br>
> think one git repo would be for any code path that is used directly in a job<br>
> in tripleo-ci itself.  The second repo would contain multiple ansible roles,<br>
> call it tripleo-ci-extras.  The second repo would contain any extra roles<br>
> that need to be plugged in for a use case that is not in a tripleo-ci job<br>
> itself.  This would allow TripleO to manage and review the code w/o<br>
> impacting the day to day business of tripleo-ci.<br>
><br>
> Something like:<br>
><br>
> <a href="http://github.com/openstack/tripleo-ci-extras" rel="noreferrer" target="_blank">github.com/openstack/tripleo-ci-extras</a><br>
><br>
> /ansible-role-upgrades<br>
> /ansible-role-image-build<br>
> /ansible-role-baremetal-undercloud<br>
> /ansible-role-baremetal-undercloud-post<br>
> /ansible-role-baremetal-overcloud<br>
>   /defaults<br>
>   /tasks/<br>
>   /templates<br>
>   setup.cfg<br>
><br>
>><br>
>> Are the roles generic enough that we could propose these as part of<br>
>> TripleO directly as new repos, and is there interest in doing that?<br>
><br>
><br>
> That is also a possibility.  I think we'd have to take a hard look at some<br>
> of these roles and determine whether or not it's worth having it's own git<br>
> repo.<br>
> Most are fairly generic imho.  For instance the image-build role can build<br>
> images for tripleo, rdo, or rhos, the bare metal roles don't have any<br>
> environment specific code they just expect the settings provided to the job<br>
> to describe the environment in a particular way.   The upgrade role can be<br>
> used for any tripleo version upstream or downstream.<br>
><br>
> IMHO I think bare metal, upgrades, and image builds would be good candidates<br>
> for their own upstream git repo.  Many of the other roles could be combined<br>
> in a single git repo to avoid the pain of git repo explosion.  I think we<br>
> can work w/ either approach, the most important thing is to start removing<br>
> the duplication as you said!<br>
<br>
</div></div>Sure, I don't think this is something we have to decide right away. As<br>
common roles emerge we could hopefully standardize on those, and if it<br>
makes sense to split them out into their own repo at some point, we<br>
could do that to.<br></blockquote><div><br></div><div>Ack and thanks. </div><div>Have a good night! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class=""><div class="h5"><br>
--<br>
-- James Slagle<br>
--<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>