incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@citrix.com>
Subject Re: Arch Rework RFC: API refactoring updates
Date Fri, 07 Dec 2012 00:39:44 GMT

On 06-Dec-2012, at 4:29 PM, Mice Xia <mice_xia@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.yadav@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.


Mime
View raw message