Juju constraints

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 Using 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. 100 units is roughly equivalent to "a single 2007-era Xeon" as reflected by 1 Amazon vCPU.

    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. The value is MiB unless an optional suffix of M/G/T/P is used per the mem constraint. Additional storage that may be attached separately does not count towards this value.

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

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. All this is the natural consequence of Juju striving to support widely differing cloud types. 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]

CloudSigma:

  • Unsupported: [instance-type, tags, virt-type]

EC2:

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

GCE:

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

Joyent:

  • Unsupported: [cpu-power, tags, virt-type]
  • Valid values: instance-type=[defined on the cloud]

LXD:

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

MAAS:

  • Unsupported: [cpu-power, instance-type, virt-type]
  • Valid values: arch=[defined on the cloud]

Manual:

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

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]

vSphere:

  • Unsupported: [tags, virt-type]

© 2018 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.