<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 6:20 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:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard <<a href="mailto:dms@redhat.com">dms@redhat.com</a>> wrote:<br>
> On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <<a href="mailto:james.slagle@gmail.com">james.slagle@gmail.com</a>> wrote:<br>
>> (0) tripleo-quickstart which follows the common and well accepted<br>
>> approach to bundling a set of Ansible playbooks/roles.<br>
><br>
> I don't want to de-rail the thread but I really want to bring some<br>
> attention to a pattern that tripleo-quickstart has been using across<br>
> it's playbooks and roles.<br>
> I sincerely hope that we can find a better implementation should we<br>
> start developing new things from scratch.<br>
<br>
</span>Yes, just to clarify...by "well accepted" I just meant how the git<br>
repo is organized and how you are expected to interface with those<br>
playbooks and roles as opposed to what those playbooks/roles actually<br>
do.<br>
<span class="gmail-"><br>
> I'll sound like a broken record for those that have heard me mention<br>
> this before but for those that haven't, here's a concrete example of<br>
> how things are done today:<br>
> (Sorry for the link overload, making sure the relevant information is available)<br>
><br>
> For an example tripleo-quickstart job, here's the console [1] and it's<br>
> corresponding ARA report [2]:<br>
> - A bash script is created [3][4][5] from a jinja template [6]<br>
> - A task executes the bash script [7][8][9]<br>
<br>
</span>From my limited experience, I believe the intent was that the<br>
playbooks should do what a user is expected to do so that it's as<br>
close to reproducing the user interface of TripleO 1:1.<br>
<br>
For example, we document users running commands from a shell prompt.<br>
Therefore, oooq ought to do the same thing as close as possible.<br>
Obviously there will be gaps, just as there is with tripleo.sh, but I<br>
feel that both tools (<a href="http://tripleo.sh/oooq" rel="noreferrer" target="_blank">tripleo.sh/oooq</a>) were trying to be faithful to<br>
our published docs as mush as possible, and I think there's something<br>
to be commended there.<br></blockquote><div><br></div><div>That is exactly right James, CI should be as close to a user driven install as possible IMHO.</div><div><br></div><div>David you are conflating two use cases as far as I can tell. The first use case (a) ansible used in the project/product that is launched by openstack/project commands,  and the second use case (b) ansible as a wrapper around commands that users are expected to execute.</div><div><br></div><div>Using navtive ansible modules as part of the project/product (a) as James is describing is perfectly fine and ansible, ARA and other tools work really well here.</div><div><br></div><div>If the CI reinterprets user level commands (b) directly into ansible module calls you basically loose the 1:1 mapping between CI, documentation and user experience.</div><div>The *most* important function of CI is guarantee that users can follow the documentation and have a defect free experience [docs].  Having to "look at the logs" is a very small </div><div>price to pay to preserve that experience.   I think we'll be able to get the logs from the templated bash into ARA, we just need a little time to get that done.</div><div>IMHO CI is a very different topic than what James is talking about in this thread and hopefully won't interupt this converstation further.</div><div><br></div><div>Thanks</div><div><br></div><div>[docs] <a href="https://docs.openstack.org/tripleo-quickstart/latest/design.html#problem-help-make-the-deployment-steps-easier-to-understand">https://docs.openstack.org/tripleo-quickstart/latest/design.html#problem-help-make-the-deployment-steps-easier-to-understand</a></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Not saying it's right or wong, just that I believe that was the intent.<br>
<br>
An alternative would be custom ansible modules that exposed tasks for<br>
interfacing with our API directly. That would also be valuable, as<br>
that code path is mostly untested now outside of the UI and CLI.<br>
<br>
I think that tripleo-quickstart is a slightly different class of<br>
"thing" from the other current Ansible uses I mentioned, in that it<br>
sits at a layer above everything else. It's meant to automate TripleO<br>
itself vs TripleO automating things. Regardless, we should certainly<br>
consider how it fits into a larger plan.<br>
<span class="gmail-im gmail-HOEnZb"><br>
--<br>
-- James Slagle<br>
--<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>