Cloud Application Management for Platforms

Copyright Notice

License

The Cloud Application Management for Platforms (CAMP) Specification is being provided by the copyright holders under the following license. By using and/or copying this work, you agree that you have read, understood and will comply with the following terms and conditions:

Permission to copy, display and distribute the Cloud Application Management for Platforms (CAMP) Specification and/or portions thereof, without modification, in any medium without fee or royalty is hereby granted, provided that you include the following on ALL copies of the Cloud Application Management for Platforms (CAMP) Specification, or portions thereof, that you make:

1. A link or URL to the Cloud Application Management for Platforms (CAMP) Specification at this location:

http://cloudspecs.org/CAMP/CAMP_v1-0.pdf

2. The full text of the copyright notice as shown in the Cloud Application Management for Platforms (CAMP) Specification.

CloudBees, Cloudsoft, Huawei, Oracle, Rackspace, Red Hat, Software AG (collectively, the "Authors") agree to grant you a royalty-free license, under reasonable, non-discriminatory terms and conditions to patents that they deem necessary to implement the Cloud Application Management for Platforms (CAMP) Specification.

THE Cloud Application Management for Platforms (CAMP) SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, REGARDING THIS SPECIFICATION AND THE IMPLEMENTATION OF ITS CONTENTS, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OR TITLE.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THE Cloud Application Management for Platforms (CAMP) SPECIFICATION.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or publicity pertaining to the Cloud Application Management for Platforms (CAMP) Specification or its contents without specific, written prior permission. Title to copyright in the Cloud Application Management for Platforms (CAMP) Specification will at all times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

Cloud Application Management for Platforms

Contents

Abstract 1

1. Introduction 1

1.1. Overview 1

1.2. Purpose 1

1.3. Example 2

1.4. Non-Goals 3

1.5. PaaS Roles 3

1.6. Document Conventions 4

2. Architecture 4

2.1. Management Model 4

2.1.1. PaaS Resource Model 6

2.1.2. Resource Relationships 7

2.1.3. Management Model Diagrams 109

2.2. Importing a Platform Deployment Package 1412

2.3. Exporting a Platform Deployment Package 1513

3. Application Lifecycle 1513

3.1. Uploaded 1614

3.2. Deployed 1614

3.3. Instantiated 1614

3.4. Suspended 1614

4. Platform Deployment Package 1715

4.1. PDP Package Structure 1715

4.2. Deployment Plan 1715

4.2.1. Deployment Plan Schema 1715

5. Resources 1816

5.1. Common Types 1816

5.1.1. Boolean 1816

5.1.2. String 1816

5.1.3. URI 1816

5.1.4. Timestamp 1816

5.1.5. Link 1816

5.1.6. ResourceState 1816

5.2. Attribute Constraints 1917

5.2.1. Cardinality 1917

5.2.2. Mutability 1917

5.2.3. Writeable 1917

5.3. Common Resource Attributes 1917

5.3.1. uri 1917

5.3.2. name 1917

5.3.3. description 1917

5.3.4. created 2018

5.3.5. tags 2018

5.4. Error Response Message 2018

5.5. Extensibility to the resource model 2220

5.6. Platform 2220

5.6.1. specificationVersion 2321

5.6.2. implementationVersion 2321

5.6.3. assemblyTemplates 2321

5.6.4. assemblies 2321

5.6.5. platformComponentTemplates 2321

5.6.6. platformComponentCapabilities 2321

5.6.7. platformComponents 2422

5.6.8. resourceState 2422

5.7. AssemblyTemplate 2422

5.7.1. definition 2523

5.7.2. basedOn 2523

5.7.3. applicationComponentTemplates 2523

5.7.4. platformComponentTemplates 2523

5.7.5. dependencies 2523

5.8. ApplicationComponentTemplate 2624

5.8.1. definition 2624

5.8.2. basedOn 2724

5.9. ApplicationComponentRequirement 2824

5.9.1. definition 2825

5.10. ApplicationComponentCapability 2825

5.10.1. definition 2925

5.11. PlatformComponentTemplate 2926

5.11.1. definition 2926

5.12. PlatformComponentRequirement 2926

5.12.1. definition 3027

5.13. PlatformComponentCapability 3027

5.13.1. definition 3027

5.14. Assembly 3027

5.14.1. definition 3128

5.14.2. applicationComponents 3128

5.14.3. platformComponents 3128

5.14.4. assemblyTemplate 3228

5.14.5. resourceState 3229

5.15. ApplicationComponent 3229

5.15.1. definition 3229

5.15.2. applicationComponents 3330

5.15.3. platformComponents 3330

5.15.4. resourceState 3330

5.16. PlatformComponent 3330

