Open Stack

Angus Lees wrote:
> I've been reading a bunch of the existing Dockerfiles, and I have two humble 
> requests:
> 
> 
> 1. It would be good if the "interesting" code came from python sdist/bdists 
> rather than rpms.
> 
> This will make it possible to rebuild the containers using code from a private 
> branch or even unsubmitted code, without having to go through a redhat/rpm 
> release process first.
> 
> I care much less about where the python dependencies come from. Pulling them 
> from rpms rather than pip/pypi seems like a very good idea, given the relative 
> difficulty of caching pypi content and we also pull in the required C, etc 
> libraries for free.
> 
> 
> With this in place, I think I could drop my own containers and switch to 
> reusing kolla's for building virtual testing environments.  This would make me 
> happy.
> 
> 
> 2. I think we should separate out "run the server" from "do once-off setup".
> 
> Currently the containers run a start.sh that typically sets up the database, 
> runs the servers, creates keystone users and sets up the keystone catalog.  In 
> something like k8s, the container will almost certainly be run multiple times 
> in parallel and restarted numerous times, so all those other steps go against 
> the service-oriented k8s ideal and are at-best wasted.
> 
> I suggest making the container contain the deployed code and offer a few thin 
> scripts/commands for entrypoints.  The main replicationController/pod _just_ 
> starts the server, and then we have separate pods (or perhaps even non-k8s 
> container invocations) that do initial database setup/migrate, and post-
> install keystone setup.
> 
> I'm open to whether we want to make these as lightweight/independent as 
> possible (every daemon in an individual container), or limit it to one per 
> project (eg: run nova-api, nova-conductor, nova-scheduler, etc all in one 
> container).   I think the differences are run-time scalability and resource-
> attribution vs upfront coding effort and are not hugely significant either way.
> 
> Post-install catalog setup we can combine into one cross-service setup like 
> tripleO does[1].  Although k8s doesn't have explicit support for batch tasks 
> currently, I'm doing the pre-install setup in restartPolicy: onFailure pods 
> currently and it seems to work quite well[2].
> 
> (I'm saying "post install catalog setup", but really keystone catalog can 
> happen at any point pre/post aiui.)
> 
> [1] https://github.com/openstack/tripleo-incubator/blob/master/scripts/setup-endpoints
> [2] https://github.com/anguslees/kube-openstack/blob/master/kubernetes-in/nova-db-sync-pod.yaml
> 
> -- 
>  - Gus

One thing I've learned is to not perform software updates within a container.
A number of the containers I've seen do software updates on startup but I've
seen this break dependencies in containers a few times making them unusable.
This detracts from the ability to have a completely controlled environment
within a container with proven software versions that play nicely together.

    Ian