On Tue, May 26, 2015 at 1:48 PM, Kapil Thangavelu <kap...@gmail.com> wrote:
> > > On Mon, May 25, 2015 at 9:23 PM, Andrew Wilkins < > andrew.wilk...@canonical.com> wrote: > >> On Tue, May 26, 2015 at 12:18 PM, Richard Harding < >> rick.hard...@canonical.com> wrote: >> >>> On Tue, 26 May 2015, Andrew Wilkins wrote: >>> >>> > On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth <m...@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. > I think going with a static name and adding the additional information in tags is the best way forward. It does mean that you have to click an extra level down, but that's going to be true of everything other than AWS anyway. This way we can reserve certain tags (say, everything starting with "Juju") and periodically reconcile them with Juju's state; and we don't have to worry about overwriting changes made by users to machine names. We'll set the machine name once on creation, then users can update them if desired. > 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. > Agreed. I've got a diff in the works that: - adds a new "resource-tags" config attribute, which providers will use if they can to add user-specified tags to resources created in the environment. We will not manage changes to tags (i.e. if you change resource-tags, that will only affect resources created after the change). - updates both AWS and OpenStack providers to use above. - updates the AWS provider to name machines like in the OpenStack provider: juju-<envname>-machine-<ID>. Threading the other information through to tags will be done separately. Thanks for the feedback. Cheers, Andrew 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-...@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
