incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fang Wang <fang.w...@citrix.com>
Subject RE: Arch Rework RFC: API refactoring updates
Date Sat, 08 Dec 2012 02:43:25 GMT
Alex, thanks for the clarification. 

User and admin commands separation is aimed for developers and document generation, for the

current refactoring  plan. 

There is some benefits to physically separate user and admin API servers in the future, is
it something we may consider
It? Because it can grant different levels of service and resource allocation to handle admin
API commands.
Otherwise the end users and admin users still have the same end point access. 

> 3. role based access is actually going to be delegated to cloud-access to check. There
is no a separate command class per role problem so there's no maintenance problem.
For the access-check, I think the API server will do it, as well as the role based ACL check.
 

Thanks,
-Fang


-----Original Message-----
From: Alex Huang [mailto:Alex.Huang@citrix.com] 
Sent: Friday, December 07, 2012 4:45 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: Arch Rework RFC: API refactoring updates

I think there's misunderstanding here.

1. Separation for user and admin commands is done for developers.  Because current CloudStack
mixes the options available only to admins with the options available to end users, we see
problems with people accessing things that they shouldn't be able to access.  This is not
intended as a role-based command access.  This is to force developers to think about what
they are putting in.

2. CloudStack actually allows commands to be packaged as a set.  That's done in a text file
in commands.properties.  So domain admin commands mixed in with end user commands in a single
end point is not a problem.  It is not determined by the packaging of the java files.

3. role based access is actually going to be delegated to cloud-access to check. There is
no a separate command class per role problem so there's no maintenance problem.

--Alex

> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Friday, December 07, 2012 3:51 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Arch Rework RFC: API refactoring updates
> 
> On Fri, Dec 7, 2012 at 1:41 PM, Rohit Yadav <rohit.yadav@citrix.com> wrote:
> >
> > On 06-Dec-2012, at 5:15 PM, Mice Xia <weiran.xia1@gmail.com> wrote:
> >
> >> rohit,
> >>
> >> i asked this question because requests from domain admins are 
> >> usually
> from
> >> outside of datacenter for a public cloud.
> >>
> >> so artifact built from user package can be directly deployed as a 
> >> user api server and serve user requests. but to serve domain admin 
> >> request,
> sysadmin
> >> has to prepare another api server with another set of apis, which 
> >> is a sub set of admin package, is this correct?
> >
> > Thanks for the question Mice, I've shared one solution. Will get to 
> > you on
> this one.
> >
> 
> Are we sure this move is a good idea in general?
> I mean from a public cloud perspective I can understand the logic. In 
> a private cloud though, things tend to be far less boolean.
> This also seems incredibly inflexible for long term maintenance - 
> unless I am completely missing something.

Mime
View raw message