Open Stack

On 7/28/2016 11:29 AM, Clint Byrum wrote:
> 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.
The point is well made, but this consideration is there for all kinds of 
decisions and must be evaluated on a case by case basis. "The difficult 
efforts of being interoperable vs. the cost of maintaining more 
non-interoperable things."

In this case, at least from the discussion that made it into the spec, 
the models didn't seem to be so far off.

> __________________________________________________________________________
> 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