Sorry I couldn't make the IRC meeting.  sdake quite rightly suggested I send 
this to the broader list for dissection.

I spent yesterday templatising my k8s configs so I could publish them without 
revealing all my passwords ;)

Please take a look and let me know if any of this is useful.  I think the good 
bits are:

- A simpler method of handling k8s pod routes by just using etcd and two shell 
loops to setup a poor-mans dynamic routing protocol.  For all its simplicity, 
this should scale to hundreds of nodes just fine, and a sharding hierarchy 
would be easy enough to add at that point  (see the networking portions in 

- Dockerfiles for nova + keystone, and a start on glance.  The structure should 
be similar for all the other "control" jobs that don't need to mess with 
hardware directly.  In particular, I'm experimenting with what it would be 
like if environment variables were supported directly in oslo.config files, and 
so far it looks good.

I chose to build these from git master.  I'm not sure if that's a good idea or 
not, but it's what I need to use this for dev work.   A possible improvement 
would be to base these on something like dockerfile/python-runtime.

- k8s config for keystone + nova + a start on glance.  Again, these should be a 
good model for other control jobs.

- I use heat to setup the initial deployment "environment" and generate all 
the passwords, and then stamp the generated values into kubernetes "template" 
files.  This assumes an already active undercloud, but it also removes easily 
isolated tasks like "set up a mysql server and provide its address here" from 
our list of problems to tackle.

I'm trying to run servers independently wherever possible, rather than 
bundling them into the same pod or container.  This gives maximum freedom with 
very little overhead (thanks to docker).  This also means my containers are 
basically dumb software distribution, without a complicated

I don't have anything that configures keystone users or catalog yet - I was 
going to do that in a single pass that just added all the service ports some 
time after keystone was configured but not as part of each individual service.

 - Gus

OpenStack-dev mailing list

Reply via email to