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
- Security
- Controlling the scope of regulatory compliance
Contents:
Spaces as constraints and bindings
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.
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.
Endpoint bindings can be specified during deployment with juju deploy --bind or changed after deployment using the juju bind command.
Support for spaces in Juju providers
Support for spaces by the different Juju providers falls into one of three cases.
Spaces inherited from the substrate
This is the case for MAAS, as described below.
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 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.
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 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.
Subnets inherited from the substrate
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.
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.
LXD
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.
Subnets discovered progressively
This is the case for the Manual provider, as described below.
Manual
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.