Sorry folks, I got it wrong and I re-read my emails and Alex is right. Pl. see
his reply.
What's done and plans:
I've separated out api cmds as per admin, user pkg so that developers would
know what security level the apis (Cmd classes) are in. Next, I separated them
based on entity group (like all vpc, vm etc. related apis go together). This
was done only for developers, so they would know where to look for them and
contribute. This would also help us generate better automated apidocs, the
grouping and classification is done manually by hand. Right now I've fixed the
build and apidocs build as well.
The next thing we're going to do is work on @ACL annotation, APIAccessChecker
(that checks roles, etc. which is an adapter, so organizations can throw their
own role based checkers). We also have @validators which can do db, range/size
based (also adapter, so one can diy db validations). What we want to do is for
a group of apis, implement them and show that it works from top to bottom (the
api refactoring work). And if we get it right, we can replicate that for all
the apis, separate out api+service layer as a api web app and make it interact
with cloud-engine.
And yes, all the API servers would have access to both
org.apache.cloudstack.api…{admin, user} artefacts or classes. So, a sysadmin
can decide what kind of apiserver with what set of apis (whitelisted, if not
defined, the api would be blacklisted) they want to offer at which end point
(running on a VM as a service).
Sorry for the confusion.
Regards,
Rohit
PS. /me slaps himself
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?
>
> 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.
