Constraint

See also: How to manage machine constraints

In Juju, a constraint is a user-defined hardware specification for a machine that is spawned by Juju.

Constraints can be set at the level of an individual machines, when you create the machine. However, more commonly they’re set for machine groups – e.g., all the machines in a controller, model, or application.

Popular constraints include mem, cores, root-disk, and arch.

Contents:

Complete list of constraints

allocate-public-ip

 Applies to public clouds (GCE, EC2, Azure) and OpenStack. Accepted values are “true” or “false”. Supplying this constraint will determine whether machines are issued an IP address accessible outside of the cloud’s virtual network. Public cloud instances are assigned a public IP by default.

arch

 Architecture. Values include ‘amd64’, ‘arm’, ‘i386’, ‘arm64’, or ‘ppc64’.

container

 Indicates that a machine must be the specified container type. Valid values: [lxd, kvm].

cores

 Effective CPU cores. An integer. Alias: cpu-cores.

cpu-power

 Abstract CPU power. An 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: This is provider-specific, and for the moment is only implemented on MAAS clouds. 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 specificed role/profile for the given cloud should be used. Only valid for clouds which support instance roles. Currently only for AWS with instance-profiles.

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

 Virtualization type, such as ‘kvm’ or ‘virtual-machine’.

zones

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

Example: zones=us-east-1a,us-east-1c

Note: A zone can also be used as a placement directive (--to zone= option).

Cloud differences

Constraints cannot be applied towards a backing cloud in an agnostic way. That is, a particular cloud type may support some constraints but not others. Also, even if two clouds support a constraint, sometimes the constraint value may work with one cloud but not with the other. The list below addresses the situation.

Azure

  • Unsupported: [cpu-power, tags, virt-type]
  • Valid values: arch=[amd64]; instance-type=[defined on the cloud]
  • Conflicting constraints: [instance-type] vs [mem, cores, arch]

Note: root-disk-source is the juju storage pool for the root disk. By specifying a storage pool, the root disk can be configured to use encryption.

CloudSigma

  • Unsupported: [container, instance-type, tags, virt-type, allocate-public-ip, root-disk-source]

EC2

  • Unsupported: [tags, virt-type, allocate-public-ip]
  • Valid values: instance-type=[defined on the cloud]
  • Conflicting constraints: [instance-type] vs [mem, cores, cpu-power]

Note: root-disk-source is the juju storage pool for the root disk. By specifying a storage pool, the root disk can be configured to use encryption.

GCE

  • Unsupported: [tags, virt-type, root-disk-source]
  • Valid values: instance-type=[defined on the cloud]
  • Conflicting constraints: [instance-type] vs [arch, cores, cpu-power, mem]

Kubernetes

  • Unsupported: [cores, virt-type, container, instance-type, spaces, allocate-public-ip, root-disk-source]
  • Non-standard: cpu-power=100 is 1/10 of a core. cpu-power is measured in millicores as defined by Kubernetes.

LXD

  • Unsupported: [cpu-power, tags, virt-type, container, allocate-public-ip]
  • Valid values: arch=[host arch]

Note: root-disk-source is the LXD storage pool for the root disk. The default LXD storage pool is used if root-disk-source is not specified.

MAAS

  • Unsupported: [cpu-power, instance-type, virt-type, allocate-public-ip, root-disk-source]
  • Valid values: arch=[defined on the cloud]

Manual

  • Unsupported: [cpu-power, instance-type, tags, virt-type, allocate-public-ip, root-disk-source]
  • Valid values: arch=[for controller - host arch; for other machine - arch from machine hardware]

Oracle

  • Unsupported: [tags, virt-type, container, root-disk-source]
  • Valid values: arch=[amd64]

OpenStack

  • Unsupported: [tags, cpu-power]
  • Valid values: instance-type=[defined on the cloud]; virt-type=[kvm,lxd]
  • Conflicting constraints: [instance-type] vs [mem, root-disk, cores]

Note: root-disk-source is either “local” or “volume”

vSphere

  • Unsupported: [tags, virt-type, allocate-public-ip]
  • Valid values: arch=[amd64, i386]

Note: root-disk-source is the datastore for the root disk

Clouds and constraints

In the ideal case, you stipulate a constraint when deploying an application and the backing cloud provides a machine with those exact resources. In the majority of cases, however, default constraints may have already been set (at various levels) and the cloud may be unable to supply those exact resources.

When the backing cloud is unable to precisely satisfy a constraint, the resulting system’s resources will exceed the constraint-defined minimum. However, if the cloud cannot satisfy a constraint at all, then an error will be emitted and a machine will not be provisioned.

Constraints and LXD containers

Constraints can be applied to LXD containers either when they’re running directly upon a LXD cloud type or when hosted on a Juju machine (residing on any cloud type). However, with containers, constraints are interpreted as resource maximums as opposed to minimums.

In the absence of constraints, a container will, by default, have access to all of the underlying system’s resources.

LXD constraints also honour instance type names from either AWS, Azure, or GCE (e.g., AWS type t2.micro maps to 1 CPU and 1 GiB of memory). When used in combination with specific CPU/MEM constraints, the latter values will override the corresponding instance type values.

Constraints and Kubernetes

Constraints in Kubernetes models control the resource requests and limits on the pods spawned as a result of deploying an application.

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.

Constraint scopes, defaults, and precedence

Constraints can be applied to various levels or scopes. Defaults can be set on some of them, and in the case of overlapping configurations a precedence is adhered to. Changing a default does not affect the existing machines.

On a per-controller basis, the following constraint scopes exist:

Among the scopes, default constraints can be set for each with the exception of the controller and single machines.

The all-units scope has its default set dynamically. It is the possible constraint used in the initial deployment of an application.

The following precedence is observed (in order of priority):

  1. Machine
  2. Application (and its units)
  3. Model
  4. All models

For instance, if a default constraint (mem) applies to a single model and the same constraint has been stipulated when adding a machine (add-machine) within that model, then the machine’s constraint value will be applied.

The dynamic default for units can be overridden by either setting the application’s default or by adding a machine with a constraint and then applying the new unit to that machine.

Last updated a month ago.

Help improve this document in the forum.