See also: How to manage spaces
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
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.
Last updated 4 months ago.