Upcoming change in 1.24: tags in EC2

[Kapil Thangavelu]

On Mon, May 25, 2015 at 9:23 PM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> 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.
>

one option is to leave the machine id static at allocation (ie what it is
now) and then do workloads dynamically in an additional tag under the juju
namespace. At least with aws, this does degrade console usability as the
user will be looking at a flat list of machines and will have to poke into
details to learn workload on an individual. There's some mitigation in that
the aws console added a nice feature earlier this year for browsing
resource groups via query by tag albeit with additional end user setup.
Compound values (all services on a machine) can be searched via contains.
ie. i could find all machines running units of service xyz in a given env
with juju-env=uuid and juju-units=contains xyz. There's some
usability/discoverability issues with env uuid vs name. aws limits to 10
tags and 255 length utf8 values, most orgs reserve some set of tags for
their own use.

the alternative for dynamic values means storing both the name tag as
desired vs last known state and reconciling with extant value to avoid the
overwrite or via verification of value format convention as you said.

In addition to env tag it would be very good to allow the user to specify
static tags to be associated with all env resources so that juju can
interop with existing org classification and chargeback schemes.

Fwiw Gce has more traditional tag impl of just tag value and instance names
are static. Gce provides for a chargeback mechanism ootb at the gce project
level in addition to account.

cheers,

Kapil


> Cheers,
> Andrew
>
> --
> 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/attachments/20150525/911ee10c/attachment.html>