On 03/05/13 7:47 PM, "Chip Childers" <chip.child...@sungard.com> wrote:
>On Fri, May 03, 2013 at 04:11:21AM +0000, Murali Reddy wrote: >> >> >> 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? I got confused as well, actually host tags [1] is different from AWS like tags [2]. In this case I can see host tags as meta-data (of hosts) that has semantic meaning (for deployment planner) to CloudStack. Adding key/value pair meta-data to virtual entities within CS is easy way to extend the properties of CS objects. > >> 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? Agree. There could be use cases for both services that are cloud provider managed (admin) vs self-service that need to access/store meta-data. We need to keep design to be flexible. Also current proposal to add new API for each of the action (add/update/remove) and corresponding entity (AddNicDetail, UpdateVolumeDetail etc) looks too redundant. IMO, we can just have create/delete/List/Update meta data API's with resource type and id. We can keep API's both user and admin accessible. > >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? > >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. > >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. > >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 [1] http://s.apache.org/bG2 [2] http://s.apache.org/16q
