incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mice Xia <weiran.x...@gmail.com>
Subject Re: Arch Rework RFC: API refactoring updates
Date Fri, 07 Dec 2012 01:15:14 GMT
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?

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message