You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Nitin Mehta <Ni...@citrix.com> on 2013/04/29 06:01:27 UTC
[MERGE] CS-2163
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 FS can be found @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+better+control+over+first+class+objects+in+CS
- I have added the unit tests and marvin tests as well.
- I ran the RAT check as well with no failures.
Thanks,
Nitin
Re: [MERGE] CS-2163
Posted by Min Chen <mi...@citrix.com>.
+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 thread.
-min
On 4/30/13 7:58 AM, "Prasanna Santhanam" <ts...@apache.org> wrote:
>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 +0000, 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
>> > admin
>> The FS of tags [1] states the same objectives:
>>
>> """ Tag is the first class object in the cloudStack """
>>
>> The resource tags is based on AWS tags that carry meta-information for
>> users to do nifty things [2] like managing billing, filtering, external
>> services etc. In the AWS case it is up to the user to determine what
>> she does with a tag.
>>
>> > to have better control over the first class objects in CS. This
>>ability
>> > should be with admin only.
>> Why only admin? Like I pointed, I as a user could decide to fire APIs
>> that do the same failure/backup implementation across my regions if my
>> provider hasn't enabled any service as you describe in your use case.
>>
>> > - Also list* (* == volume, vm etc.) APIs can list the tags for the
>>enduser
>> > and mixing tags with the meta information wouldn't go well as they
>> > are admin only. I don't want to mix the meta information with the
>>resource
>> > response because they are not the attributes of the resource, we
>>should
>> > try to get to this model in future.
>> That's a scope/access control issue of the API. As an admin I could
>> reserve a set of tags for myself to use that my users are forbidden to
>> create. AWS reserves the 'aws' tag.
>>
>> > (Like we don't want to add stats to vm response )
>> > - Lets not use something just because they seem similar, because they
>>both
>> > might evolve in a different way in future.
>>
>> I'm just trying to understand if the existence of tags was overlooked
>> before developing this feature. To me it sounds like one can enhance
>> the existing APIs than have to introduce new ones that can be
>> potentially confusing.
>>
>> [1] https://cwiki.apache.org/confluence/x/PYnlAQ
>> [2] http://s.apache.org/v4
>>
>> --
>> Prasanna.,
>>
>> ------------------------
>> Powered by BigRock.com
>
>--
>Prasanna.,
>
>------------------------
>Powered by BigRock.com
>
Re: [MERGE] CS-2163
Posted by Prasanna Santhanam <ts...@apache.org>.
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 +0000, 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
> > admin
> The FS of tags [1] states the same objectives:
>
> """ Tag is the first class object in the cloudStack """
>
> The resource tags is based on AWS tags that carry meta-information for
> users to do nifty things [2] like managing billing, filtering, external
> services etc. In the AWS case it is up to the user to determine what
> she does with a tag.
>
> > to have better control over the first class objects in CS. This ability
> > should be with admin only.
> Why only admin? Like I pointed, I as a user could decide to fire APIs
> that do the same failure/backup implementation across my regions if my
> provider hasn't enabled any service as you describe in your use case.
>
> > - Also list* (* == volume, vm etc.) APIs can list the tags for the enduser
> > and mixing tags with the meta information wouldn't go well as they
> > are admin only. I don't want to mix the meta information with the resource
> > response because they are not the attributes of the resource, we should
> > try to get to this model in future.
> That's a scope/access control issue of the API. As an admin I could
> reserve a set of tags for myself to use that my users are forbidden to
> create. AWS reserves the 'aws' tag.
>
> > (Like we don't want to add stats to vm response )
> > - Lets not use something just because they seem similar, because they both
> > might evolve in a different way in future.
>
> I'm just trying to understand if the existence of tags was overlooked
> before developing this feature. To me it sounds like one can enhance
> the existing APIs than have to introduce new ones that can be
> potentially confusing.
>
> [1] https://cwiki.apache.org/confluence/x/PYnlAQ
> [2] http://s.apache.org/v4
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: [MERGE] CS-2163
Posted by Prasanna Santhanam <ts...@apache.org>.
On Tue, Apr 30, 2013 at 09:25:40AM +0000, 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
> admin
The FS of tags [1] states the same objectives:
""" Tag is the first class object in the cloudStack """
The resource tags is based on AWS tags that carry meta-information for
users to do nifty things [2] like managing billing, filtering, external
services etc. In the AWS case it is up to the user to determine what
she does with a tag.
> to have better control over the first class objects in CS. This ability
> should be with admin only.
Why only admin? Like I pointed, I as a user could decide to fire APIs
that do the same failure/backup implementation across my regions if my
provider hasn't enabled any service as you describe in your use case.
> - Also list* (* == volume, vm etc.) APIs can list the tags for the enduser
> and mixing tags with the meta information wouldn't go well as they
> are admin only. I don't want to mix the meta information with the resource
> response because they are not the attributes of the resource, we should
> try to get to this model in future.
That's a scope/access control issue of the API. As an admin I could
reserve a set of tags for myself to use that my users are forbidden to
create. AWS reserves the 'aws' tag.
> (Like we don't want to add stats to vm response )
> - Lets not use something just because they seem similar, because they both
> might evolve in a different way in future.
I'm just trying to understand if the existence of tags was overlooked
before developing this feature. To me it sounds like one can enhance
the existing APIs than have to introduce new ones that can be
potentially confusing.
[1] https://cwiki.apache.org/confluence/x/PYnlAQ
[2] http://s.apache.org/v4
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: [MERGE] CS-2163
Posted by Nitin Mehta <Ni...@citrix.com>.
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 ability
should be with admin only.
- Also list* (* == volume, vm etc.) APIs can list the tags for the enduser
and mixing tags with the meta information wouldn't go well as they
are admin only. I don't want to mix the meta information with the resource
response because they are not the attributes of the resource, we should
try to get to this model in future.
(Like we don't want to add stats to vm response )
- Lets not use something just because they seem similar, because they both
might evolve in a different way in future.
Hope you agree. Let me know your thoughts on this.
Thanks,
-Nitin
On 30/04/13 11:06 AM, "Prasanna Santhanam" <ts...@apache.org> wrote:
>On Mon, Apr 29, 2013 at 04:01:27AM +0000, 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.
>> - Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2163
>> - The FS can be found @
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+be
>>tter+control+over+first+class+objects+in+CS
>> - I have added the unit tests and marvin tests as well.
>> - I ran the RAT check as well with no failures.
>
>Why not just use resource tags to convey this meta-information? All it
>would mean for the third-party subscriber would be to get this from
>the event bus as you mentioned.
>
>createTags & resourceType = VM/Disk/Snapshot etc & key=k, value=v?
>
>--
>Prasanna.,
>
>------------------------
>Powered by BigRock.com
Re: [MERGE] CS-2163
Posted by Prasanna Santhanam <ts...@apache.org>.
On Mon, Apr 29, 2013 at 04:01:27AM +0000, 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.
> - Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2163
> - The FS can be found @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+better+control+over+first+class+objects+in+CS
> - I have added the unit tests and marvin tests as well.
> - I ran the RAT check as well with no failures.
Why not just use resource tags to convey this meta-information? All it
would mean for the third-party subscriber would be to get this from
the event bus as you mentioned.
createTags & resourceType = VM/Disk/Snapshot etc & key=k, value=v?
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: [MERGE] CS-2163
Posted by Chip Childers <ch...@sungard.com>.
On Mon, Apr 29, 2013 at 04:01:27AM +0000, 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.
> - Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2163
> - The FS can be found @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+better+control+over+first+class+objects+in+CS
> - I have added the unit tests and marvin tests as well.
> - I ran the RAT check as well with no failures.
>
> Thanks,
> Nitin
+1 from me.
Re: [MERGE] CS-2163
Posted by Nitin Mehta <Ni...@citrix.com>.
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" <mi...@citrix.com> wrote:
>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 answer to #1 is true, then you may need to modify new DB views
>introduced in 4.1 to reflect that flag as well so that you can filter
>resources for end user.
> Thanks
> -min
>
>On 4/28/13 9:01 PM, "Nitin Mehta" <Ni...@citrix.com> 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.
>>- Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2163
>>- The FS can be found @
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+be
>>t
>>ter+control+over+first+class+objects+in+CS
>>- I have added the unit tests and marvin tests as well.
>>- I ran the RAT check as well with no failures.
>>
>>Thanks,
>>Nitin
>
Re: [MERGE] CS-2163
Posted by Min Chen <mi...@citrix.com>.
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 answer to #1 is true, then you may need to modify new DB views
introduced in 4.1 to reflect that flag as well so that you can filter
resources for end user.
Thanks
-min
On 4/28/13 9:01 PM, "Nitin Mehta" <Ni...@citrix.com> 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.
>- Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-2163
>- The FS can be found @
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Ability+to+have+bet
>ter+control+over+first+class+objects+in+CS
>- I have added the unit tests and marvin tests as well.
>- I ran the RAT check as well with no failures.
>
>Thanks,
>Nitin