Updated the FS [1] as per the discussion. So the plan is to introduce a generic api to add semantic meta data to the first class objects.
AddResourceDetail - Add details to resource * resourceIds - List of resource ids * resourceType - Example - volume, nic etc. * details - Map of key/value pairs DeleteResourceDetail - Remove detail to resource * resourceIds - List of resource ids * resourceType - Example - volume, nic etc. * details - Map of key/value pairs ListResourceDetails - lists details for a resource * resourceId * resourceType - Example - volume, nic etc. * key * value [1] - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+bett er+control+over+first+class+objects+in+CS On 09/05/13 3:04 PM, "Nitin Mehta" <nitin.me...@citrix.com> wrote: > > >On 03/05/13 7:58 PM, "Chip Childers" <chip.child...@sungard.com> wrote: > >>On Fri, May 03, 2013 at 04:11:21AM +0000, Murali Reddy wrote: >>> 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. >> >>Aren't tags used quite a bit for placement functions? >> >>> 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. >> >>I agree with generalizing it, absolutely. >> >>I think my question is: Are we talking about CS internals only? Or are >>we talking about a truly generalized system that can contain metadata >>for the system, the admins and the users? When I read the functional >>spec, >>it seems confusing as to which of these are being focused on, and if not >>all of them are we getting ourselves into another situation where the >>data authorization model is limited to some specific use case and not >>flexible enough to extend in other ways? >> >>One other FS question: >> >>I see this: "DeployVM/UpdateVM/ - Add flag whether to display the VM to >>end user". What's the definition of "end user" in this scenario? Are >>account admins end users? How about domain admins? Is root admin the >>only one that can see these things? > >Yes, currently as per the use case root admin is the only one allowed to >give him control over the first class objects, but again this can be >customized in future. > >> >>It seems that the implementation is limited in scope yet again to a >>boolean flag. Similar to the question of metadata scope, why would this >>not be designed to be a more robust data authorization model? >> >>It seems like this whole feature should be approached as: >> >>1 - Define a data structure (possibly extending tags) that allows for >>flexible key/value pairs being attached to virtual entities within CS. > >As per suggestions by Murali, I am planning to introduce a generic api to >add semantic meta data to the first class objects. > >> >>2 - Build an ACL model that's actually able to handle different ACL >>requirements for that metadata AS WELL AS for the foundational virtual >>resources. > >Valid point. I am going to currently enable it for root admin but >certainly the design can be extended to handle ACL requirements in future >as well. > >> >>Perhaps I'm over complicating things, but this FS was only first created >>on April 25 and I think that these concerns need to be discussed / >>debated. >> >>-chip >
