Re: [camp] Cloud Foundry Core

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

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