Re: A cautionary tale of names
On 12 January 2015 at 03:17, Tim Penhey tim.pen...@canonical.com wrote: This is because the EC2 provider tags the machines with the environment name, and not environment UUID. I think we should change this ASAP. +1. The environment name should be purely client-local IMHO. The main thing that needs to happen to enable this, if it hasn't been done already, is to generate the UUID client side before bootstrapping the environment. It's also worth considering that this might break some existing workflows, assuming it's still possible to perform operations on an environment that has no .jenv file but just an environments.yaml entry. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: A cautionary tale of names
On Sun, Jan 11, 2015 at 8:17 PM, Tim Penhey tim.pen...@canonical.com wrote: This is because the EC2 provider tags the machines with the environment name, and not environment UUID. I think we should change this ASAP. Tim, I'm glad you brought this up. We have followed the lead of the EC2 provider in this regard, so we'll need to fix this. Perhaps other providers need fixing too? On Mon, Jan 12, 2015 at 8:43 AM, Gustavo Niemeyer gust...@niemeyer.net wrote: A few quick notes: - Having an understandable name in a resource useful Agreed. For GCE we may have both the env name and UUID. - Being a tag means it's possible to have a name *and* a UUID What do you mean by this? Do tags incorporate the env UUID somehow? -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: A cautionary tale of names
On 12/01/15 22:23, roger peppe wrote: On 12 January 2015 at 03:17, Tim Penhey tim.pen...@canonical.com wrote: This is because the EC2 provider tags the machines with the environment name, and not environment UUID. I think we should change this ASAP. +1. The environment name should be purely client-local IMHO. The main thing that needs to happen to enable this, if it hasn't been done already, is to generate the UUID client side before bootstrapping the environment. We do this now, and have done for all of 1.21 I think. It's also worth considering that this might break some existing workflows, assuming it's still possible to perform operations on an environment that has no .jenv file but just an environments.yaml entry. Yeah, I understand this, but I feel that changing this behaviour is a small price to pay for better robustness in our running environments. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: A cautionary tale of names
On 13/01/15 04:55, Eric Snow wrote: On Sun, Jan 11, 2015 at 8:17 PM, Tim Penhey tim.pen...@canonical.com wrote: This is because the EC2 provider tags the machines with the environment name, and not environment UUID. I think we should change this ASAP. Tim, I'm glad you brought this up. We have followed the lead of the EC2 provider in this regard, so we'll need to fix this. Perhaps other providers need fixing too? I'm pretty sure it impacts more than just EC2. We (the team) should audit all the providers for this issue. Tim -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: A cautionary tale of names
On Tue, Jan 13, 2015 at 2:15 AM, Kapil Thangavelu kapil.thangav...@canonical.com wrote: On Mon, Jan 12, 2015 at 10:03 AM, roger peppe roger.pe...@canonical.com wrote: On 12 January 2015 at 15:43, Gustavo Niemeyer gust...@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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: A cautionary tale of names
On Mon, Jan 12, 2015 at 10:03 AM, roger peppe roger.pe...@canonical.com wrote: On 12 January 2015 at 15:43, Gustavo Niemeyer gust...@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). -k -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
