Yes, there will if we finish this work, but not within CS mgmt server itself. 
CloudStack api server should not become a load balance or a web server, it 
would be a servlet running in any container like jetty, tomcat or jboss.

Such endpoints can be configured to proxy traffic to multiple api servers, for 
example nginx can be used as a gateway/proxy for host:8080/compute, 
host:8080/lb etc. The api servers would have list of supported apis whitelisted 
in commands.properties.

Regards.

On 04-Dec-2012, at 10:39 AM, Chiradeep Vittal <[email protected]> 
wrote:

> There should be a facility to locate the API under a specific namespace.
> E.g., 
> compute: <server>:8080/compute/
> loadbalancer: <server>:8080/lb/
> volume: <server>:8080/volume/
> 
> 
> On 12/4/12 2:19 AM, "Rohit Yadav" <[email protected]> wrote:
> 
>> Hi everyone,
>> 
>> The API refactoring work for 4.1.0 is going on in api_refactoring branch:
>> https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=short
>> log;h=refs/heads/api_refactoring
>> So far I've broken the user level APIs (build system is broken on the
>> branch), admin level API is wip.
>> 
>> API refactoring plan and fs:
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+refa
>> ctoring
>> 
>> Annotation refactoring:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-518
>> 
>> The aim is to fix api classification, grouping and eventually run as a
>> separate server which would communicate with the data center abstraction
>> engine called cloud-engine over its REST end point.
>> 
>> For those who've attended Alex's talk on architectural rework, this
>> rework would make it possible to have:
>> 
>> - Separate end points for sysadmins and role based users.
>> - Blacklisting of apis etc, creation of different kinds of roles (system
>> admins could run an api-server with a set of apis they wish to offer over
>> an endpoint by adding/removing from commands.properties.in).
>> - Separate out api server from mgmt server, so we move towards our goal
>> to have a cloud core; everything would talk to the scalable cloud-engine.
>> - Grouping as per security roles (org.apache.cloudstack.api.{user, admin})
>> - Multiple api servers, with load balancing etc. which would make it very
>> scalable.
>> - Renaming package names to org.apache.cloudstack.* namespace.
>> - A scalable queue (considering apache compliant Quartz)
>> - Annotations to have automated docs with better notion of linking
>> entities an arg to an API, separate out security layer etc. Right now the
>> API layer and mgmt server (cloud-server, cloud-core) is tightly coupled.
>> - Auto-discovery and caching of APIs for a users using a helper plugin
>> for cloudmonkey cli, right now the API info is precached in cloudmonkey
>> during build time.
>> 
>> Please go through the api fs proposal. Suggestions, proposals, feedback,
>> flames?
>> 
>> Regards.
>> 
>> Ref. rfc email:
>> http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201211.m
>> box/%3CB1DF26ECC0458748AC97CECE2DA98D41012FA1E1CAFD@SJCPMAILBOX01.citrite.
>> net%3E
> 

Reply via email to