<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 7, 2017 at 10:17 PM, James Slagle <span dir="ltr"><<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jul 7, 2017 at 5:00 PM, Luke Hinds <<a href="mailto:lhinds@redhat.com">lhinds@redhat.com</a>> wrote:<br>
> I can't offer much in-depth feedback on the pros and cons of each scenario.<br>
> My main point would be to try and simplify as much as we can, rather then<br>
> adding yet more tooling to the stack. At the moment ooo is spread across<br>
> multi repos and events are handed around multiple tool sets and queues. This<br>
> adds to a very steep learning curve for the folk who have to operate these<br>
> systems, as there are multiple moving parts to contend with. At the moment<br>
> things seem 'duck taped' together, so we should avoid adding more<br>
> complexity, and refactor down to a simpler architecture instead.<br>
><br>
> With that in mind [1] sounds viable to myself, but with the caveat that<br>
> others might have a better view of how much of a fit that is for what we<br>
> need.<br>
<br>
</span>Agreed, I think the goal ought to be a move towards simplification<br>
with Ansible at the core.<br>
<br>
An ideal scenario for me personally would be a situation where<br>
operators could just run Ansible in the typical way that they do today<br>
for any other project. Additionally, we'd have a way to execute the<br>
same Ansible playbook/roles/vars/whatever via Mistral so that we had a<br>
common API for our CLI and UI.<br>
<br>
Perhaps the default would be to go through the API, and more advanced<br>
usage could interface with Ansible directly.<br></blockquote><div><br></div><div>I like the sound of this approach, as we then have a API for driving complex deployment and upgrades, but if an operator needs to troubleshoot or customise, they can do so with pure play ansible. Yet mistral is there to drive the main complexity of a full openstack deployment. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally, we must have a way to maintain backwards compatibility<br>
with our existing template interfaces, or at least offer some form of<br>
migration tooling.<br>
<br>
Thanks for your feedback.<br>
<span class="im HOEnZb"><br>
--<br>
-- James Slagle<br>
--<br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="font-size:12.8px">Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat</span><br style="font-size:12.8px"><span style="font-size:12.8px">e: </span><a href="mailto:lhinds@redhat.com" style="color:rgb(17,85,204);font-size:12.8px" target="_blank">lhinds@redhat.com</a><span style="font-size:12.8px"> | irc: lhinds @freenode | m: </span>+44 77 45 63 98 84<span style="font-size:12.8px"> | t: </span>+44 12 52 36 2483<br style="font-size:12.8px"></div></div>
</div></div>