Constraint

doc
1

In Juju, a constraint is a key-value pair that represents a specification that can be passed to certain juju commands /command flags to customise the hardware resources (bare metal machines, virtual machines, system containers, Kubernetes containers) spawned by Juju.

If the resource is a bare metal machine or a virtual machine, a constraint represents a minimum, whereas if the resource is a system container or a Kubernetes container it represents a maximum.

For machine (non-Kubernetes) clouds, constraints can be set directly on individual machines. However, more commonly they are set at the level of the controller, model, or application. If you set constraints at multiple levels at once – that is, with overlap – the constraint applied at the more specific level takes precedence.

The rest of this document describes all the existing constraints.

Some of these keys – their availability and their meaning – vary from one cloud to another. Below this is indicated with a generic note. For specifics see List of supported clouds > <cloud name>.

Contents:

List of constraints

allocate-public-ip

 Supplying this constraint will determine whether machines are issued an IP address accessible outside of the cloud’s virtual network.

Valid values: true, false.

Note: Applies to public clouds (GCE, EC2, Azure) and OpenStack. Public cloud instances are assigned a public IP by default.

arch

 The architecture.

Valid values: amd64, arm64, ppc64el, s390x, riscv64.

container

 Indicates that a machine must be the specified container type.

Valid values: lxd, kvm.

cores

 Number of effective CPU cores.

Type: integer.

Alias: cpu-cores.

cpu-power

 Abstract CPU power.

Type: integer, where 100 units is roughly equivalent to “a single 2007-era Xeon” as reflected by 1 Amazon vCPU. In a Kubernetes context a unit of “milli” is implied.

Note: Not supported by all providers. Use cores for portability.

image-id

 (Starting with 3.2) The image ID. If not nil, indicates that a machine must use the specified image.

Note: Not supported by all providers. Value is provider-specific. Also, when applied during juju deploy, must be used in conjunction with the --base flag of the command – the image-id will specify the image to be used for the provisioned machines and the --base will specify the charm revision to be deployed on those machines.

instance-role

 Indicates that the specified role/profile for the given cloud should be used.

Note: Only valid for clouds which support instance roles. Currently only for AWS with instance profiles and (starting with Juju 3.6) for Azure with managed identities.

instance-type

 Cloud-specific instance-type name. Values vary by provider, and individual deployment in some cases.

Note: When compatibility between clouds is desired, use corresponding values for cores, mem, and root-disk instead.

mem

 Memory (MiB). An optional suffix of M/G/T/P indicates the value is mega-/giga-/tera-/peta- bytes.

root-disk

 Disk space on the root drive (MiB). An optional suffix of M/G/T/P is used as per the mem constraint. Additional storage that may be attached separately does not count towards this value.

root-disk-source

 Name of the storage pool or location the root disk is from.

Note: root-disk-source has different behaviour with each provider.

spaces

 A comma-delimited list of Juju network space names that a unit or machine needs access to. Space names can be positive, listing an attribute of the space, or negative (prefixed with “^”), listing something the space does not have.

Example: spaces=storage,db,^logging,^public (meaning, select machines connected to the storage and db spaces, but NOT to logging or public spaces).

Note: EC2 and MAAS are the only providers that currently support the spaces constraint.

tags

 Comma-delimited tags assigned to the machine. Tags can be positive, denoting an attribute of the machine, or negative (prefixed with ^), to denote something that the machine does not have.

Example: tags=virtual,^dualnic

Note: Currently only supported by the MAAS provider.

virt-type

 Virtualisation type.

Valid values: kvm, virtual-machine.

zones

 A list of availability zones. Multiple values present a range of zones that a machine must be created within.

Valid values: Depending on the cloud provider.

Example for the aws cloud: zones=us-east-1a,us-east-1c

Note: A zone can also be used as a placement directive (--to zone= <name of zone>).
1 Like
2
3

Hi, just a nitpick, the constraint “cpu-cores” is an alias of “cores”, using “cpu-cores” works but gives this warning:

Warning: constraint "cpu-cores" is deprecated in favor of "cores".

Best,

1 Like
4

Fixed it now, thanks!

5

There is a typo in the constraint allocate-public-id, it should be allocate-public-ip.

1 Like
6

Fixed, thanks!

7
8

This part

Memory and CPU constraints on sidecar charms currently only represent requests used by Kubernetes for scheduling, and don’t set limits and requests separately on each container. This deficiency is tracked under bug LP1919976.

Is misleading, it seems to say that only requests are set on the pod, which is not what the ticket says (it says that limit = request and we can’t set different values) I also validated that limit is also set when a memory constraint is set:

    Limits:
      memory:  4Gi
    Requests:
      memory:   4Gi

I think this should be rephrased

9

It seems currently you cannot set the default constraints for a new model, or, constraints for “all models” or the controller as a whole.

The documentation currently implies that is possible, mentioning constraint scopes exist for “all models”. But I cannot find any way to set this.

The following feature request (very recent, co-incidentally) implies this is also not possible:

Please update the document to either correctly note you cannot do this, or, note how to do it.

The option I had thought did this, “juju bootstrap --constraints” actually doesn’t, it only sets the constraints for the “controller” model which really we normally don’t use to do anything else in my experience.

I cannot see any other detail in juju help commands|grep constraint, juju model-defaults|grep constraint or juju set-model-constraints --help that implies there is a way to do this. Additionally a new model does not appear to inherit the constraints from the controller model.

10

Hi there. I noticed that for MAAS the tag constraint seems to be missing. See e.g. this discussion on how it can be used How to use MAAS constraints?

11

Hello! The virt-type options can be updated to “container” or “virtual-machine”.

ERROR cannot add application "alias": invalid constraint value: virt-type=kvm
valid values are: [ container virtual-machine]
12

Since in many cases a user will want to leverage multiple constraints, it would be good for the docs to clarify that the correct syntax is to separate key/value pairs with a space (and quote the whole string). In other words:

  • --constraints="key1=value1,value2 key2=value3 ← correct
  • --constraints key1=value1 --constraints key2=value2 ← incorrect, only key2=value2 will be considered