Open Stack

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 <inc007 at 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 <lars at redhat.com> wrote:
> > On Fri, Jul 7, 2017 at 1:50 PM, James Slagle <james.slagle at 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 <lars at redhat.com>
> >
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170710/5d120ae6/attachment.html>