A cautionary tale of names

[Andrew Wilkins]

On Tue, Jan 13, 2015 at 2:15 AM, Kapil Thangavelu <
kapil.thangavelu at canonical.com> wrote:

>
>
> On Mon, Jan 12, 2015 at 10:03 AM, roger peppe <roger.peppe at canonical.com>
> wrote:
>
>> On 12 January 2015 at 15:43, Gustavo Niemeyer <gustavo at niemeyer.net>
>> wrote:
>> > A few quick notes:
>> >
>> > - Having an understandable name in a resource useful
>>
>> It's also good to be clear about what a name actually signifies.
>>
>> Currently (unless things have changed since I last looked)
>> it's entirely possible to start an environment with one name,
>> then send the resulting .jenv file to someone else, who can
>> store it under some other name and still access the environment
>> under the different name.
>>
>> Local aliases/names are nice - no worry about global name space
>> clashes.
>>
>> But I agree that meaningful resource names are useful too.
>>
>> One possibility is that the UUID could incorporate the original
>> environment name (I guess it would technically no longer be
>> a UUID then, but UUID standards are overrated IMHO).
>>
>> Another possibility is to provide some other way to give
>> a name at environment bootstrap time (e.g. a config option)
>> that would be associated with resources created by the environment.
>>
>
> This is effectively what happens albeit implicitly, the name is associated
> at bootstrap, and is used by the state server when provisioning resources.
> ie. in this context (aws) we don't actually use native tag facilities (part
> of why all instances allocated by juju are missing names in the aws
> console), but instead use a security group for implicit tagging. the
> secgroup name corresponds to this initial bootstrap name, other users can
> name the env how they want as further provisioning is done by the state
> servers which will continue to use the initial bootstrap name.. there are
> still niggles here around destroy-environment force if its clientside. the
> secgroup name in aws can be up to 255 chars. it would be good if we used
> tags better for aws resources (instances, drives, etc) as it can help
> usability (aws console) and cost accounting (very common to roll up charges
> by tags for chargeback).
>

FWIW, I have started on a branch that tags instances and volumes in EC2
with the environment UUID. I didn't reply sooner because, as you've noted,
this won't immediately solve the the problem. We would need to change to
using tags instead of the security group association for listing instances,
which is probably a good idea anyway, but requires some additional upgrade
logic.

Cheers,
Andrew


> -k
>
>
> --
> 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/20150113/922ff22c/attachment.html>