Open Stack

On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard <dms at redhat.com> wrote:
> On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.slagle at gmail.com> wrote:
>> (0) tripleo-quickstart which follows the common and well accepted
>> approach to bundling a set of Ansible playbooks/roles.
>
> I don't want to de-rail the thread but I really want to bring some
> attention to a pattern that tripleo-quickstart has been using across
> it's playbooks and roles.
> I sincerely hope that we can find a better implementation should we
> start developing new things from scratch.

Yes, just to clarify...by "well accepted" I just meant how the git
repo is organized and how you are expected to interface with those
playbooks and roles as opposed to what those playbooks/roles actually
do.

> I'll sound like a broken record for those that have heard me mention
> this before but for those that haven't, here's a concrete example of
> how things are done today:
> (Sorry for the link overload, making sure the relevant information is available)
>
> For an example tripleo-quickstart job, here's the console [1] and it's
> corresponding ARA report [2]:
> - A bash script is created [3][4][5] from a jinja template [6]
> - A task executes the bash script [7][8][9]

>From my limited experience, I believe the intent was that the
playbooks should do what a user is expected to do so that it's as
close to reproducing the user interface of TripleO 1:1.

For example, we document users running commands from a shell prompt.
Therefore, oooq ought to do the same thing as close as possible.
Obviously there will be gaps, just as there is with tripleo.sh, but I
feel that both tools (tripleo.sh/oooq) were trying to be faithful to
our published docs as mush as possible, and I think there's something
to be commended there.

Not saying it's right or wong, just that I believe that was the intent.

An alternative would be custom ansible modules that exposed tasks for
interfacing with our API directly. That would also be valuable, as
that code path is mostly untested now outside of the UI and CLI.

I think that tripleo-quickstart is a slightly different class of
"thing" from the other current Ansible uses I mentioned, in that it
sits at a layer above everything else. It's meant to automate TripleO
itself vs TripleO automating things. Regardless, we should certainly
consider how it fits into a larger plan.

-- 
-- James Slagle
--