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 18:41:33 GMT

On 06-Dec-2012, at 5:15 PM, Mice Xia <weiran.xia1@gmail.com> 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 <rohit.yadav@citrix.com> 写道:
>> 
>> 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.
>> 
>> 
> 
> -- 
> Sent from Gmail Mobile

Mime
View raw message