Containers and deployment - thoughts for discussion

[Ian Booth]

Hi folks

We are at the stage with implementing containers where we need to give thought
to charm deployment policies and how they are implemented. I'll present some
ideas for discussion.

Firstly, let's define some terms. A machine is "clean" if it has never had any
charms deployed to it. Because we cannot guarantee that a charm will leave a
machine in a pristine state when it is uninstalled, once a machine becomes
dirty, it will never again be considered clean even if all charms are removed.
Machines can also host containers. A machine is "empty" if it is not hosting any
containers. Because containers can be removed cleanly, a machine can be
considered empty again once all hosted containers are removed.

1. Assignment policy

We currently have AssignNew, AssignUnused, AssignLocal. Juju is hardwired to
AssignNew, and let's ignore AssignLocal for now. We want to scrap AssignUnused
and introduce new assignment policies:

- AssignClean : charms to deployed to clean machines
- AssignCleanEmpty : charms to deployed to clean and empty machines

So the first policy allows charms to be deployed to a pristine machine which may
be hosting containers. The second requires no containers be hosted.

2. Deployment constraints

We need a constraint to control which assignment policy should be used when
deploying a charm. We also need constraints to specify what characteristics a
running machine should have (eg charm foo can only be deployed on a machine
having 4GB of RAM). The current thinking is that we have 2 levels of constraint:
service and environment. Environment constraints provide the default values
unless otherwise specified within any charm metadata or at deployment time. So
the order of precedence is:
1. User specified at deployment time
2. Charm metadata
3. Environment

If no constraint is specified anywhere, then the provider itself can supply a
value during the config validation stage prior to bootstrapping, thus allowing a
provider mandated default to be injected into the environment. eg the local
provider would specify AssignClean

The first step will be to implement an environment assignment policy constraint,
which defaults to AssignNew if not specified anywhere else.

3. Machine instantiation policy

I think this is just a deployment constraint?
When a charm needs to be deployed into a new machine, do we create a new
container on an existing machine instance or do we create a new machine
instance, or do we create a new container on a new machine instance. It can get
complicated because we might want to mark a charm as being able to be deployed
into a container, but a raw machine will do. Or we might prefer a raw machine
but accept a container? We also need to handle the case where a container is
acceptable but there are none available and we can't create a new one on any
running machine because all the memory/resources are being used by existing
containers and so we need to create a new machine instance and then the
container. Complicated. I'd like some advice on the must haves for the next
release and the rest we can prioritise after that.


4. Machine characteristics

We currently have constraints which allow a machine with minimum characteristics
to be instantiated, but we also need to record what actual characteristics a
machine actually has. eg we could ask for a machine to be started with at least
1GB RAM and the machine we get has 4GB. As explained above, we need these
characteristics when deploying charms with constraints. We also need to be able
to aggregate characteristics across containers so we can see if a host machine
can have an additional container added etc. Machine characteristics will be
displayed in juju status.


Let the bikeshedding begin.