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. Regards. > > sent from phone, sorry for typos. > > mice > > 在 2012年12月7日星期五，Rohit Yadav <[email protected]> 写道： >> >> On 06-Dec-2012, at 4:29 PM, Mice Xia <[email protected]> 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:[email protected]] >>> Sent: Friday, December 07, 2012 4:07 AM >>> To: [email protected] >>> 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. >> >> > > -- > Sent from Gmail Mobile
