cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nitin Mehta <Nitin.Me...@citrix.com>
Subject Re: [MERGE] CS-2163
Date Thu, 09 May 2013 09:55:02 GMT
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.Mehta@citrix.com> wrote:

>
>
>On 03/05/13 7:58 PM, "Chip Childers" <chip.childers@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.Vittal@citrix.com>
>>> wrote:
>>> 
>>> >
>>> >
>>> >On 5/2/13 6:24 AM, "Chip Childers" <chip.childers@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
>


Mime
View raw message