Network spaces

Juju models networks using spaces.

A network space is a grouping of one or more subnets visible to the Juju controller. A subnet can only be in one space.

Spaces can be used to segment network traffic for the purposes of:

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

Space support

Spaces are supported by the following providers:

  • MAAS
  • EC2
  • OpenStack
  • Azure
  • Manual

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 the 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 the 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 the AWS VPC that Juju is using, then issuing the command so that the new subnet is available for association with a Juju space.

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.

Manual

Manual provider space support differs somewhat to 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 cloud must be provisioned by Juju before their subnets can be grouped into spaces. When a 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. This example comes from a new AWS model.

$ 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 for subnets.

$ 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 non-MAAS providers, 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 command 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 be renamed.

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

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"

Using spaces

Configuration

Space names are valid values for the controller configuration items:

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

A space name can also be specified for the value of default-space in model-configuration.

Deployment

Spaces can be specified as constraints or bindings to affect application deployments and machine provisioning.

Space constraints affect what subnets a machine is connected to.

A binding associates a space with an application endpoint. This restricts traffic for the endpoint to the subnets in the space.

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

By default, endpoints are bound to the space specified in the default-space model configuration value. The default for this setting is “alpha”.

Last updated a month ago. Help improve this document in the forum.