[openstack-dev] [TripleO] Forming our plans around Ansible
David Moreau Simard
dms at redhat.com
Mon Jul 10 15:08:59 UTC 2017
That sounds like a good fit for an Ansible plugin to control how
variables or host inventories are designed  and is the intended use
case for extending Ansible behavior.
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]
On Mon, Jul 10, 2017 at 9:31 AM, Steven Hardy <shardy at redhat.com> wrote:
> On Sun, Jul 9, 2017 at 8:44 AM, Yolanda Robla Mota <yroblamo at redhat.com> wrote:
>> 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?
> The main interface provided by Heat which AFAIK cannot currently be
> replaced by Ansible is the parameters schema, where the template
> parameters are exposed (that include description, type and constraint
> data) in a format that is useful to e.g building the interfaces for
> Ansible has a different approach to role/playbook parameters AFAICT,
> which is more a global namespace with no type validation, no way to
> include description data or tags with variable declarations, and no
> way to specify constraints (other than perhaps hainvg custom modules
> or playbook patterns that perform the validations early in the
> This is kind of similar to how the global namespace for hiera works
> with our puppet model, although that at least has the advantage of
> namespacing foo::something::variable, which again doesn't have a
> direct equivalent in the ansible role model AFAIK (happy to be
> corrected here, I'm not an ansible expert :)
> For these reasons (as mentioned in my reply to James), I think a first
> step of a "split stack" model where heat deploys the nodes/networks
> etc, then outputs data that can be consumed by Ansible is reasonable -
> it leaves the operator interfaces alone for now, and gives us time to
> think about the interface changes that may be needed long term, while
> still giving most of the operator-debug and usability/scalabilty
> benefits that I think folks pushing for Ansible are looking for.
>> On Sat, Jul 8, 2017 at 12:20 AM, James Slagle <james.slagle at gmail.com>
>>> On Fri, Jul 7, 2017 at 5:31 PM, David Moreau Simard <dms at redhat.com>
>>> > 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
>>> > 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  and it's
>>> > corresponding ARA report :
>>> > - A bash script is created  from a jinja template 
>>> > - A task executes the bash script 
>>> 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-request at lists.openstack.org?subject:unsubscribe
>> Yolanda Robla Mota
>> Principal Software Engineer, RHCE
>> Red Hat
>> C/Avellana 213
>> Urb Portugal
>> yroblamo at redhat.com M: +34605641639
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev