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

[Nate Finch]

+1 to using a UUID to identify a universally unique environment.  Any other
route is just asking for pain and suffering.

Ideally there would also be an easy way to change the name of an
environment so that if you do end up with two environments that have the
same name.... you can just change the name of one of them.  Given that the
name is just user-friendly decoration, it shouldn't bother anyone to change
it, right?

Finally, it means that you probably need to be able to reference an
environment by UUID on the CLI (i.e. juju switch <uuid> or juju deploy -e
<uuid>).  Of course, duplicate names is incompatible with the whole model
of our environments.yaml, but I think we were already working on discarding
that?

On Thu, Nov 12, 2015 at 10:09 PM Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> On Fri, Nov 13, 2015 at 10:38 AM Tim Penhey <tim.penhey at canonical.com>
> wrote:
>
>> 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's a transformation of earlier code that returned API info directly, but
> the current incarnation does not predate cached info. It needs to be there
> in case your cached addresses are out of date.
>
>
>> 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?
>>
>
> There should not be an assumption of a single name per cloud credentials,
> but I think some providers still do make that assumption.
>
>
>> 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.
>>
>
> Yes, we're meant to be using the UUID to distinguish between 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?
>>
>
> The name is meant to be informational only, and the UUID should be used to
> uniquely identify (!) the resources for an environment.
>
> It *should* just work. Specifically in the case of ec2, it won't at the
> moment, because we use security groups to group resources. The security
> group name is based on environment name, and not UUID. We should be able to
> fix for new ec2 environments by using the UUID in the security group name.
> We could also use tags, but for some bizarre reason you specify tags at
> creation time.
>
> Another issue with ec2, and possibly others, is the use of storage to
> record state server instance IDs. I don't think we keep a unique file name
> for each environment. We should be using tags for identify state server
> instances anyway, which is what we're now doing in GCE, Azure, OpenStack,
> possibly others.
>
> FWIW, I've got multi-env working in the new Azure provider. Each
> environment is put in a group called
> "juju-<env-name>-environment-<env-uuid>". Each hosted environment knows the
> UUID of the controller environment so StateServerInstances does the right
> thing, among other reasons.
>
> 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.
>>
>
> I'm pretty confident it works correctly for some of the providers, but as
> above, definitely not true for all. It works correctly for the new Azure
> provider, and possibly the old one (can't remember, would need to dig).
>
> 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.
>>
>
> We should do this. We need something unique, a UUID is fitting.
>
> We should still be able to list state server instances, but it should be
> based on the UUID of the controller environment (the env with state server
> machines), not on the name of any environment.
>
> I think the only reason to check for an existing bootstrap is if the
> bootstrap with the current UUID partially failed, and left turds behind.
> Then you should destroy-env --force to clean up.
>
>  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.
>>
>
> Are there some docs on how migration is going to work? It may have
> implications for work I'm doing with Azure.
>
> Cheers,
> List
>
> 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
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20151113/a579e778/attachment-0001.html>