On 06-Dec-2012, at 4:29 PM, Mice Xia <mice_...@tcloudcomputing.com> wrote:
> [quote] > 1. Moved and classified all apis (except the anomalies, see other email) into > namespace org.apache.cloudstack.api 2. There are two packages, admin and user > in which the APIs are grouped based on security level. Note; APIs are not > grouped based on roles. > - Because of 1,2,3; there would be two classes of API server. The first one > would be available for users, the user API server which would handle requests > from network outside the datacenter which Alex refers to as "over the wire" > requests. The second one would be available for sysadmins, the mgmt API > server which would handle requests from admins/sysadmins within the > datacenter; > [/quote] > > I haven’t seen the codes, just one question. > If the intention is to deploy API server separately based on the security > level, where are APIs enabled for domain-admin located? In the user package > or in the admin package? The admin package. For domain-admin etc. the sysadmin would run mgmt servers with different sets of apis s/he wants to provide for a domain admin. There won't be any pre configured set of apis, this would allow a system admin to decide exactly what level of access s/he wants to provide to a domainadmin role user. This allows him/her to create multiple end points of mgmt server as well, just like the user api server. Regards. > > Regards > Mice > > -----Original Message----- > From: Rohit Yadav [mailto:rohit.ya...@citrix.com] > Sent: Friday, December 07, 2012 4:07 AM > To: cloudstack-dev@incubator.apache.org > Subject: Arch Rework RFC: API refactoring updates > > Few updates; > > 1. Moved and classified all apis (except the anomalies, see other email) into > namespace org.apache.cloudstack.api 2. There are two packages, admin and user > in which the APIs are grouped based on security level. Note; APIs are not > grouped based on roles. > 3. Further in each org.apache.cloudstack.api.{admin,user}.command pkg, the > APIs are grouped as per api affinity (for ex. all vm related ones in vm pkg). > 4. Few usage related APIs could not be moved from cloud-server to cloud-api, > as they are tightly coupled with classes available in cloud-server. > 5. commands.properties is fixed. > 6. Checked, the api_refactoring merges fine with a minor merge conflicts. The > build on the branch is broken, would be fixed soon. > > I request that if you're adding any new class, please use the namespace > org.apache.cloudstack. > > Road ahead: > - Because of 1,2,3; there would be two classes of API server. The first one > would be available for users, the user API server which would handle requests > from network outside the datacenter which Alex refers to as "over the wire" > requests. The second one would be available for sysadmins, the mgmt API > server which would handle requests from admins/sysadmins within the > datacenter; > > user API server would use only the org.apache.cloudstack.api.user artifact > admin API server would use both org.apache.cloudstack.api.admin and > org.apache.cloudstack.api.user Based on the arch. rework docs, ppts, talks, > Alex's idea was to separate api based on security level would give ultimate > isolation. > > - Separate out cloud-api, and make it run as a separate web app like awsapi. > - Annotations and separation of API based on api affinity would help automate > apidoc generation, api discovery over an api endpoint, so clients (UI or > cloudmonkey etc.) would be able to discover > - The commands.properties syntax is horrible, I want to get rid of the evil > syntax by having an apiname annotation for all API Cmd classes and the API > server would be able to load this info during runtime. In > commands.properties, we should be just able to set policy for user role for > each api, if apiname is not declared it's blacklisted. It becomes tricky with > plugins. I don't know how to get it right the first time, but let's try. > - ACL and security checking at API layer, the requests would be just passed > to (multiple) cloud-engine which won't handle them, as that will only > orchestrate. > - Roles would be decided from commands.properties. Multiple API servers can > be run with different combination of rules in commands.properties. This would > allow separation of policy from mechanism, and multiple roles and end points. > For example, an admin can create http routers for these api server, so: > <url>/hr, <url>/finance, <url>/marketting can be proxies to different user > api servers with different set of whitelisted apis. > > Comments, suggestions, flames? > > Regards.
