I would like to merge the feature which will add the ability in CS so that the
user can have better control over first class objects in CS
- The feature can be found in the branch cs-2163 and has been rebased with
master.
- Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2163
- The
On Mon, Apr 29, 2013 at 04:01:27AM +, Nitin Mehta wrote:
> I would like to merge the feature which will add the ability in CS so that
> the user can have better control over first class objects in CS
>
> - The feature can be found in the branch cs-2163 and has been rebased with
> master.
> -
Nitin,
I have several questions after reading your FS:
1. The API to be modified should also include some list APIs to control
which resources to be displayed to the end user based on your new flag,
right? You didn't mention such APIs in your FS, so I am asking for
clarification.
2. If ans
On Mon, Apr 29, 2013 at 04:01:27AM +, Nitin Mehta wrote:
> I would like to merge the feature which will add the ability in CS so that
> the user can have better control over first class objects in CS
>
> - The feature can be found in the branch cs-2163 and has been rebased with
> master.
> -
Prasanna - Thanks for your question. The reasons for not using createTags
are as follows :-
- tags functionality is for grouping resources than adding meta
information and is allowed to all users. What I am proposing is for the
admin
to have better control over the first class objects in CS. This
On Tue, Apr 30, 2013 at 09:25:40AM +, Nitin Mehta wrote:
> Prasanna - Thanks for your question. The reasons for not using createTags
> are as follows :-
>
> - tags functionality is for grouping resources than adding meta
> information and is allowed to all users. What I am proposing is for the
Also - tags supports many more resources in CloudStack already as
compared to the resources you are adding for meta-information. All the
more reason to enhance existing APIs?
On Tue, Apr 30, 2013 at 08:21:39PM +0530, Prasanna Santhanam wrote:
> On Tue, Apr 30, 2013 at 09:25:40AM +, Nitin Mehta
+1 to Prasanna's argument. Tags provide more flexibility and extensibility
than adding column to existing db schema. What happens if later on we want
to add finer control to these resources not specific to end user? Adding
another column?
Also, I haven't seen your answer to my questions in this t
Min - Thanks for your questions. I have updated the FS with the list Apis.
I also updated the FS with the DB view changes.
This was already done while submitting the merge request.Thanks for
pointing this out.
Thanks,
-Nitin
On 29/04/13 11:07 PM, "Min Chen" wrote:
>Nitin,
>
> I have sever
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
possib
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.
>
>
On 5/2/13 6:24 AM, "Chip Childers" 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 ca
On Thu, May 02, 2013 at 10:50:25AM -0700, Chiradeep Vittal wrote:
>
>
> On 5/2/13 6:24 AM, "Chip Childers" 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
On 02/05/13 11:20 PM, "Chiradeep Vittal"
wrote:
>
>
>On 5/2/13 6:24 AM, "Chip Childers" 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
On Fri, May 03, 2013 at 04:11:21AM +, Murali Reddy wrote:
> On 02/05/13 11:20 PM, "Chiradeep Vittal"
> wrote:
>
> >
> >
> >On 5/2/13 6:24 AM, "Chip Childers" wrote:
> >
> >>On Thu, May 02, 2013 at 12:40:45PM +0530, Abhinandan Prateek wrote:
> >>>
> >>> The tags are name-value pairs basicall
On 03/05/13 7:47 PM, "Chip Childers" wrote:
>On Fri, May 03, 2013 at 04:11:21AM +, 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. '
On Mon, May 06, 2013 at 11:39:49AM +, Murali Reddy wrote:
> On 03/05/13 7:47 PM, "Chip Childers" wrote:
>
> >On Fri, May 03, 2013 at 04:11:21AM +, Murali Reddy wrote:
> >>
> >>
> >> I would like to see this as, meta-data that has semantic meaning to
> >> CloudStack vs meta-data that's pu
On Mon, May 06, 2013 at 11:39:49AM +, Murali Reddy wrote:
> On 03/05/13 7:47 PM, "Chip Childers" wrote:
>
> >On Fri, May 03, 2013 at 04:11:21AM +, Murali Reddy wrote:
> >>
> >>
> >> I would like to see this as, meta-data that has semantic meaning to
> >> CloudStack vs meta-data that's pu
On 06/05/13 5:18 PM, "Prasanna Santhanam" wrote:
>>
>> 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
On 06/05/13 5:20 PM, "Prasanna Santhanam" wrote:
>On Mon, May 06, 2013 at 11:39:49AM +, Murali Reddy wrote:
>> On 03/05/13 7:47 PM, "Chip Childers" wrote:
>>
>> >On Fri, May 03, 2013 at 04:11:21AM +, Murali Reddy wrote:
>> >>
>> >>
>> >> I would like to see this as, meta-data that has
On 03/05/13 7:58 PM, "Chip Childers" wrote:
>On Fri, May 03, 2013 at 04:11:21AM +, Murali Reddy wrote:
>> On 02/05/13 11:20 PM, "Chiradeep Vittal"
>> wrote:
>>
>> >
>> >
>> >On 5/2/13 6:24 AM, "Chip Childers" wrote:
>> >
>> >>On Thu, May 02, 2013 at 12:40:45PM +0530, Abhinandan Prateek w
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
On Thu, May 09, 2013 at 09:55:02AM +, Nitin Mehta wrote:
> 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
> *
Chip - The change is not significant but a subset of the work already
done. Going this path makes the model of adding semantic metadata more
flexible and can be extended to have a more flexible ACL in future as well.
I am already done with the changes and have added the unit and integration
tests a
This has been merged into master now.
On 12/05/13 2:40 PM, "Nitin Mehta" wrote:
>Chip - The change is not significant but a subset of the work already
>done. Going this path makes the model of adding semantic metadata more
>flexible and can be extended to have a more flexible ACL in future as
>w
25 matches
Mail list logo
