Re: [camp] Cloud Foundry Core

[Tobias Kunze <tkunze@redhat.com>]

Just to clarify: yes, we'll need a registry if portability is to be ensured. Until then, though, this mechanism is sufficient to ensure that new services may be discovered.

Of course, if Capabilities and Requirements are used, the symbols used there need to be defined/registered, but that is outside of  the spec as I understand it at this point.

-Tobias


>> Without some agreement the "name", the attribute space (e.g. "tomcatVersion", "javaVersion", etc.), and the value-space of those attributes - you can't tell if this template describes "the same service" as the ones described by Cloud Foundry (or some other registry).
> 
> Yes, but that's OK I'd think.
> 
> -Tobias
> 
> 
> On Nov 14, 2012, at 8:59, GILBERT PILZ <gilbert.pilz@oracle.com> wrote:
> 
>> But what you get when you dereference the links in Platform.platformComponentTemplates[] is something like  the following:
>> 
>> {
>> "uri" : "http://slc03lgx.us.oracle.com/campSrv/PlatformComponentTemplate/2";,
>> "name" : "Apache Tomcat 7.0.29",
>> "description" : "Bitnami TomcatStack 7.0.29-0",
>> "created" : "2012-09-10T16:34:00-0800",
>> "resourceState" : {
>>   "state" : "READY"
>> },
>> "tomcatVersion" : "7.0.29",
>> "javaVersion" : "1.6.0_33",
>> "servletVersion" : "3.0",
>> "jspVersion" : "2.2"
>> }
>> 
>> Without some agreement the "name", the attribute space (e.g. "tomcatVersion", "javaVersion", etc.), and the value-space of those attributes - you can't tell if this template describes "the same service" as the ones described by Cloud Foundry (or some other registry).
>> 
>> ~ gp
>> 
>> On 11/14/2012 8:33 AM, Tobias Kunze wrote:
>>> I think we have a mechanism, although not one dedicated to discovering new services: Platform.platform_component_templates[]. No?
>>> 
>>> -Tobias
>>> 
>>> 
>>> On Nov 14, 2012, at 8:02, Ashok Malhotra<ashok.malhotra@oracle.com>  wrote:
>>> 
>>>> Do we have an issue that covers service discovery or should we open one?
>>>> All the best, Ashok
>>>> 
>>>> On 11/14/2012 7:47 AM, Behrens, Michael V CTR (US) wrote:
>>>>> Good info...Having a query REST API to get a list of services from a provider sounds like a basic/important interface.  If new services are installed, they should be able to make themselves visible, however that might be an internal mechanism (outside the spec).
>>>>> 
>>>>> -----Original Message-----
>>>>> From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On Behalf Of Adrian Otto
>>>>> Sent: Wednesday, November 14, 2012 10:22 AM
>>>>> To: camp@lists.oasis-open.org
>>>>> Subject: [camp] Cloud Foundry Core
>>>>> 
>>>>> Today there was an announcement in the news you should be aware of. The Cloud Foundry guys have made an attempt at cross-installation compatibility by defining supported application frameworks and services that applications can use. There is a test tool. If the list of standard ones is present, then you are considered compatible, and an application expecting those components is expected to work when moved to that platform.
>>>>> 
>>>>> http://core.cloudfoundry.org/definition
>>>>> 
>>>>> 
>>>>> It seems simple, but it does validate the idea of keeping some registry or list of common common components, and a well defined way to check if a given application is expected to work on a target platform.
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
>>>> For additional commands, e-mail: camp-help@lists.oasis-open.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: camp-help@lists.oasis-open.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: camp-help@lists.oasis-open.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: camp-help@lists.oasis-open.org
>