<div dir="ltr">I'll throw a second grenade in.<div><br></div><div>Kayobe[1][2] is an OpenStack deployment tool based on kolla-ansible that adds sounds in some ways similar to what you're describing. It roughly follows the TripleO undercloud/overcloud model, with Bifrost used to deploy the overcloud. Kayobe augments kolla-ansible with ansible playbooks for configuration of the undercloud and overcloud hosts - networking, docker storage, LVM. It also provides automation of some common workflows. There's currently a focus on baremetal and scientific computing, but that's only because that's been the focus up to now. Users drive kayobe using a CLI which is mostly a wrapper around ansible-playbook.<div><br></div><div>I'm not suggesting that everyone should discard TripleO and adopt Kayobe - clearly TripleO is a lot more mature. That said, if TripleO wants to move to a more ansible-centric architecture, it might be prudent to see how similar projects work, and if possible, share some code.<br><div><br></div><div>[1] <a href="https://github.com/stackhpc/kayobe" target="_blank">https://github.com/<wbr>stackhpc/kayobe</a></div><div>[2] <a href="http://kayobe.readthedocs.io/en/latest/" target="_blank">http://kayobe.readthedocs.<wbr>io/en/latest/</a><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 July 2017 at 17:44, Michał Jastrzębski <span dir="ltr"><<a href="mailto:inc007@gmail.com" target="_blank">inc007@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,<br>
<br>
I'll just throw a grenade (pun intended) into your discussion - sorry!<br>
How about kolla-kubernetes? State awareness is done by kubernetes,<br>
it's designed for containers and we already have most of services<br>
ready and we'll be running ansible inside containers on top of k8s,<br>
for all the things that k8s is not natively good at. Sounds like<br>
somewhat you describe just switch heat with k8s.<br>
<br>
Cheers,<br>
Michal<br>
<div class="m_-6884849811266705659gmail-HOEnZb"><div class="m_-6884849811266705659gmail-h5"><br>
On 10 July 2017 at 08:37, Lars Kellogg-Stedman <<a href="mailto:lars@redhat.com" target="_blank">lars@redhat.com</a>> wrote:<br>
> On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <<a href="mailto:james.slagle@gmail.com" target="_blank">james.slagle@gmail.com</a>> wrote:<br>
>><br>
>> There are also some ideas forming around pulling the Ansible playbooks<br>
>><br>
>> and vars out of Heat so that they can be rerun (or run initially)<br>
>> independently from the Heat SoftwareDeployment delivery mechanism:<br>
><br>
><br>
> I think the closer we can come to "the operator runs ansible-playbook to<br>
> configure the overcloud" the better, but not because I think Ansible is<br>
> inherently a great tool: rather, I think the many layers of indirection in<br>
> our existing model make error reporting and diagnosis much more complicated<br>
> that it needs to be.  Combined with Puppet's "fail as late as possible"<br>
> model, this means that (a) operators waste time waiting for a deployment<br>
> that is ultimately going to fail but hasn't yet, and (b) when it does fail,<br>
> they need relatively intimate knowledge of our deployment tools to backtrack<br>
> through logs and find the root cause of the failure.<br>
><br>
> If we can offer a deployment mode that reduces the number of layers between<br>
> the operator and the actions being performed on the hosts I think we would<br>
> win on both fronts: faster failures and reporting errors as close as<br>
> possible to the actual problem will result in less frustration across the<br>
> board.<br>
><br>
> I do like Steve's suggestion of a split model where Heat is responsible for<br>
> instantiating OpenStack resources while Ansible is used to perform host<br>
> configuration tasks.  Despite all the work done on Ansible's OpenStack<br>
> modules, they feel inflexible and frustrating to work with when compared to<br>
> Heat's state-aware, dependency ordered deployments.  A solution that allows<br>
> Heat to output configuration that can subsequently be consumed by Ansible --<br>
> either running manually or perhaps via Mistral for API-driven-deployments --<br>
> seems like an excellent goal.  Using Heat as a "front-end" to the process<br>
> means that we get to keep the parameter validation and documentation that is<br>
> missing in Ansible, while still following the Unix philosophy of giving you<br>
> enough rope to hang yourself if you really want it.<br>
><br>
> --<br>
> Lars Kellogg-Stedman <<a href="mailto:lars@redhat.com" target="_blank">lars@redhat.com</a>><br>
><br>
><br>
</div></div><div class="m_-6884849811266705659gmail-HOEnZb"><div class="m_-6884849811266705659gmail-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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
><br>
<br>
______________________________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>