Upcoming change in 1.24: tags in EC2

[Andrew Wilkins]

On Tue, May 26, 2015 at 12:18 PM, Richard Harding <
rick.harding at canonical.com> wrote:

> On Tue, 26 May 2015, Andrew Wilkins wrote:
>
> > On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth <mark at ubuntu.com>
> wrote:
> >
> > > On 25/05/15 18:57, Kapil Thangavelu wrote:
> > > > That's super awesome, and very helpful for real world usage. A few
> > > > suggestions, For users with multiple environments, seeing a bunch
> > > > machine-0 in the ui, is rather confusing, i'd suggest prefixing with
> > > > the env name. Potentially even more useful is actually naming the
> > > > machines not for their pet names, but their cattle names (workload
> > > > name), ie. name with the primary unit that caused the machine to
> > > > exist, or was the first unit assigned to the machine (minus state
> > > > servers).
> > >
> > > Agreed; for full chargeback we need environment uuid, for social
> > > debugging we need some sort of environment name, unit names and
> charm(s)
> > > deployed, including in containers on the machine. For EBS it would be
> > > the store name, uuid, and unit identity.
> > >
> >
> > Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at doing
> > that.
> >
> > A concern I have is that these resources can be reassigned (units added,
> > volume
> > assigned to different store) so those tags would then be misleading.
> That's
> > the main
> > reason why I avoided including information about the workload/store in
> the
> > name. I
> > suppose the benefit outweighs, and we could look at updating tags later
> on.
> >
> > Cheers,
> > Andrew
>
> One suggestion is being careful about what tags might already exist on a
> machine that a user might have set through their own control UI. If Juju is
> tracking tags it sets we should make sure it never messed with ones it did
> not set.
>

When we come to updating existing machines, we won't touch existing tags.
The tags we do add, apart from Name, will be prefixed with Juju so they're
obviously under the management of Juju. Change them at your own peril.

This does highlight a problem of how we identify whether or not Juju can
update
the resource's Name tag though. We would either never update it, and live
with
possibly-wrong machine names, or alternatively we'd have a sufficiently
unique
name format that Juju will replace only if it matches.

Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150526/e6c4a818/attachment.html>