<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 26, 2015 at 12:18 PM, Richard Harding <span dir="ltr"><<a href="mailto:rick.harding@canonical.com" target="_blank">rick.harding@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 26 May 2015, Andrew Wilkins wrote:<br>
<br>
> On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth <<a href="mailto:mark@ubuntu.com">mark@ubuntu.com</a>> wrote:<br>
><br>
> > On 25/05/15 18:57, Kapil Thangavelu wrote:<br>
> > > That's super awesome, and very helpful for real world usage. A few<br>
> > > suggestions, For users with multiple environments, seeing a bunch<br>
> > > machine-0 in the ui, is rather confusing, i'd suggest prefixing with<br>
> > > the env name. Potentially even more useful is actually naming the<br>
> > > machines not for their pet names, but their cattle names (workload<br>
> > > name), ie. name with the primary unit that caused the machine to<br>
> > > exist, or was the first unit assigned to the machine (minus state<br>
> > > servers).<br>
> ><br>
> > Agreed; for full chargeback we need environment uuid, for social<br>
> > debugging we need some sort of environment name, unit names and charm(s)<br>
> > deployed, including in containers on the machine. For EBS it would be<br>
> > the store name, uuid, and unit identity.<br>
> ><br>
><br>
> Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at doing<br>
> that.<br>
><br>
> A concern I have is that these resources can be reassigned (units added,<br>
> volume<br>
> assigned to different store) so those tags would then be misleading. That's<br>
> the main<br>
> reason why I avoided including information about the workload/store in the<br>
> name. I<br>
> suppose the benefit outweighs, and we could look at updating tags later on.<br>
><br>
> Cheers,<br>
> Andrew<br>
<br>
</div></div>One suggestion is being careful about what tags might already exist on a<br>
machine that a user might have set through their own control UI. If Juju is<br>
tracking tags it sets we should make sure it never messed with ones it did<br>
not set.<br></blockquote><div><br></div><div>When we come to updating existing machines, we won't touch existing tags.<br></div><div>The tags we do add, apart from Name, will be prefixed with Juju so they're</div><div>obviously under the management of Juju. Change them at your own peril.</div><div><br></div><div>This does highlight a problem of how we identify whether or not Juju can update</div><div>the resource's Name tag though. We would either never update it, and live with</div><div>possibly-wrong machine names, or alternatively we'd have a sufficiently unique</div><div>name format that Juju will replace only if it matches.</div><div><br></div><div>Cheers,</div><div>Andrew</div></div></div></div>