Storing supported containers in state
Tim Penhey
tim.penhey at canonical.com
Fri Aug 16 02:39:52 UTC 2013
Hi folks,
We have a problem now where we have the ability to create containers,
but not talk to them. Enabling the connectivity and network
addressability is going to take time. The question then is how to
enable Juju to have the ability to create containers in environments
that support it, and fail early in environments where it is not yet
supported.
instance/container.go has
var SupportedContainerTypes []ContainerType
I propose that we move this to be on Provider. The initial idea being
that we can support containers (well LXC for now) on MAAS, but not
anywhere else. Yet.
It would also make sense for us to be able to update this at run time.
For example, for the first cut on EC2 we are looking to support the new
“vpc by default” setting that some accounts have. If they have this,
then we can do addressing relatively easily, but if not, we don’t want
to create containers. Then we may support “existing vpcs” to hook into
environments where there is already a vpc created. And for other
environments, no containers for you.
Similarly for OpenStack. I think we are going to have to interrogate
the environment when we bootstrap to find which APIs are available to us.
So a question becomes:
How do we store this information in state, and have it updatable by the
bootstrap machine when the environment comes up, and have it make sense?
One thing that leaps to mind is the environment config. However this is
already getting a little convoluted and overused in too many different
situations.
Tim
More information about the Juju-dev
mailing list