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
- Controlling the scope of regulatory compliance
- Spaces as constraints and bindings
- Support for spaces in Juju providers
- Listing spaces and subnets
- Modifying spaces
- Naming spaces
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.
- See Using constraints for more information about constraints.
- See Setting constraints when adding a machine for use with the
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.
- See Deploying to spaces for examples of using space constraints with the
- Binding endpoints at deployment time is covered in Deploying to network spaces.
Endpoint bindings can be changed after deployment using the
juju bind command.
- For using spaces that bind endpoints with bundles see charmed operator bundles.
Support for spaces by the different Juju providers falls into one of three cases.
This is the case for MAAS, as described below.
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 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.
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.
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.
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 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.
This is the case for the Manual provider, as described below.
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.
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
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 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
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"
Space names are valid values for the controller configuration items:
The name of
default-space, which is by default “alpha”, can also be specified in model-configuration.
Last updated 24 days ago.