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 (from Juju 2.9)
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-spacejuju-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.
- See Using constraints for more information about constraints.
- See Deploying to spaces for examples of using space constraints with the
deploycommand. - See Setting constraints when adding a machine for use with the
add-machinecommand.
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”.