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 -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
