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
- Controlling the scope of regulatory compliance
Spaces are supported by the following providers:
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 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.
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 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
$ 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 ...
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
$ 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"
Space names are valid values for the controller configuration items:
A space name can also be specified for the value of
default-space in model-configuration.
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.
- See Using constraints for more information about constraints.
- See Deploying to spaces for examples of using space constraints with the
- See Setting constraints when adding a machine for use with the
A binding associates a space with an application endpoint. This restricts traffic for the endpoint to the subnets in the space.
- Binding endpoints at deployment time is covered in Deploying to network spaces.
- For using spaces with bundles see Charm bundles.
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 4 months ago.