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 [cl...@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-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