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 Arch Rework RFC: API refactoring updates
Date Thu, 06 Dec 2012 20:06:51 GMT
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