Difference between revisions of "Cue/api"
(→Requirements) |
(→Requirements) |
||
Line 28: | Line 28: | ||
=== Requirements === | === Requirements === | ||
− | + | Requirements for Cue - Kilo timeframe. | |
* Control plane | * Control plane |
Revision as of 19:10, 26 November 2014
Contents
Cue API Design
Acronyms
Acronym | Definition |
---|---|
SSL | Secure Sockets Layer |
REST | Representational State Transfer |
URI | Uniform Resource Identifier |
UUID | Universally Unique Identifier |
AMQP | Advanced Messaging Queuing Protocol |
Introduction
Messaging systems enable software applications to communicate and scale. Many of today's enterprise systems make use of messaging systems as the glue between the different components or applications. These components depend on messaging to interact with each other to provide end-to-end functionality. This Openstack stackforge project is intended to solve the problem in the provisioning, deployment and management of messaging systems in a seamless automated fashion for applications deployed on the Openstack cloud operating system.
There are several off-the-shelf messaging systems that implement messaging and queuing semantics such as RabbitMQ, Qpid and ActiveMQ. These proven systems have wide acceptance, usage and testing. The goal of this project is not to implement another messaging system for the Openstack platform, but to implement an automated messaging provisioning, deployment and management system. This system will simplify the application development life-cycle to allow the developer to focus on their application instead of the back-end storage services.
Goals
The focus of the project is to provide high-availability, auto-healing and tenant level isolation to the end user. The initial goal for version 1.0 is to use RabbitMQ as the supported messaging system. The overall goal for this effort is to provide a messaging queueing provisioning service for OpenStack built with community support.
Requirements
Requirements for Cue - Kilo timeframe.
- Control plane
- Rabbit Management Console
- Keystone integration
- Command-Line – Create/Delete Cluster
- Horizon Integration - Create/Delete Cluster
- Queue Control Plane Patching
- RabbitMQ Instance Patching
- Cluster Management – Scale up/down
- Devstack integration
- Gate Tests
System Context Diagram
Component | Description |
---|---|
User | Direct customer of MSGaaS. |
Horizon | MSGaaS functionality will be added to Horizon, which will provide a web-based portal for MSGaaS control. |
CLI | Command Line Interface to MSGaaS, provides user access to provisioning and deploying messaging clusters. |
REST_API | Provides user access to provisioning and deploying messaging clusters through REST interface. This is a light-weight interface, provisioning and configuration of clusters/nodes is delegated to the TaskWorker process. |
TaskScheduler | Used to synchronize work tasks between the REST_API and TaskWorker processes. |
TaskWorker | Carries out work associated with all provisioning, configuration and management of RabbitMQ clusters and nodes. Makes use of heat for initial provisioning/deployment. |
DB | Database to store information on clusters and nodes. Example, in cluster creation, when request is initially received through REST_API, this DB is updated accordingly and the work is delegated to TaskWorker. TaskWorker then updates this DB as provisioning and configuration takes place. Subsequent calls to check on status of cluster creation, will return updated information from this DB. |
Heat | Used cloud instance orchestration in deploying RabbitMQ cluster images. |
REST API
General requirement, REST API must respond within 500ms.
List Clusters
GET /v1/clusters
This operation synchronously returns all clusters provisioned within the associated project id.
Request Parameters N/A
Response | Code(s) |
---|---|
Normal | ok (200) |
Error | unauthorized (401) |
Response Parameters
Parameter | Type | Description |
---|---|---|
cluster(list) | string | List of clusters, detailing respective cluster id, name, status, created time stamp and updated time stamp. |
JSON Request
N/A
JSON Response
{
"clusters": [ { "cluster_id": "b51948c9-1ac5-4c28-a580-6f7c500d82f8", "name": "Message Cluster 1", "status": "ACTIVE", "created": "2014-11-11T01:02:03Z", "updated": "2014-11-11T01:02:03Z" }, { "cluster_id": "13c456c9-bbfc-4c31-b26d-3ae5c3cd7a77", "name": "Message Cluster 2", "status": "ACTIVE", "created": "2014-11-12T13:23:54Z", "updated": "2014-11-13T19:55:01Z" } ]
}
Create Cluster
POST /v1/clusters
This operation asynchronously creates a new cluster of Nova instances provisioned with the required message brokers in a central tenant.
Request Parameters
Parameter | Type | Description |
---|---|---|
nic | UUID | Network Identification for a Neutron network where cluster will be created in. |
name | string | Name of cluster. |
volume_size | int | Optional parameter to indicate size of volume for node instance. If volumes are supported, then this parameter will be used. If ephmeral disk are not supported, volume support will be required. |
flavor (list) | string | List of node flavors, which specify VM type in terms of CPU/memory/disk resources (e.g. small, medium, large). Size of list denotes the number of nodes in cluster.
small: 1 GHz dual-core CPU; 512 MB memory; 250 GB disk medium: 2.8 GHz dual-core CPU; 4 GB memory; 1 TB disk large: 3.6 GHz quad-core CPU; 32 GB memory; 5 TB disk |
Response Codes
Response | Code(s) |
---|---|
Normal | 202 (accepted) |
Error | badRequest (400), unauthorized (401), itemNotFound (404) |
Response Parameters
Parameter | Type | Description |
---|---|---|
cluster_id | UUID | ID of cluster to be created. |
name | string | Name of cluster (same as provided name in request parameters). |
status | string | Current status of cluster.
BUILDING: Cluster is in progress of being provisioned. ACTIVE: Cluster is running. ERROR: Provisioning error(s) encountered. DELETED: Cluster has been deleted. |
JSON Request
{
"nic": "d32019d3-bc6e-4319-9c1d-6722fc136a22", "name": "Message Cluster 1", "volume_size": "100", "nodes": [ { "flavor": "large" }, { "flavor": "large" }, { "flavor": "large" } ]
}
JSON Response
{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068", "name": "Message Cluster 1", "status": "BUILDING", "created": "2014-11-11T01:02:03Z", "updated": "2014-11-11T01:02:03Z", "nodes": [ { "node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19", "status": "BUILDING", "flavor": "large", }, {
"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2", "status": "BUILDING", "flavor": "large", }, {
"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8", "status": "BUILDING", "flavor": "large", }
}
Show Cluster
GET /v1/clusters/{cluster_id}
This operation synchronously returns the status and information on the specified cluster within the provided tenant.
Request Parameters
Parameter | Type | Description |
---|---|---|
cluster_id (URI) | UUID | Cluster ID. This value is returned when a new cluster is created. |
Response Codes
Response | Code(s) |
---|---|
Normal | ok (200) |
Error | unauthorized (401), itemNotFound (404) |
Response Parameters
Parameter | Type | Description |
---|---|---|
cluster_id | UUID | ID of requested cluster. |
name | string | Name of cluster. |
status | string | Current status of cluster.
BUILDING: Cluster is in progress of being provisioned. ACTIVE: Cluster is running. ERROR: Provisioning error(s) encountered. DELETED: Cluster has been deleted. |
created | string | Created time stamp in format: yyyy-mm-ddThh:mm:ssZ |
updated | string | Last updated time stamp in format: yyyy-mm-ddThh:mm:ssZ |
nodes(list) | node | List of nodes, which includes node id, instance state, and flavor. |
JSON Request
N/A
JSON Response
{
"cluster_id": "dd745f4a-9333-417e-bb89-9c989c84c068", "name": "Message Cluster 1", "status": "ACTIVE", "created": "2014-11-11T01:02:03Z", "updated": "2014-11-11T01:02:03Z", "nodes": [ { "node_id": "616fb98f-46ca-475e-917e-2563e5a8cd19", "status": "ACTIVE", "flavor": "large", "endpoints": [ { "type": "AMQP", "value": "amqp://10.20.30.40:10000" }, { "type": "console", "value": "http://10.20.30.40:5672" } ], "created": "2014-11-11T01:06:03Z", "updated": "2014-11-11T01:06:03Z" }, {
"node_id": "e90c9d13-c4b8-4a08-992a-dad6109b8ac2", "status": "ACTIVE", "flavor": "large", "endpoints": [ { "type": "AMQP", "value": "amqp://10.20.30.41:10000" }, { "type": "console", "value": "http://10.20.30.41:5672" } ], "created": "2014-11-11T01:08:03Z", "updated": "2014-11-11T01:08:03Z" }, {
"node_id": "372f8f47-6818-4d83-aa42-8744c0e689b8", "status": "ACTIVE", "flavor": "large", "endpoints": [ { "type": "AMQP", "value": "amqp://10.20.30.42:10000" }, { "type": "console", "value": "http://10.20.30.42:5672" } ], "created": "2014-11-11T01:12:03Z", "updated": "2014-11-11T01:12:03Z" } ]
}
Delete Cluster
DELETE /v1/clusters/{cluster_id}''
This operation will asynchronously delete the indicated cluster within the provided tenant.
Request Parameters
Parameter | Type | Description |
---|---|---|
cluster_id (URI) | UUID | Cluster ID. This value is returned when a new cluster is created. |
Response Codes
Response | Code(s) |
---|---|
Normal | accepted (202) |
Error | unauthorized (401), itemNotFound (404) |
Response Parameters
N/A
JSON Request
N/A
JSON Response
N/A
Testing
Cue API testing will verify the expected functionality of the Cue user interface with both positive/negative tests. The overall scope will cover testing from the HTTP REST request to required database interactions and work-flow task submission for RPC workers.
Unit Tests
Unit tests will verify the resulting function calls for each REST-ful URI and action(s). The Python Mock library will be used to replace external system dependencies with placeholder objects.
Function | Tests | Input Data | Expected Result(s) |
---|---|---|---|
List Clusters |
|
|
|
Create Cluster |
|
|
|
Show Cluster |
|
|
|
Delete Cluster |
|
|
|
Functional Tests
The functional tests will verify the HTTP REST URI request lifecycle from controller routing to HTTP response. These tests will make use of Pecan's testing utility; pecan.testing module.
Operation | URI | Tests | Input Data | Expected Data (JSON) | |
---|---|---|---|---|---|
GET | /v1/clusters |
|
|
| |
POST | /v1/clusters |
|
|
|
|
GET | /v1/clusters/{cluster_id} |
|
|
|
|
DELETE | /v1/clusters/{cluster_id} |
|
|
|
Integration Tests
The integration tests will cover API functionality from HTTP request to database access and task submission for RPC workers. The Pecan test utility will be used to route test request URI to appropriate controllers, then database record(s) will be verified for applicable change. Finally the creation of task objections will be verified to ensure valid task flows.