Versions Compared

Old Version 8

changes.mady.by.user Min Chen

Saved on

compared with

New Version 9

changes.mady.by.user Min Chen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Problem Statement

Current CloudStack API layer design suffers from various issues:

...

  1. API server will have its own war file to deploy as a separate webapp from cloudstack engine, and can even be deployed to distributed machines to load balance user requests.
  2. API server will have its own cache DB to store entity information that we want to present to end-user. Note that this cache DB is totally decoupled from CloudStack DB (which is shared by multiple management servers). Each api server can has its own cacheDB. This cache DB can have totally different schema design to represent a correct end-user targeted response view. The cache DB schema will closely map to our new cloudstack resource model plus row-level permission information that can acquired from pluggable ACL component.
  3. With independent cache DB on each API server, API server becomes stateless, shutting down one api server will not impact other api server peers.
  4. When API server starts, it will build up the cache DB by fetching fresh data from cloud-engine through REST api, and invoking ACL apis to fill in row-level permission information.
  5. API server will subscribe to our event framework to get notified for each resource update to update its cacheDB.
  6. During cacheDB buildup, we can also build inverted index using Lucene to support google-like search against it.
  7. API server will provide a REST compliant api with the following REST pattern:

Method

URL

Meaning

GET

<rooturl>:<port>/<entity>

List all entitys based on certain criteria

GET

<rooturl>:<port>/<entity>/<identifier>

Get details of a given entity

GET

<rooturl>:<port>/<entity>/<identifier>/<relation1>/<identifier>/<relaltion2>/<identifier>/...

Traversal through entity relationship to get to another related entity.
TODO How to handle criteria in the middle of traversal path, any xpath like syntax can be used here?

POST

<rooturl>:<port>/<entity>

Create an entity

POST

<rooturl>:<port>/<entity>/<identifier>/<opName>

Apply an operation against the given entity

PUT

<rooturl>:<port>/<entity>/<identifier>

Update the given entity

DELETE

<rooturl>:<port>/<entity>/<identifier>

Delete the given entity

Where
<rooturl>: API server web app root url.
<port> : API server web app port.
<entity> : CloudStack entity class, which will be explained below in Object Model section.
<identifier> : Unique identifier for an entity instance, can be uuid, or any other attribute that can uniquely identify a resource.
<opName> : Supported operation name for an entity.TODO How to handle criteria in the middle of traversal path in above #3 URL?

CloudStack Object Model