On 02/05/13 11:20 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote:
> > >On 5/2/13 6:24 AM, "Chip Childers" <chip.child...@sungard.com> wrote: > >>On Thu, May 02, 2013 at 12:40:45PM +0530, Abhinandan Prateek wrote: >>> >>> The tags are name-value pairs basically meant to label resources by a >>>user. >>> The purpose of the current API is to add useful meta information to >>> resources so that they can be meaningfully controlled by external >>>tools. >>> >>> The current implementation of meta info API may look similar to tags >>>with >>> possible edition of a "system" or a "user" qualifier/flag in order to >>> control visibility. >>> >>> But it is not so. Tags by definition are name value pairs where both >>>name >>> and value is a string. If we try to set the meta data information in >>>the >>> tags we are severely restricting the type of meta information that can >>>be >>> contained in the tags. For example if the "data-type" information is >>> required in this meta-data we will end up tweaking the tag system to >>>serve >>> some purpose that it is not meant for. >>> >>> I strongly suggest that we do not try to contain the meta information >>>in a >>> restricted framework provided by tags. >>> >>> -abhi >> >>I don't understand this argument. Most primary data types have string >>representations, right? (ref: JSON) >> >>Are you talking about complex types? Or things like integers, long, >>datetime, etc...? > >I didn't understand it either. >Perhaps the issue is whether this meta-data is available to the end-user >or not? At least, tags are visible to the end-user. Is it the intention >that this 3rd party service do its magic in cahoots with the admin? > > I would like to see this as, meta-data that has semantic meaning to CloudStack vs meta-data that's purely user meta-data that has no meaning to CloudStack and its plug-ins. 'Tags' falls in second category. From e.g. use-case Nitin has put in FS, I do see valid case where a plug-in/feature of CloudStack or external systems like to book keep information of an entity. We already have a pattern of storing such meta data of entities (user_vm_details, cluster_details etc) in the details table which is basically a key-value pair. IMO, I see no harm if we can generalise it.
