This makes it possible to use layer-ols (and, more interestingly, all
the layers built on top of it) for deployments that are too stateful, or
too reliant on being deployed on metal rather than in a cloud, to be
able to use the usual full switch deployment technique. Several parts
of Launchpad fall into this category.
When the symlink_switch_payload layer configuration flag and the
build_label configuration item are both set, install_payload will
extract the payload to a directory based on the build label and maintain
the code directory as a symlink to the current payload. Note that this
only really makes sense if payloads can be fetched from somewhere else
rather than built into the charm, which means that this option is
currently mainly useful when fetching payloads from Swift.
Some Launchpad deployments (currently the git hosting backend) store the
payload in Swift and configure the charm to be able to fetch it from
there, rather than building the payload into the charm. This is
convenient for various reasons: it reduces the space used on the
controller, and in the git.launchpad.net case it means that it's
possible to deploy a different version of the payload even if
git.launchpad.net itself is broken.
In the cause of converging Launchpad's deployment code with that used by
the rest of OLS, I'd like to add this as an optional facility in
layer-ols.
