[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:
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]