8
To fulfil a popular set of use cases, juju needs a mechanism to control
9
placement of service units; to fulfil the simplest possible version of this
10
story, we consider two possible cases:
12
* User needs to specify minimum hardware requirements * User needs to specify
13
other, context-dependent, hardware attributes
15
This feature allows us to remove the temporary EC2 environment properties
16
`default-image-id` and `default-machine-type`, and makes obsolete the
17
requirement to interact with cobbler out-of-band when placing services and units
18
in an orchestra environment.
24
We introduce "machine constraints", which are used to encode an administrator's
25
hardware requirements. Constraints can be set for environments and services,
26
with lookups for each key falling back from more specific to more general
27
settings, with default values set by juju when otherwise unspecified [0]_.
28
Changes to constraints do not affect any unit that's already been placed on a
31
Constraints will be controlled with a new command, `juju set-constraints`,
32
taking an optional `--service-name` and any number of `key=value` pairs. When
33
the service name is specified, the constraints are set on that service;
34
otherwise they are set on the environment. An empty `value` is treated as "the
35
juju default", allowing users to ignore environment settings at the service
36
level without having to explicitly remember and use the juju default value.
37
There is no way to change the juju default values.
39
We also extend the syntax for `juju deploy`, such that `--constraints` expects a
40
single string of space-separated constraints, understood as above; these
41
constraints will be set on the service before the first unit is deployed. `juju
42
bootstrap` will also understand the `--constraints` argument, and will set them
45
The constraints fall into two categories:
47
* Generic constraints: based on the minimal properties exposed by every
50
* `cpu`: The minimum processing power of the machine, measured in `ECU
51
http://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud#Elastic_compute_units`_,
52
defaulting to 1; any real number >= 0 is valid. * `mem`: The minimum memory
53
for the machine, defaulting to 512MB; any real number >= 0 and suffixed with
54
M, G or T is valid. * `arch`: The machine's processor architecture. Unset
55
by default; valid values are "386", "amd64", and "arm".
57
In the case of `cpu` or `mem`, the value `0` is treated specially, and used to
58
denote that the value doesn't matter at all. EC2 could, for example,
59
special-case `cpu=0` to allow for deploying to a t1.micro without naming it
60
explicitly, but this is not strictly necessary; in the general case, `<key>=0`
61
simply means "do not filter on `<key>`.
63
When interpreting generic constraints, juju is expected to deploy machines
64
with as little wastage as possible: that is to say, given a `mem=3G`
65
constraint and two available machines with 4G and 6G respectively, juju would
66
deploy to the 4G machine.
68
* Provider constraints: based on the additional properties exposed by a given
69
provider, which are not expected to be directly portable to other providers:
71
* For EC2, we expect to expose:
73
* `ec2-zone`: availability zone within the EC2 region. Unset by default (so
74
we get what we're given); valid values depend on the current EC2 region
75
(which is set in environments.yaml, as before). * `ec2-instance-type`:
76
instance type. Unset by default (so we fall back to the juju-level `mem`
77
and `cpu` requirements); valid values are those machine types that EC2 has
78
available in the given region.
80
* For orchestra, we expect to expose:
82
* `orchestra-name`: to allow admins to specify a specific instance by name,
83
if required. Unset by default; the valid values are the set of instance
84
names exposed by cobbler. * `orchestra-classes`: a comma-separated list
85
of cobbler mgmt-classes to which the instance must belong. Empty by
86
default; the valid values are the existing cobbler mgmt-classes, excluding
87
the current values of `available-mgmt-class` and `acquired-mgmt-class`
88
(from the orchestra environment settings).
90
Provider constraints are only effective when used with the appropriate
91
provider, and are silently ignored when specified with a different provider.
93
Note that provider constraints can overlap with generic constraints: in such a
94
situation, the tightest constraints take precendence, such that `mem=8G
95
ec2-instance-type=m1.small` would actually produce an `m1.xlarge` (the
96
smallest instance with at least 8G of RAM); meanwhile, `cpu=1
97
ec2-instance-type=m1.large` would produce an m1.large.
99
Finally, please note that for the local provider, given its nature and its
100
intended use as a development tool, no constraints have any effect whatsoever.
106
Please note that this spec depends on features of juju and orchestra that are
107
not present at the time of writing:
109
* We need orchestra to expose `arch`, `cpu`, and `mem`; as long as the data is
110
available, the orchestra team is free to expose them in whatever way is
111
convenient; but the feature will be severely hobbled if we don't have access
115
Potential Enhancements
116
----------------------
118
The above spec is intended to be small and focused; several enhancements are
119
possible and may be desirable in the future. They include:
121
* Unit-level constraints, specified at `juju add-unit` time, and inheriting
122
naturally from service, environment, and juju.
124
* An additional generic constraint, `storage`: The minimum persistent disk
125
space for the machine, defaulting to 4GB. Valid inputs as for `mem`.
127
* Max constraints: allow the `cpu` and `mem` (and maybe `storage`) constraints
128
to also take the value `max`, meaning "the best available".
130
* Additional provider constraints, such as:
132
* `orchestra-dns-name`: potentially useful for sysadmins who don't primarily
133
think of their systems by `orchestra-name`.
135
* Co-location constraints: for determining machine placement in terms of
136
existing juju components. Possibilities include:
138
* `place-in=<machine-id>`: On a separate container in the machine with juju id
141
* `place-with=<service-name>`: On a separate container in *any* machine with a
142
unit of `service-name` deployed.
144
* `scale-with=<service-name>`: On a separate container in *every* machine
145
running a unit of `service-name`; henceforth every add or remove of a unit
146
of `service-name` will lead to the addition or removal of the corresponding
147
unit of the requested service.
149
Note that it is not advisable to implement co-location constraints without
150
having the ability to deploy units in isolated containers on single machines;
151
and doing this is somewhat tricky, so this is almost certainly impossible to
154
* Provider->generic constraint translation: In the event of our implementing
155
stacks, it may be useful to be able to convert provider-specific constraints
156
into generic ones (where possible) to facilitate creation of
157
provider-independent stacks.
160
.. [0] So: if an environment has specified `ec2-zone=a mem=1G` and a service has
161
specified `mem=2G`, instances of that service in that environment will inherit
162
the `ec2-zone` setting of "a", and the juju default `cpu` of "1", while using
163
the locally-specified `mem` of "2G".
added
removed
docs/source/drafts/placement.rst