5.16.1. definition 3431

5.16.2. externalManagementResource 3431

5.16.3. resourceState 3431

6. Protocol 3532

6.1. Transport Protocol 3532

6.2. URI Space 3532

6.3. Media Types 3532

6.4. Request Headers 3633

6.5. Request Parameters 3633

6.6. Response Headers 3633

6.7. HTTP Status Codes 3633

6.8. Concurrent API versions 3633

6.9. Registering a PDP 3734

6.10. Instantiating an Application 3734

6.11. Suspending and Resuming an Application 3835

6.12. Deleting an Application Instance and a Deployed Application 3835

7. Normative References 3835

8. Non-Normative References 3936

Annex A. Glossary 4037

Annex B. Use Cases (Non-Normative) 4138

B.1. Building the Application 4138

B.1.1. Build Application and Package 4138

B.1.2. Build Application in the Cloud and Optionally Package 4239

B.2. Deploying and Managing the Application 4340

B.2.1. Import Platform Deployment Package 4441

B.2.2. Upload Application 4441

B.2.3. Run/Stop/Suspend/Snapshot 4542

B.2.4. Patch an Application Component Template 4542

B.2.5. Patch a Created, Deployed or Running Application 4542

Annex C. Example Database Platform Component (Non-Normative) 4542

C.1. Model 4542

C.2. DatabaseCapability 4542

C.2.1. definition 4643

C.2.2. clusterTypes 4643

C.2.3. maxNumberNodes 4744

C.2.4. maxCores 4744

C.2.5. maxMemSize 4744

C.2.6. maxDiskSize 4744

C.2.7. backupAvailable 4744

C.2.8. synchronousCopyAvailable 4744

C.2.9. partitionAvailable 4845

C.2.10. compressionAvailable 4845

C.2.11. retentionAvailable 4845

C.2.12. tunings 4845

C.2.13. cachingAvailable 4845

C.3. DatabaseRequirement 4845

C.3.1. definition 4946

C.3.2. clusterTypes 4946

C.3.3. numberNodesRange 5047

C.3.4. coreRange 5047

C.3.5. memSizeRange 5047

C.3.6. diskSizeRange 5047

C.3.7. backupEnabled 5047

C.3.8. synchronousCopyEnabled 5047

C.3.9. partitionEnabled 5148

C.3.10. compressionEnabled 5148

C.3.11. retentionEnabled 5148

C.3.12. tunings 5148

C.3.13. cachingEnabled 5148

C.4. DatabaseTemplate 5148

C.4.1. definition 5249

C.4.2. clusterType 5249

C.4.3. numberNodes 5350

C.4.4. cores 5350

C.4.5. memSize 5350

C.4.6. diskSize 5350

C.4.7. backupEnabled 5350

C.4.8. synchronousCopyEnabled 5350

C.4.9. partitionEnabled 5451

C.4.10. compressionEnabled 5451

C.4.11. retentionEnabled 5451

C.4.12. tuning 5451

C.4.13. cachingEnabled 5451

C.5. Database 5451

C.5.1. definition 5552

C.5.2. externalManagementResource 5552

C.5.3. clusterType 5653

C.5.4. numberNodes 5653

C.5.5. cores 5653

C.5.6. memSize 5653

C.5.7. diskSize 5653

C.5.8. backupEnabled 5653

C.5.9. synchronousCopyEnabled 5653

C.5.10. partitionEnabled 5754

C.5.11. compressionEnabled 5754

C.5.12. retentionEnabled 5754

C.5.13. tuning 5754

C.5.14. cachingEnabled 5754

C.5.15. operationsThroughput 5754

C.5.16. operationsBandwidth 5855

C.5.17. resourceState 5855

Annex D. Implementation Considerations (Non-Normative) 5855

D.1. Types of Platform Deployments 5855

D.2. Scaling 5956

Cloud Application Management for Platforms

1. Introduction

1.1. Overview

Platform as a Service (PaaS) is a term that refers to a type of cloud computing in which the service provider offers customers/consumers access to one or more instances of a running application computing platform or application service stack. NIST defines PaaS [SP800-145] as a “service model” with the following characteristics:

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

There are multiple commercial PaaS offerings in existence using languages such as Java, Python and Ruby and frameworks such as Spring and Rails. Although these offerings differ in such aspects as programming languages, application frameworks, etc., there are inherent similarities in the way they manage the lifecycle of the applications that are targeted for, and deployed upon them. The core proposition of this specification is that these similarities can be leveraged to produce a generic application and platform management API that is language, framework, and platform neutral.

For PaaS consumers this management API would have the following benefits:

