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 On Tue, Apr 30, 2013 at 09:25:40AM +0000, Nitin Mehta wrote: > Prasanna - Thanks for your question. The reasons for not using createTags > are as follows :- > > - tags functionality is for grouping resources than adding meta > information and is allowed to all users. What I am proposing is for the > admin The FS of tags [1] states the same objectives: """ Tag is the first class object in the cloudStack """ The resource tags is based on AWS tags that carry meta-information for users to do nifty things [2] like managing billing, filtering, external services etc. In the AWS case it is up to the user to determine what she does with a tag. > to have better control over the first class objects in CS. This ability > should be with admin only. Why only admin? Like I pointed, I as a user could decide to fire APIs that do the same failure/backup implementation across my regions if my provider hasn't enabled any service as you describe in your use case. > - Also list* (* == volume, vm etc.) APIs can list the tags for the enduser > and mixing tags with the meta information wouldn't go well as they > are admin only. I don't want to mix the meta information with the resource > response because they are not the attributes of the resource, we should > try to get to this model in future. That's a scope/access control issue of the API. As an admin I could reserve a set of tags for myself to use that my users are forbidden to create. AWS reserves the 'aws' tag. > (Like we don't want to add stats to vm response ) > - Lets not use something just because they seem similar, because they both > might evolve in a different way in future. I'm just trying to understand if the existence of tags was overlooked before developing this feature. To me it sounds like one can enhance the existing APIs than have to introduce new ones that can be potentially confusing. [1] https://cwiki.apache.org/confluence/x/PYnlAQ [2] http://s.apache.org/v4 -- Prasanna., ------------------------ Powered by BigRock.com
