I'll throw a second grenade in. 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.
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. [1] https://github.com/stackhpc/kayobe [2] http://kayobe.readthedocs.io/en/latest/ On 10 July 2017 at 17:44, Michał Jastrzębski <inc...@gmail.com> wrote: > Hey, > > I'll just throw a grenade (pun intended) into your discussion - sorry! > How about kolla-kubernetes? State awareness is done by kubernetes, > it's designed for containers and we already have most of services > ready and we'll be running ansible inside containers on top of k8s, > for all the things that k8s is not natively good at. Sounds like > somewhat you describe just switch heat with k8s. > > Cheers, > Michal > > On 10 July 2017 at 08:37, Lars Kellogg-Stedman <l...@redhat.com> wrote: > > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.sla...@gmail.com> > wrote: > >> > >> There are also some ideas forming around pulling the Ansible playbooks > >> > >> and vars out of Heat so that they can be rerun (or run initially) > >> independently from the Heat SoftwareDeployment delivery mechanism: > > > > > > I think the closer we can come to "the operator runs ansible-playbook to > > configure the overcloud" the better, but not because I think Ansible is > > inherently a great tool: rather, I think the many layers of indirection > in > > our existing model make error reporting and diagnosis much more > complicated > > that it needs to be. Combined with Puppet's "fail as late as possible" > > model, this means that (a) operators waste time waiting for a deployment > > that is ultimately going to fail but hasn't yet, and (b) when it does > fail, > > they need relatively intimate knowledge of our deployment tools to > backtrack > > through logs and find the root cause of the failure. > > > > If we can offer a deployment mode that reduces the number of layers > between > > the operator and the actions being performed on the hosts I think we > would > > win on both fronts: faster failures and reporting errors as close as > > possible to the actual problem will result in less frustration across the > > board. > > > > I do like Steve's suggestion of a split model where Heat is responsible > for > > instantiating OpenStack resources while Ansible is used to perform host > > configuration tasks. Despite all the work done on Ansible's OpenStack > > modules, they feel inflexible and frustrating to work with when compared > to > > Heat's state-aware, dependency ordered deployments. A solution that > allows > > Heat to output configuration that can subsequently be consumed by > Ansible -- > > either running manually or perhaps via Mistral for > API-driven-deployments -- > > seems like an excellent goal. Using Heat as a "front-end" to the process > > means that we get to keep the parameter validation and documentation > that is > > missing in Ansible, while still following the Unix philosophy of giving > you > > enough rope to hang yourself if you really want it. > > > > -- > > Lars Kellogg-Stedman <l...@redhat.com> > > > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.op > enstack.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
