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
