What i'd like to dig more is how Ansible and Heat can live together. And what features do Heat offer that are not covered by Ansible as well? Is there still the need to have Heat as the main engine, or could that be replaced by Ansible totally in the future?
On Sat, Jul 8, 2017 at 12:20 AM, James Slagle <james.sla...@gmail.com> wrote: > On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard <d...@redhat.com> > wrote: > > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.sla...@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 > -- > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Yolanda Robla Mota Principal Software Engineer, RHCE Red Hat <https://www.redhat.com> C/Avellana 213 Urb Portugal yrobl...@redhat.com M: +34605641639 <http://redhatemailsignature-marketing.itos.redhat.com/> <https://red.ht/sig>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
