Open Stack

I think that would be true, if the container api was opinionated. for example, trying to map only a subset of the openstack config options to docker environment variables. This would make the containers specific to what your talking about. Which business rules to support, what hardware, etc.

But the api is a fairly small one. Its mostly a standardized way to pass config files in through docker volumes and get them to land in the right places in the container. You should be able to use any system you want (puppet, chef, jinja, shell scripts) to deal with the business logic and such, to generate the config files, then use the standard api contract to ensure that whatever way you launch the container, (puppet, chef, heat, docker run, kubelet, kubernetes, etc) it behaves the same. The way your generated config file specifies.

Kolla has provided many different variants of each of the containers (centos, ubuntu, etc), showing that api contract is pretty flexible.

A similar thing is going on with kolla-kubernetes.

Thanks,
Kevin

________________________________________
From: Clint Byrum [clint at fewbar.com]
Sent: Wednesday, July 27, 2016 3:12 PM
To: openstack-dev
Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Excerpts from Fox, Kevin M's message of 2016-07-27 21:51:15 +0000:
> Its a standard way of launching a given openstack service container with specified config regardless if its backed with a redhat or ubuntu or source based package set that the Operator can rely on having a standardized interface to. distro packages don't grantee that kind of thing and don't want to.
>
> To me, its an abstraction api kind of like nova is to kvm vs xen. the nova user shouldn't have to care which backend is chosen.
>

You're not wrong, and I do believe there is programming happening to
these interfaces. However the surface area of the API you describe is
_WAY_ too big to justify the work to maintain it as a single entity.

This is really why deployment tooling is so diverse. Hardware, networks,
business rules, operating systems, licensing, regulatory constraints...
all of those are part of a real deployment, and trying to make an API
that allows covering all of those bases, versus just having a bunch of
specific-ish implementations, has so far resulted in acceptance of more
implementations nearly every time.

__________________________________________________________________________
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