Updated 2018-04-10: The container developed from this work is now automatically built on docker hub.

This is the sixth and probably final post in a series of posts about experimenting with the OpenStack Placement service in containers.

The first got the basics working but was not satisfactory because it only used an already established database and created a rather large container with too many dependencies.

The second mostly discusses issues with placement accidentally importing more code from nova than it would like to, simply because of the structure of the nova code. This has implications for extraction. In fact, all of the container work has done an excellent job of finding speedbumps on that path.

The third continued the work to shrink things and tried it out with some earlier scale testing to confirm all was well.

The fourth gets things working with a standalone database, for experimentation without the rest of OpenStack, and also gets rudimentary Kubernetes support established.

The fifth enables an arbitrary remote database, which can be synchronized to generate tables and perform migrations, and extends the Kubernetes support to use a horizontal pod autoscaler.

Finally, today I merged all those changes (which were happening on a branch) back to the master of the placedock repo and added an extensive README that tries to explain it all in a useful fashion, including how to use the same container in multiple scenarios, controlled by the judicious use of environment variables.

• Running the container with docker to sit beside a running OpenStack installation, such as devstack, talking to an established remote database.
• Using a single sqlite3 database within the container to do placement-only testing (to do things like model nested resource providers and complex queries thereof).
• Running in whatever fashion, but doing the work at startup to make sure that the target database has the proper tables.
• Running in kubernetes with a horizontal pod autoscaler.

Doing this work revealed a great deal about how to make placement scale well, and also informed plenty of future work on extracting placement to an independent project. I think, however, what I would like to close on is how the container evolved from something that had a fair amount of state and dependency on the outside world to something that though flexible in what it can be used for is a static thing that just serves web requests, has no state, starts very quickly, and cannot be changed. If you want to change things you have to kill it, give it new variables, and run again.

This is incredibly good and powerful. Let's have more of that.