On Fri, Jul 7, 2017 at 5:00 PM, Luke Hinds <lhi...@redhat.com> wrote: > I can't offer much in-depth feedback on the pros and cons of each scenario. > My main point would be to try and simplify as much as we can, rather then > adding yet more tooling to the stack. At the moment ooo is spread across > multi repos and events are handed around multiple tool sets and queues. This > adds to a very steep learning curve for the folk who have to operate these > systems, as there are multiple moving parts to contend with. At the moment > things seem 'duck taped' together, so we should avoid adding more > complexity, and refactor down to a simpler architecture instead. > > With that in mind [1] sounds viable to myself, but with the caveat that > others might have a better view of how much of a fit that is for what we > need.
Agreed, I think the goal ought to be a move towards simplification with Ansible at the core. An ideal scenario for me personally would be a situation where operators could just run Ansible in the typical way that they do today for any other project. Additionally, we'd have a way to execute the same Ansible playbook/roles/vars/whatever via Mistral so that we had a common API for our CLI and UI. Perhaps the default would be to go through the API, and more advanced usage could interface with Ansible directly. Additionally, we must have a way to maintain backwards compatibility with our existing template interfaces, or at least offer some form of migration tooling. Thanks for your feedback. -- -- 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