Musings around environments, cloud credentials, and the new Juju Controllers

[Tim Penhey]

Hi William and list,

I have been alternating between thinking this should be a document or an
initial email. In the end I have gone for email even though this is
likely to be longish.

Before I get started on multiple environments in Juju controllers, I'd
like to double check on Juju's expectations around named environments.

Right now, meaning Juju 1.25, Juju environments have names, and UUIDs.
The name is determined by the section in the environments.yaml file of
the user that bootstrapped the Juju environment.

There exists code in every Juju provider that attempts to determine the
state server instances of an environment. This code is used by bootstrap
to make sure you aren't trying to bootstrap an existing environment. I'm
sure the guts of this came from the early juju days when we didn't have
any cached information about the juju environments.

It appears to me, that there is an implicit assumption in the code that
there will exist only one environment of a particular name for a set of
cloud credentials.

Is this correct?

The next question is a more interesting one. Should this be the case?

As environments are created, we generate a UUID for it. This is supposed
to be globally unique, and a way to actually discriminate different
environments.

Consider the situation where Bob and Mary share some cloud credentials.
Both have an environment name defined locally in their environments.yaml
called "ec2" using those same credentials.

If Bob bootstraps "ec2", then Mary bootstraps "ec2", what should happen?

If the answer is "they clash", then this has implications for
environments in Juju controllers as described below.

If the answer is "they should be independent", I'm fairly sure that Juju
does not do this correctly for at least some, perhaps all, of the providers.


Let's for now, assume that the answer is that "they clash" and move on
to multiple environments in juju controllers.


When we bootstrap a Juju controller, as the name will be from Juju 1.26,
we will be creating something that can host many environments. The best
practice will be to have real workload environments separate from the
environment that is hosting the machines that manage the Juju API
servers and database. A key here is to make sure that when we bootstrap
a controller, we leave the user in a best practice scenario.

This means that when we bootstrap a controller, we should create one
environment for managing the controller (the controller environment),
and another empty environment which is the active environment at the end
of bootstrap which the user can immediately start deploying workloads into.

What we are changing is the connection between the name of the
controller, which is how the user interacts with it, and the names of
the environments inside that controller.

Lets take the current proposal for 1.26. When I now bootstrap the
controller that I have called "staging" what I get is a controller that
locally is called "staging", and that controller has two environments in
it, "admin" and "mymodel". One problem is that many providers use the
name of the environment to tag or discriminate.

Now I have the same cloud credentials and a controller called
"production". That controller also wants to create environments called
"admin" and "mymodel". We have now hit the same problem we had before
where we are expecting environment names and cloud credentials to be unique.

So... one of two things needs to happen:

 1) We enforce the ability of every cloud provider to have multiple
environments of the same name owned by the same cloud credentials by
making sure they use the environment UUID to do the real discrimination.
This has the side effect of no longer being able to determine if an
environment of a given name is already bootstrapped, but perhaps this
check is no longer required in the time of having locally cached
endpoints and environment UUID information.

 2) Separate out the Name that is stored in the environment config from
what we use in the model for the "name" of the environment. This would
result in the environment config having names like "production-admin"
and "staging-admin", but when reporting the list of environments to the
user, we really don't want this controller prefix.  Right now we have
one value that is used in two places.

Currently we have no place where we'd store the controller name in the
database model other than the name of the environment itself.

Worth noting that if we choose (2) above, we need to remember that soon
we'll be able to migrate environments from one controller to another, so
the controller prefix that was added to the environment when it was
created won't necessarily always match the name of the controller that
it is currently running in.

Also, we have the desire to be able to rename environments. This is not
currently possible, mostly due to the way that the environment names are
used to discriminate cloud resources, or at least group or tag cloud
resources.

These last two points make me lean more towards (1), but I'd like to
know where people think this may fall down or cause other issues.


Thoughts?

Tim