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:da...@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.ya...@citrix.com> wrote: > > > > On 06-Dec-2012, at 5:15 PM, Mice Xia <weiran.x...@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.
