cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prasanna Santhanam <...@apache.org>
Subject Re: [MERGE] CS-2163
Date Mon, 06 May 2013 11:48:03 GMT
On Mon, May 06, 2013 at 11:39:49AM +0000, Murali Reddy wrote:
> On 03/05/13 7:47 PM, "Chip Childers" <chip.childers@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


Mime
View raw message