This step generates all the passwords, and also configures adatabase and Swift container.

Note we do not actually start any servers here, it is just a placeto generate and store the configuration that we are going to use forour kubernetes jobs that will run on the machines we created instep 1.

Generate the kubernetes config files with the parameters from step 2.

Kubernetes configs have no way to pull in parameters from outsideat present, so we substitute the values directly into the files.This step is deliberately simple at the moment and would be easy tomake it look nicer.

./heat-replace.py mystack kubernetes-in kubernetes

Bring up private docker registry.

This is not strictly required, but I like to use a private dockerregistry when I am doing high-churn development work - and thenames of images in the kubernetes configs currently assume this.

Note that these are really just proxies and the actual registrycontents are stored in the swift container created in step 2.Consequently, any other instance running with the same parametersgiven in kubernetes/docker-registry-repcon.yaml will also be ableto read from and write to this registry. This may be a usefuloption during step 5.

Note also that these configs run the docker registry on port 4999instead of the usual port 5000 to avoid conflicting with keystone.

Populate private docker registry.

Build the docker images and push them to your private dockerregistry. This step essentially downloads a minimal OS and uploadsit back to the private docker registry, so it is good to performthis step on a well-connected machine (eg: on another Rackspace VM,not on your desktop).

If you are using heat-kube-coreos-rax.yaml, then it is fine to dothis step from one of the CoreOS minion machines. Just rsync thedocker sub directory to one of the minions, ssh in as root, andrun the following.

cd docker
./build.sh

Bring up kubernetes jobs.

Order matters here. The services have to be created before anyjobs that need to refer to them.

./kubecfg-create.sh

Remove one-shot jobs that are no longer necessary.

Optional. Kubernetes has poor support for non-persistent jobs atpresent, so these are a slight abuse of kubernetes. They should beharmless if left configured or if they are re-run.