|
I have a vision here, and I have a suggested approach. I will try to clarify which is which:
(Suggested) I don't think there needs to be a hosted registry to start with. I think a good first step is for the OASIS CAMP TC to simply specify how the service catalog works in each individual CAMP system so that applications can quickly determine if
they are runnable on the target platform. Apps can query the service catalog to judge compatibility against basic requirements.
(Suggested) Next, we publish (possibly in a separate document referred to by the spec as optional to implement) a list of generic CAMP symbol names for common platform components. Each maps to an actual Platform Component Template that runs on the target
platform. We specify the camp: symbol prefix as reserved. This would strengthen the interoperability/compatibility story between platforms.
(Suggested) Where there are gaps, the each service provider can define their own symbol names, such as rackspace.com:mysql. This way if you have numerous options that are compliant, the application can select the best one based on whatever criteria it
cares about. It will perform a GET on each of the Platform Component Templates to look at the attributes of each one for things like versions, capacity ranges such as storage, etc.
(Vision) My hunch is that this approach would get us close enough to the goal, and allow future solutions to improve upon this based on feedback from the various implementors. At that point a community registry may be established somewhere that could offer
additional symbols in a community namespace. This would allow symbols like campregistry.org:dns if/when standard interfaces for such services emerge. This would allow more to be added outside the scope of the CAMP TC.
(Vision) If one provider has a vanilla Openstack IaaS running, they may expose a symbol like openstack.org:compute_kvm if the Openstack community defines a functional interface that would allow that. Eventually you might get to a point where you could
just query the community service catalog and determine which providers can run a given application based on the stated requirements.
(Suggested) I'm only suggesting we take the first step and define how a service registry would operate, require that each platform offer a catalog (which could be completely empty if they want), along with a set of well known symbols for basic Platform
Components, and some clear definitions to accompany each.
--
Adrian
Where will these name symbols be registered? Not sure IANA is a good place for it.
Ask OASIS to host a registry?
All the best, Ashok
On 11/14/2012 3:05 PM, Adrian Otto wrote:
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" : [
],
"camp_linux_apache_2.2" : [
],
...
}
}
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
|