Also - tags supports many more resources in CloudStack already as compared to the resources you are adding for meta-information. All the more reason to enhance existing APIs?
On Tue, Apr 30, 2013 at 08:21:39PM +0530, Prasanna Santhanam wrote: > 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 -- Prasanna., ------------------------ Powered by BigRock.com
