Hi @nathan-flowers, welcome to the community!
This is actually YAML syntax for creating named entities. It’s a relatively uncommon feature within YAML and stems from YAML’s XML heritage. To make things slightly more complex, we namespace named entities as well with a key. So there’s some duplication.
The triple public-space line (
public-space: &public-space public-space) creates a named entity
&public-space with the value
public space. That named entity is assigned a key for Juju’s purposes as a “bundle variable”, which explains the
public-space: term at the start of the line.
In more abstract terms, this is what each “public-space” is doing:
<variable-1>: <named-entity-1> <value-1>
[<variable-2>: <named-entity-2> <value-2> ...]
Looking it in full context again, hopefully it’s slightly more obvious what each role is performing:
public-space: &public-space public-space
variables block is Juju-specific. It is a location for describing variables that are used elsewhere in the bundle file.
Sidebar: I’m not entirely sure why this isn’t a list of named entities. Another approach—that may not be valid YAML—would be to use a list of variables:
- &public-space public-space
So anyway, we now have a variable
&public-space. How do we refer to it? With the asterisk prefix.
This is saying, “Dear Juju, please use the
public-space variable’s value as the default binding for the
*.. syntax is cryptic, we apologise! We were just following the spec. And the YAML authors are probably not at fault for that. Their heritage is the C deference operator. Like many things in computing, there’s always someone else to blame.
Anyway, I hope that clarifies the situation