· “Portability between clouds” is emerging as one of the primary concerns of cloud computing. By standardizing the management API for the use cases around deploying, stopping, starting, and updating applications, this specification increases consumers’ ability to port their applications between PaaS offerings.

· It is likely that implementations of this specification will appear as plugins for application development environments (ADEs) and application management systems. Past experience has shown that, over time, such generic implementations are likely to receive more attention and be of higher quality than the implementations written for solitary, proprietary application management interfaces.

For PaaS providers this management API would have the following benefits:

· Because the strength and features of a PaaS offering’s application management API are unlikely to be perceived as key differentiators from other PaaS offerings, the existence of a consensus management API allows providers to leverage the experience and insight of the specification’s contributors and invest their design resources in other, more valuable areas.

· By increasing the portability of applications between PaaS offerings, this management API helps “grow the pie” of the PaaS marketplace by addressing one of the key pain points for PaaS consumers.

1.2. Purpose

This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.

The following is a non-exhaustive list of the use cases which are supported by this specification. Details of these use cases can be found in Annex B.

· Building and packaging an application in a local Application Development Environment (ADE)

· Building an application in an ADE running in the cloud

· Importing a Platform Deployment Package into the cloud

· Uploading application artifacts into the cloud

· Run, stop, suspend, snapshot, and patch an application

1.3. Example

This example illustrates a scenario in which the application administrator wants to run and monitor an application. It assumes that the application package was previously made available to the platform, either because it was uploaded to the platform or developed directly on the platform.

The administrator starts by deploying the application package to the platform. This is done by sending an HTTP POST request to the platform entry point URL as shown below, where "/myPaaS" is the entry point and "/myPaas/pkgs/1" is the location of the application package.

POST /myPaaS HTTP/1.1
Host: example.org
Content-Type: application/vnd.org.example.PaaS+json; type=...
Content-Length: ...
{
"pdp_uri": "/myPaaS/pkgs/1"
}

On receiving such a request the platform deploys the application package and creates a new resource "/myPaas/templates/1" that represents the deployed application. The response from the platform is show below.

HTTP/1.1 201 Created
Location: http://example.org/myPaaS/templates/1
Content-Type: ...
Content-Length: ...
...

Once the application is deployed, the administrator starts the application by sending an HTTP POST request to the resource that represents the deployed application, which was obtained in the previous step ("/myPaaS/templates/1").

POST /myPaaS/templates/1 HTTP/1.1
Host: example.org

On successful start the platform creates a new resource representing the running application and provides the URL of that resource "/myPaaS/apps/1" in the response as show below.

HTTP/1.1 201 Created
Location: http://example.org/myPaaS/apps/1
Content-Type: ...
Content-Length: ...
...

The administrator can now monitor the running application by sending an HTTP GET request to the resource that represents the running application, which was obtained in the previous step ("/myPaas/apps/1").

GET /myPaaS/apps/1 HTTP/1.1
Host: example.org

The response contains the JSON representation of the running application as shown below.

HTTP/1.1 200 OK
Content-Type: application/vnd.org.example.PaaS+json; type=Assembly
Content-Length: ...
{
"uri": "http://example.org/myPaaS/apps/1",
"name": "Hello Cloud App",
"description": "Hello Cloud Application Running in a PaaS Env",
"created": "2012-06-04T20:47Z",
"definition": "...",
"applicationComponents": [
{
"href": "/myPaaS/apps/1/acs/1"
},
{
"href": "myPaaS/apps/1/acs/2"
}
],
"platformComponents": [
{
"href": "/myPaaS/pcs/1"
},
{
"href": "myPaaS/pcs/2"
}
],
"assemblyTemplate": "/myPaaS/templates/1",
"resourceState": {
"state": "RUNNING"
}
}

1.4. Non-Goals

The specification of functional interfaces specific to services provided by individual components (see Application Components and Platform Components, below) is out of scope for this document. This is because such interfaces may be quite diverse and differ significantly from platform to platform.

1.5. PaaS Roles

There are many roles that can be defined for a PaaS environment. For the purposes of this specification we identify four roles:

Application Developer: The person that builds and tests an application and presents the developed artifacts for deployment.

Application Administrator: The person that deploys applications and manages the application throughout its life-cycle.

Together these two roles make up the consumers of the management API described in this specification. This specification is intended mainly for Application Administrators, though it does constraint the artifacts that an Application Developer presents for deployment.

Platform Administrator: The person that manages the platform. This specification describes some of the functions of a Platform Administrator, though most of the functions of this role are outside its scope.

Application End-User: A user of an application deployed on the platform. The interactions of the Application end-user and the application are outside the scope of this specification.

1.6. Document Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

Only the lower case versions of these keywords are used in this document in accordance with RFC 2119 in order to conform to ISO document requirements.