Re: [camp] Cloud Foundry Core

[Tobias Kunze <tkunze@redhat.com>]

The use case for a (formal or informal) registry I can think of is to ensure that e.g. the symbols "php-5.4", "apache", "apache-2.4", "apache:mpm-prefork", all the way down to configuration keys and values mean the same across implementations, i.e. to enable my application to depend on these capabilities and run just fine across implementations. While this use case doesn't yet require (again, formal or informal) namespacing, automating it would. A good analog here would be package names and symbols in linux distributions. For instance, in Ubuntu, "emacs23" depends (among others) on "libc6 (>= 2.15)" and "emacs23-bin-common (= 23.3+1-1ubuntu9.1)". The symbols are informally "registered" in the sense that any other apt-based distribution could provide a package that provides ("has the capability" in CAMP-speak) "libc6" in a version that matches the predicate and would thus satisfy the dependency ("requirement" in CAMP-speak). The requirement "emacs23-bin-common (= 23.3+1-1ubuntu9.1)" on the other hand makes it (again, informally) clear that this is a distribution-specific package. Obviously, matching packages to distributions with any degree of confidence that the matched pieces will also run is not covered by this system. This would require namespacing.

Nevertheless, what I want to say here is that not having namespacing and just an informal "registry" will go a long way already.

-Tobias



On Nov 14, 2012, at 15:05, Adrian Otto <adrian.otto@rackspace.com> wrote:

> Alex,
> 
> Yes, we did have some discussion about this prior to the formation of the OASIS TC, and one short side conversation in our recent F2F meeting. Using the company domain name (probably an fqdn is better than the reverse domain style used by Java) would be an effective way of preventing namespace overlap, as every platform service provider will have a unique fqdn they can use to produce their own extensions. Domain names are already unique because they are already held in a global registry. I prefer this approach over setting up yet another registry.
> 
> Adrian
> 
> 
> 
> On Nov 14, 2012, at 1:09 PM, Alex Heneveld <alex.heneveld@cloudsoftcorp.com> wrote:
> 
>> 
>> Have we discussed a domain-ownership convention for namespacing? ie only Acme Corp can use a com.acme.XXX namespace ?
>> That gets around the need for a registry.
>> 
>> Also the maven monotonically increasing version convention (for non-snapshot components) ?
>> 
>> --A
>> 
>> 
>> On 14/11/2012 18:47, Tobias Kunze wrote:
>>> 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
>>>> 
>>> ---------------------------------------------------------------------
>>> 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
>