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

Reply via email to