A cautionary tale of names
Eric Snow
eric.snow at canonical.com
Mon Jan 12 21:12:32 UTC 2015
On Sun, Jan 11, 2015 at 8:17 PM, Tim Penhey <tim.penhey at canonical.com> wrote:
> Hi folks,
>
> I hit an issue that surprised me at the time, but became obvious to me
> when I thought about our implementation.
>
> I managed to destroy my production environment by accident, and this is
> always a problem.
>
> What I was trying to do was to bring up my new production environment in
> parallel and then switch the DNS when it was up and working.
>
> I had a working environment, which I then when and renamed the .jenv
> file for. I then bootstrapped the environment again.
>
> This had the side-effect of destroying all the machines that were
> running previously. I'm using the trusty released juju packages, so
> 1.20.14.
>
> This is because the EC2 provider tags the machines with the environment
> name, and not environment UUID. I think we should change this ASAP.
In the case of GCE, I'd rather keep the human-readable instance ID the
same. To make that work, we'd store the env UUID in the instance
metadata and make the implementation of environ.Instances (and
AllInstances) check that, in addition to matching against the env
name. See any problems with that?
I'm not sure the same would work for other resources that rely on the
env name, like firewalls (in the case of GCE).
-eric
More information about the Juju-dev
mailing list