OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Service Catalog Discussion


TC,

Today's follow up comments on the "[camp] Cloud Foundry Core" thread have inspired me to think a bit more about common requirements between various CAMP implementations. I recognize that some of these areas may be beyond the scope of our charter because they define functional interfaces, but the use of these functional interfaces would be optional. We might need to have a discussion about whether we are willing to pursue this even if it goes beyond our current scope.


Goal: Interoperability. Give application developers a way to develop applications that will work on numerous CAMP compliant platforms by referring to generic requirements using a common set of "name symbols" that are well understood, and generally high level.

I suggest:

1) We create a definition of "standard" platform component "name symbols" that name various popular services that many platforms are likely to offer.

A good example of this would be a hosted MySQL 5.1 service. In order to strengthen the application portability story with CAMP, there are more things needed. I suggest we create some form of a catalog that each implementor of the spec can choose to populate. The service catalog must be implemented, but the CAMP specific symbols would not be required to be listed in the catalog for interoperability purposes only. 

Example:

Service Symbol : camp_mysql_5.1
Requirements: Provides MySQL protocol services for at least one user, password credentials, and one corresponding logical database. Must be protocol compatible with MySQL 5.1. ...
Required Component Attributes: [ (string) hostname, (int) port, (string) username, (string) database_name, (string) version ] … that are set when the service boots.
Optional Parameters: [ (string) username, (string) password, (string) database_name ] … to be passed in when creating the Component from the Template

2) Specify an API to get the service catalog to list the relations between the various "name symbols", and the platform components provided. Perform a GET on the /services resource (as identified by the Platform resource) to get the service catalog, which is a JSON representation of an associative array keyed by "name symbols". Each value in the array would be an array of Link types that refer to Platform Component Templates. Exactly one of the link types would be indicated as a 'default' for that camp_* symbol. This allows the platform to offer multiple choices for complaint platform components. Each "name symbol" must have at least one Platform Component Template listed.

Example:

{
 "services" : { 
"camp_mysql_5.1" : [ 
{ "uri" : "http://platform.rackspace.com/783927/89023-4328743-232789",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Databases", "default" : true },
{ "uri" : "http://platform.rackspace.com/783927/31337-4328743-232791",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Server_LAMP"},
{ "uri" : "http://platform.rackspace.com/783927/89023-4328743-232790",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Server_Running_MySQL_5.1"},
{ "uri" : "http://platform.rackspace.com/783927/89023-4328743-232800",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Server_Running_MySQL_5.1_with_SSD"},
],
"camp_linux_apache_2.2" : [
{ "uri" : "http://platform.rackspace.com/783927/31337-4328743-232744",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Server_Apache_2.2", "default" : true },
{ "uri" : "http://platform.rackspace.com/783927/31337-4328743-232782",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Server_Apache_2.2.13"},
{ "uri" : "http://platform.rackspace.com/783927/31337-4328743-232791",  "type" : "PlatformComponentTemplate", "name" : "Rackspace_Cloud_Server_LAMP"},
],
...
 }
 }

Implementors of the CAMP spec can choose to support the camp_* "name symbols", or not. Querying the service catalog and verifying whether the needed symbols are present or not would be an indication of a given application would be runnable on a given target platform. If a CAMP compliant service provider wanted to offer all of the CAMP "name symbols", they could make at least one Platform Component Template that supported all of them, and list it for each of the standard symbols, like I do above with the Rackspace_Cloud_Server_LAMP Template.

If the application wants to be more specific, and pick a non-default template, it can GET each of the PlatformComponentTemplates listed, and find the best one based on the attributes provided, such as version numbers, version ranges, memory size, or whatever. These attributes do not need to be specified. Use of them would be completely optional.

3) Offer an API call for passing in an array of one or more "symbol names", and if all are offered by the platform, to return a "200 OK" response with an abbreviated service catalog that lists the requested "symbol names" along with the arrays of Platform Component Templates available for each. If one or more is missing, then a 400 reply is provided, indicating that one or more of the requested "name symbols" are not supported, and listing each.

Thoughts? I'm looking forward to discussion on this. If there is adequate support for it I will submit it as an issue.

Adrian


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]