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