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 <sha...@redhat.com> wrote: > On Sun, Jul 9, 2017 at 8:44 AM, Yolanda Robla Mota <yrobl...@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.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 >> >> C/Avellana 213 >> >> Urb Portugal >> >> yrobl...@redhat.com M: +34605641639 >> >> >> __________________________________________________________________________ >> 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 >> > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
