Open Stack

That sounds like a good fit for an Ansible plugin to control how
variables or host inventories are designed [1] and is the intended use
case for extending Ansible behavior.

[1]: http://docs.ansible.com/ansible/dev_guide/developing_plugins.html#vars-plugins

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
> tripleo-ui
>
> 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
> deployment).
>
> 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.
>
> Steve
>
>
>
>
>> On Sat, Jul 8, 2017 at 12:20 AM, 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.
>>>
>>> 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
>>
>>
>>
>>
>> --
>>
>> 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
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __________________________________________________________________________
> 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