Space

See also:

A Juju (network) space is a logical grouping of subnets that can communicate with one another.

A space is used to help segment network traffic for the purpose of:

  • Network performance
  • Security
  • Controlling the scope of regulatory compliance

Contents:

Spaces as constraints and bindings

Spaces can be specified as constraints—to determine what subnets a machine is connected to—or as bindings—to determine the subnets used by application relations.

A binding associates an application endpoint with a space. This restricts traffic for the endpoint to the subnets in the space. By default, endpoints are bound to the space specified in the default-space model configuration value. The name of the default space is “alpha”.

The concepts of space and application end-point binding can be depicted as follows:

Constraints and bindings affect application deployment and machine provisioning as well as the subnets a machine can talk to.

Endpoint bindings can be changed after deployment using the juju bind command.

Support for spaces in Juju providers

Support for spaces by the different Juju providers falls into one of three cases.

Spaces inherited from the provider

This is the case for MAAS, as described below.

MAAS

The concept of spaces is native to MAAS and its API can be used to modify the space/subnet topology. As such, Juju does not permit editing of spaces in a MAAS model. MAAS spaces and subnets are read and loaded into Juju when a new model is created.

If spaces or subnets are changed in MAAS, they can be reloaded into Juju via Juju’s reload-spaces command.

The reload-spaces command does not currently pull in all information. This is being worked upon. See LP #1747998.

For other providers, reload-spaces will fall back to refreshing the known subnets if subnet discovery is supported. One scenario for this usage would be adding a subnet to an AWS VPC that Juju is using, and then issuing the reload-spaces command so that the new subnet is available for association with a Juju space.

Subnets inherited from the provider

This is the case for EC2, OpenStack and Azure, and LXD. Inherited subnets are then grouped into spaces at the discretion of the Juju administrator.

EC2

Machines on Amazon EC2 are provisioned with a single network device. At this time, specifying multiple space constraints and/or bindings will result in selection of a single intersecting space in order to provision the machine.

OpenStack and Azure

The OpenStack and Azure providers support multiple network devices. Supplying multiple space constraints and/or bindings will provision machines with NICs in subnets representing the union of specified spaces.

LXD

LXD automatically detects any subnets belonging to bridge networks that it has access to. It is up to the Juju user to define spaces using these subnets.

Subnets discovered progressively

This is the case for the Manual provider, as described below.

Manual

For the Manual provider, space support differs somewhat from other providers. The reload-spaces command does not discover subnets. Instead, each time a manual machine is provisioned, its discovered network devices are used to update Juju’s known subnet list.

Accordingly, the machines to be used in a manual provider must be provisioned by Juju before their subnets can be grouped into spaces. When provisioning a machine results in discovery of a new subnet, that subnet will reside in the alpha space.

Listing spaces and subnets

Spaces can be viewed with the spaces command, as follows:

juju spaces
Name   Space ID  Subnets
alpha  0         172.31.0.0/20
                 172.31.16.0/20
                 172.31.32.0/20
                 172.31.48.0/20
                 172.31.64.0/20
                 172.31.80.0/20
                 252.0.0.0/12
                 252.16.0.0/12
                 252.32.0.0/12
                 252.48.0.0/12
                 252.64.0.0/12
                 252.80.0.0/12

Similarly, to list subnets, we can use the subnets command:

juju subnets
subnets:
  172.31.0.0/20:
    type: ipv4
    provider-id: subnet-9b4ed4fc
    provider-network-id: vpc-54a7112e
    status: in-use
    space: alpha
    zones:
    * us-east-1c
  172.31.16.0/20:
    type: ipv4
    provider-id: subnet-eca389a6
    provider-network-id: vpc-54a7112e
    status: in-use
    space: alpha
    zones:
    * us-east-1a
...

Modifying spaces

For all providers other than MAAS, all subnets are initially in a default “alpha” space. Juju operators are able to create, rename, or delete spaces, and move subnets between them.

Spaces are created with the add-space command. The following example creates a new space called “db-space” and associates the 172.31.0.0/20 subnet with it:

juju add-space db-space 172.31.0.0/20
added space "db-space" with subnets 172.31.0.0/20

Subnets can be moved between spaces with the move-to-space command:

juju move-to-space db-space 172.31.16.0/20
Subnet 172.31.16.0/20 moved from alpha to db-space

Spaces can also be renamed:

juju rename-space db-space public-space
renamed space "db-space" to "public-space"

You can delete a space using the remove-space command. Deleting a space will cause any subnets in it to move back to the “alpha” space.

juju remove-space public-space
removed space "public-space"

Naming spaces

Space names are valid values for the controller configuration items:

  • juju-ha-space
  • juju-mgmt-space

The name of default-space, which is by default “alpha”, can also be specified in model-configuration.


Last updated 24 days ago.