Excerpts from Fox, Kevin M's message of 2016-07-27 22:56:56 +0000: > 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. >
I appreciate your optimism, however, Kolla is not "the deployment of OpenStack". It is a set of tools to deploy OpenStack with a set of options available. If it were a small thing to do, people would choose it. But instead, they know, the combinatorial matrix of options is staggering, and one is much better off specializing if they don't fit into the somewhat generic model that any tool like Kolla provides. I'd say focus on _keeping things like Kolla focused_ rather than worrying about making it interoperable. __________________________________________________________________________ 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
