+1 to Prasanna's argument. Tags provide more flexibility and extensibility than adding column to existing db schema. What happens if later on we want to add finer control to these resources not specific to end user? Adding another column? Also, I haven't seen your answer to my questions in this thread.
-min On 4/30/13 7:58 AM, "Prasanna Santhanam" <t...@apache.org> wrote: >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 >
