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
  • AWS
  • OpenStack

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.

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.

Where supported by the provider, reload-spaces will fall back to refreshing the known subnets. 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.

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

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

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.