cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: Arch Rework RFC: API refactoring updates
Date Sat, 08 Dec 2012 00:45:28 GMT
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  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.


> -----Original Message-----
> From: David Nalley []
> Sent: Friday, December 07, 2012 3:51 PM
> To:
> Subject: Re: Arch Rework RFC: API refactoring updates
> On Fri, Dec 7, 2012 at 1:41 PM, Rohit Yadav <> wrote:
> >
> > On 06-Dec-2012, at 5:15 PM, Mice Xia <> 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.

View raw message