Constraints reference

doc
,
1

NOTE: DEPRECATED. SEE INSTEAD Constraint .

See also:

Constraints are minimum requirements for machines that are created on behalf of Juju. They are passed as options to commands that either provision a new machine directly or are set as defaults for new machines at the controller, model, or application level.

This reference page lists all the constraints that can be used with Juju.

For in-depth coverage and examples see the About constraints page in the user guide.

Generic constraints

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

  • cores Effective CPU cores. An integer.

  • 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.

  • 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.

  • 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.

  • 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.

  • virt-type Virtualization type, such as ‘kvm’.

  • 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 option).

  • 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.

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, cpu-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, cpu-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, cpu-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, cpu-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

2

Hello.
I only wanted to point out an inconsitency in the documentation concerning the root-disk-source constraint. The note in the parameter descriptions says:

Note: Supported by the vSphere and OpenStack providers

while below in the Cloud differences section for OpenStack it says:

Unsupported: [tags, cpu-power, root-disk-source]

thank you

2 Likes
3
4