Open Stack

On Fri, Jul 7, 2017 at 6:20 PM, James Slagle <james.slagle at gmail.com> wrote:

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

That is exactly right James, CI should be as close to a user driven install
as possible IMHO.

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.

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.

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.
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
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.
IMHO CI is a very different topic than what James is talking about in this
thread and hopefully won't interupt this converstation further.

Thanks

[docs]
https://docs.openstack.org/tripleo-quickstart/latest/design.html#problem-help-make-the-deployment-steps-easier-to-understand



> 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
> --
>
> __________________________________________________________________________
> 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/20170709/4cf04100/attachment.html>