« back to all changes in this revision
Viewing changes to constraints.md
- browse files at revision 7
- compare with another revision
- download diff
- download tarball
- view history from revision 7
- Committer: Jorge O. Castro
- Date: 2012-12-05 21:12:36 UTC
- Revision ID: jorge@ubuntu.com-20121205211236-sqnq19z6xn2u0d2t
* Syntax files/clarity
added
removed
constraints.md
10
10
to constraints do not affect any unit that has already been assigned to
11
11
a machine.
12
12
13
Constraints will be controlled with a new command, \`juju
14
set-constraints\`, taking an optional \`--service\` arg, and any number
15
of \`key=value\` pairs. When the service name is specified, the
13
Constraints will be controlled with a new command, `juju
14
set-constraints`, taking an optional `--service` arg, and any number
15
of `key=value` pairs. When the service name is specified, the
16
16
constraints are set on that service; otherwise they are set on the
17
17
environment.
18
18
19
Valid choices for the \`value\` are generally dependent on the
19
Valid choices for the `value` are generally dependent on the
20
20
particular constraint, with two exceptions:
21
21
22
22
> - An empty value always means "use the juju default setting". This
24
24
> without having to explicitly remember and re-set the juju default
25
25
> values. Note that there is no way to change the juju default
26
26
> values.
27
> - A value of \`any\` explicitly unsets a constraint, and will cause
27
> - A value of `any` explicitly unsets a constraint, and will cause
28
28
> it to be chosen completely arbitrarily.
29
29
30
We also extend the syntax for \`juju deploy\`, and \`juju bootstrap\`,
31
such that \`--constraints\` expects a single string of space-separated
30
We also extend the syntax for `juju deploy`, and `juju bootstrap`,
31
such that `--constraints` expects a single string of space-separated
32
32
constraints, understood as above; deployment constraints will be set on
33
33
the service before the first unit is deployed, and bootstrap constraints
34
34
will be set on the environment and used to provision the initial master
35
35
machine.
36
36
37
Please note that there are no changes to the \`juju add-unit\` command;
37
Please note that there are no changes to the `juju add-unit` command;
38
38
juju is explicitly focused on *service* orchestration, and it is
39
39
counterproductive to encourage users to consider individual units. This
40
40
can be worked around by setting new service constraints before adding
41
41
new units, but is not encouraged.
42
42
43
The new \`juju get-constraints\` command is used to see the currently
43
The new `juju get-constraints` command is used to see the currently
44
44
applicable constraints. When called without arguments, it outputs the
45
45
environment constraints as a single yaml-formatted dict; alternatively,
46
46
it can be called with any number of arguments referencing any mix of
53
53
Launch a new deployment running on an m1.medium (running an i386 image),
54
54
and defaulting to that for future services:
55
55
56
$ juju bootstrap --constraints "instance-type=m1.medium arch=i386"
56
juju bootstrap --constraints "instance-type=m1.medium arch=i386"
57
57
58
58
Deploy MySQL on a machine with at least 32GiB of RAM, and at least 8 ECU
59
59
of CPU power (architecture will be inherited from the environment, or
60
60
default to amd64):
61
61
62
$ juju deploy --constraints "cpu=8 mem=32G" mysql
62
juju deploy --constraints "cpu=8 mem=32G" mysql
63
63
64
64
Launch all future machines on t1.micros (unless overridden by service
65
65
constraints):
66
66
67
$ juju set-constraints instance-type=t1.micro
67
juju set-constraints instance-type=t1.micro
68
68
69
69
Launch all future "mysql" machines with at least 8GiB of RAM and 4 ECU:
70
70
71
$ juju set-constraints --service mysql mem=8G cpu=4
71
juju set-constraints --service mysql mem=8G cpu=4
72
72
73
73
Output current environment constraints:
74
74
75
$ juju get-constraints
75
juju get-constraints
76
76
77
77
Output constraints for machine 3, service "mysql", and service unit
78
78
"wordpress/7":
79
79
80
$ juju get-constraints 3 mysql wordpress/7
80
juju get-constraints 3 mysql wordpress/7
81
81
82
82
Provider Constraints
83
83
--------------------
84
84
85
85
The constraints available vary by provider. Internally, every provider
86
will register \`ubuntu-series\` and \`provider-type\` constraints, to
86
will register `ubuntu-series` and `provider-type` constraints, to
87
87
assist with image selection and sanity-checking respectively, but these
88
88
are purely internal constraints and are not settable directly; however,
89
they are visible in the output of \`juju get-constraints\` for clarity's
89
they are visible in the output of `juju get-constraints` for clarity's
90
90
sake.
91
91
92
92
The currently available EC2 constraints are:
93
93
94
> - \`cpu\`: The minimum processing power of the machine, measured in
95
> [ECU](http://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud#Elastic_compute_units),
96
> defaulting to 1; any real number \>= 0 is valid.
97
> - \`mem\`: The minimum memory for the machine, defaulting to 512MB;
98
> any real number \>= 0, and optionally suffixed with M, G or T is
99
> valid.
100
> - \`arch\`: The machine's processor architecture, defaulting to
101
> "amd64". Valid values are "i386", "amd64", and "arm".
102
> - \`instance-type\`: The name of the EC2 instance type for the
103
> machine. This conflicts with \`cpu\` and \`mem\` (but not with
104
> \`arch\`); that is, setting an \`instance-type\` constraint will
105
> clear out any inherited \`cpu\` or \`mem\` values, and vice versa,
106
> and it is an error to attempt to specify the conflicting
107
> constraints in the same command.
108
> - \`ec2-zone\`: availability zone within the EC2 region. Unset by
109
> default (so we get what we're given); valid values are the single
110
> ascii characters that correspond to the final characters of the
111
> zones available to you in the current EC2 region (which is set in
112
> environments.yaml, as usual). That is, if you can see
113
> "us-east-1a", "us-east-1c", and "us-east-1d", the \`ec2-zone\`
114
> constraints should be \`a\`, \`c\`, or \`d\`.
94
- `cpu`: The minimum processing power of the machine, measured in
95
[ECU](http://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud#Elastic_compute_units),
96
defaulting to 1; any real number >= 0 is valid.
97
- `mem`: The minimum memory for the machine, defaulting to 512MB;
98
any real number >= 0, and optionally suffixed with M, G or T is
99
valid.
100
- `arch`: The machine's processor architecture, defaulting to
101
"amd64". Valid values are "i386", "amd64", and "arm".
102
- `instance-type`: The name of the EC2 instance type for the
103
machine. This conflicts with `cpu` and `mem` (but not with
104
`arch`); that is, setting an `instance-type` constraint will
105
clear out any inherited `cpu` or `mem` values, and vice versa,
106
and it is an error to attempt to specify the conflicting
107
constraints in the same command.
108
- `ec2-zone`: availability zone within the EC2 region. Unset by
109
default (so we get what we're given); valid values are the single
110
ascii characters that correspond to the final characters of the
111
zones available to you in the current EC2 region (which is set in
112
environments.yaml, as usual). That is, if you can see
113
"us-east-1a", "us-east-1c", and "us-east-1d", the `ec2-zone`
114
constraints should be `a`, `c`, or `d`.
115
115
116
Of these constraints, only \`ec2-zone\` is specific enough to EC2 to
117
deserve the "ec2-" prefix; we expect to expose \`arch\`, \`cpu\`,
118
\`mem\` and \`instance-type\` constraints on other providers in the
116
Of these constraints, only `ec2-zone` is specific enough to EC2 to
117
deserve the "ec2-" prefix; we expect to expose `arch`, `cpu`,
118
`mem` and `instance-type` constraints on other providers in the
119
119
future, and have therefore not made them explicitly related to EC2.
120
120
121
121
None of these constraints are currently valid on private clouds that
122
happen to expose an EC2 API; the \`default-instance-type\` and
123
\`default-image-id\` provider settings remain as a workaround for this
122
happen to expose an EC2 API; the `default-instance-type` and
123
`default-image-id` provider settings remain as a workaround for this
124
124
situation, until we develop a means of exposing arbitrary clouds'
125
125
instance-type and image-id resources to juju. They are not valid when
126
126
working with Amazon's EC2; this situation is detected by checking for
127
existence of an \`ec2-uri\` provider setting, which implies use of a
127
existence of an `ec2-uri` provider setting, which implies use of a
128
128
private cloud.
129
129
130
130
The currently available MAAS constraint is:
131
131
132
> - \`maas-name\`: The MAAS name to which each unit must be deployed.
133
> This is philosophically problematic, on the basis that teaching
134
> users that it's OK to specify single machines will lead them to
135
> pain when they attempt to scale out large deployments; but it's
136
> justified on the basis that MAAS itself needs to act as a stepping
137
> stone between the "metal" and "cloud" mindsets. \`maas-name\` is
138
> unset by default, and should correspond to a name known by the
139
> MAAS provider.
132
- `maas-name`: The MAAS name to which each unit must be deployed.
133
This is philosophically problematic, on the basis that teaching
134
users that it's OK to specify single machines will lead them to
135
pain when they attempt to scale out large deployments; but it's
136
justified on the basis that MAAS itself needs to act as a stepping
137
stone between the "metal" and "cloud" mindsets. `maas-name` is
138
unset by default, and should correspond to a name known by the
139
MAAS provider.
140
140
141
141
The currently available Orchestra constraint is:
142
142
143
> - \`orchestra-classes\`: A comma-separated list of Cobbler
144
> management classes to which the instance must belong.
145
> \`orchestra-classes\` is empty by default, and each class should
146
> correspond to an existing Cobbler management class, excluding the
147
> current values of \`available-mgmt-class\` and
148
> \`acquired-mgmt-class\` in environments.yaml.
143
- `orchestra-classes`: A comma-separated list of Cobbler
144
management classes to which the instance must belong.
145
`orchestra-classes` is empty by default, and each class should
146
correspond to an existing Cobbler management class, excluding the
147
current values of `available-mgmt-class` and
148
`acquired-mgmt-class` in environments.yaml.
149
149
150
150
The local provider exposes no user-settable constraints.
151
151
160
160
161
161
When bootstrapping an environment, you can set the constraints directly:
162
162
163
$ juju bootstrap --constraints arch=i386
163
juju bootstrap --constraints arch=i386
164
164
165
165
The above command did two things:
166
166
167
> - Set the environment constraints to require machines with an i386
168
> architecture, leaving the other defaults untouched; this is
169
> precisely equivalent to:
170
>
171
> $ juju bootstrap --constraints "arch=i386 cpu=1 mem=512 instance-type=any ec2-zone=any"
172
>
173
> ...or, alternatively, using the automatic default selection:
174
>
175
> $ juju bootstrap --constraints "arch=i386 cpu= mem= instance-type= ec2-zone="
176
>
177
> ...but rather more convenient to type.
178
>
179
> - Started the bootstrap/master machine with the above constraints.
180
>
167
- Set the environment constraints to require machines with an i386
168
architecture, leaving the other defaults untouched; this is
169
precisely equivalent to:
170
171
juju bootstrap --constraints "arch=i386 cpu=1 mem=512 instance-type=any ec2-zone=any"
172
173
...or, alternatively, using the automatic default selection:
174
175
juju bootstrap --constraints "arch=i386 cpu= mem= instance-type= ec2-zone="
176
177
...but rather more convenient to type.
178
179
- Started the bootstrap/master machine with the above constraints.
180
181
181
Because the environment constraints were set, subsequent deployments
182
182
will use the same values:
183
183
184
$ juju deploy mysql
184
juju deploy mysql
185
185
186
186
...but other services can be started with their own constraints:
187
187
188
$ juju deploy wordpress --constraints instance-type=m1.medium
188
juju deploy wordpress --constraints instance-type=m1.medium
189
189
190
Note that the \`arch=i386\` constraint is still inherited from the
190
Note that the `arch=i386` constraint is still inherited from the
191
191
environment, and that this presents a potential problem:
192
192
193
$ juju deploy minecraft --constraints instance-type=cc2.8xlarge
193
juju deploy minecraft --constraints instance-type=cc2.8xlarge
194
194
195
195
The above command will *still* inherit the environment constraints, and
196
196
will lead to an undeployable service (because cc2.8xlarge cannot run on
197
197
i386). Running juju debug-log will expose the problem; you can fix it as
198
198
follows:
199
199
200
$ juju remove-unit minecraft/0
201
$ juju terminate-machine 1
202
$ juju set-constraints --service minecraft arch=amd64 instance-type=cc2.8xlarge
203
$ juju add-unit minecraft
200
juju remove-unit minecraft/0
201
juju terminate-machine 1
202
juju set-constraints --service minecraft arch=amd64 instance-type=cc2.8xlarge
203
juju add-unit minecraft
204
204
205
205
(You need to remove machine 1's assigned unit before you can terminate
206
206
it; you need to explicitly terminate the machine to stop the
211
211
Work on the constraints feature is ongoing, and it will shortly become
212
212
impossible to specify knowably inconsistent constraints; but it is in
213
213
general impossible to detect undeployable constraints with absolute
214
certainty (for example, you could deploy with \`ec2-zone=a\` and be
214
certainty (for example, you could deploy with `ec2-zone=a` and be
215
215
running perfectly happily, but see us-east-1a suddenly go down just as
216
216
you add a unit).
217
217
219
219
-----------------------------
220
220
221
221
As noted, it is impossible to directly set constraints on machines or
222
service units; however, it is still possible to call \`juju
223
get-constraints\` on those entities. In either case, the constraints are
222
service units; however, it is still possible to call `juju
223
get-constraints` on those entities. In either case, the constraints are
224
224
a snapshot of the applicable constraints at entity creation time; so the
225
225
unit constraints are the combined environment/service constraints from
226
226
the time at which the unit was created, and the machine constraints are
245
245
invalidity; at the agent level they are simply ignored.
246
246
247
247
All commands valid before the client upgrade should continue to work as
248
before, as will the EC2 \`default-image-id\` and
249
\`default-instance-type\` environment settings.
248
before, as will the EC2 `default-image-id` and
249
`default-instance-type` environment settings.
250
250
251
[^1]: So: if an environment has specified \`ec2-zone=a mem=1G\` and a
252
service has specified \`mem=2G\`, instances of that service in that
253
environment will inherit the \`ec2-zone\` setting of "a", and the
254
juju default \`cpu\` of "1", while using the service \`mem\` of
251
[^1]: So: if an environment has specified `ec2-zone=a mem=1G` and a
252
service has specified `mem=2G`, instances of that service in that
253
environment will inherit the `ec2-zone` setting of "a", and the
254
juju default `cpu` of "1", while using the service `mem` of
255
255
"2G".
Loggerhead is a web-based interface for Breezy
Version: 2.0.1