On Tue, Oct 14, 2014 at 02:51:15PM +1100, Angus Lees wrote:
> 1. It would be good if the "interesting" code came from python sdist/bdists 
> rather than rpms.

I agree in principal, although starting from packages right now lets
us ignore a whole host of issues.  Possibly we'll hit that change down
the road.

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

All the existing containers [*] are designed to be idempotent, which I
think is not a bad model.  Even if we move initial configuration out
of the service containers I think that is a goal we want to preserve.

I pursued exactly the model you suggest on my own when working on an
ansible-driven workflow for setting things up:


Ansible made it easy to support one-off "batch" containers which, as
you say, aren't exactly supported in Kubernetes.  I like your
(ab?)use of restartPolicy; I think that's worth pursuing.

[*] That work, which includes rabbitmq, mariadb, keystone, and glance.

> 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).

My goal is one-service-per-container, because that generally makes the
question of process supervision and log collection a *host* problem
rather than a *container* problem. It also makes it easier to scale an
individual service, if that becomes necessary.

Lars Kellogg-Stedman <l...@redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

Attachment: pgp5UySJo2RQn.pgp
Description: PGP signature

OpenStack-dev mailing list

Reply via email to