Current placement policies

Placement
---------

Deployer supports flexible per unit placement policies. A unit placement policy allows for
specifying which machine a unit is placed on, including allowing multiple units to be deployed
 to the same machine.

This is expressed in deployer config via the ‘to’ list parameter on a service. Each unit that
needs placement must have its placement specified individually else the default behavior is used,
per the service’s constraints.

There are two forms of placement values that are supported.

Specifying another service, in which case the unit will be placed alongside the matching unit of
that service with matching done by unit count. ie the first unit of x will be placed with the
first unit of y. The second unit of x with the second unit of y.

Machine placement to machine ‘0’. This is the only machine placement supported as its
ambigious across environments. Additionally, containerization of the service unit is
supported for all of these values with the prefix ‘container_type:’, ie. lxc:mysql. Not 
specifying a containerization type results in both service units together in the same root
fs (aka hulk-smash). Containerization can specified on a unit by unit basis.

Nested to: specifications are not supported (ie in the below wordpress can’t # be deployed
to mysql because mysql already specifies a ‘to’ placement)

Example:

envExport:
  services:
    mysql:
      # The only machine id supported is machine 0
      to: 0
    wordpress:
      units: 3
    redis-server:
      units: 3
      to: [lxc:wordpress, wordpress]
    ceph:
      units: 4
      to: [wordpress, wordpress, wordpress, wordpress]
    serenade:
      to: lxc:wordpress=2

In this case the first unit of redis-server is deployed in a container on wordpress/0
The second unit of redis-server is deployed hulk smash onto wordpress/1 The third unit of
redis-server gets a full machine allocated to itself.

For ceph, we deploy hulk smash of the first 3 units, the final unit doesn’t have a 
corresponding unit of wordpress and is deployed (along with a console warning) to a 
separate machine per its default constraints.

The serenade service is overriding the default deploy-with unit by explicitly 
specifying a unit index for the deployment. These are not unit id based but rather
based on extant unit count of the remote service starting with 0.

Proposed placement policies

The placement around mongodb and wordpress reflects new syntax. for mongodb we
relax the restriction of machine placement to machines other than 0, ie a user can
pick any machine. This is a non portable syntax and charm store validation will
flag/deny it. For wordpress constraints are being specified on a per unit basis,
with the default service constraints being used for the third unit.

envExport:
  services:
    mongodb:
      # The only machine id supported is machine 0
      units: 3
      to: [1, 2, 3]
    wordpress:
      units: 3
      to: ["constraints: maas-name=xyz", "constraints: cpu-cores=8"]