On Mon, May 06, 2013 at 11:39:49AM +0000, Murali Reddy wrote: > 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.
Those two are unrelated features - host tags and resource tags. We call too many things tags IMO. The tags I meant were Resource Tags, these you will see in the UI against every resource that takes key,value pair meta-data. Alena developed this feature IIRC. > > > > >> 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. Like createTags, listTags, deleteTags? -- Prasanna., ------------------------ Powered by BigRock.com
