OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (CAMP-175) Could remove "artifacts" or make them optional


    [ https://issues.oasis-open.org/browse/CAMP-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60490#comment-60490 ] 

Gilbert Pilz edited comment on CAMP-175 at 8/9/15 9:37 PM:
-----------------------------------------------------------

At the moment CAMP is application-centric. It doesn't support managing the lifecycle of a service except as an opaque side effect to the actions that are performed on an application. Starting with a plan resource that references a specific service resource (these are misnamed - BTW), you create a running application by POSTing to the assemblies_factory resource. During the processing of this request the Provider is expected to do "something" with regards to thing that is described by the service resource; either bind the new application to an existing, running instance of the thing described by the service resource, or create a new instance of the thing described by the service resource and bind the new thing to this newly created entity, or ... All the CAMP Consumer knows is that, once the assembly resource is created and stable (i.e. the application is running), an instance of the thing described by the service will be up and doing its job for the application. CAMP hints, but doesn't require, that this running instance will be represented by a component.

My problem with the idea of supporting the representation of standalone services and managing their lifecycle is that I don't know how you would bind such services to an application. The assembly resource represents a running application - I'm stuck on how an application that requires a particular service could actually be "running" if it weren't already bound to the services that it required. If, instead of trying to bind the running standalone service to an assembly resource we try to bind it to a plan resource, I can't see how this is that different from what we have today. The "service resource" is supposed to tell you everything about the thing that your application will have access to once it is launched. Whether that thing is already running or not is, from the applications viewpoint, irrelevant.

I'm not saying we can't expand the focus of CAMP to be less application centric. If we want to support the management of services independently of the applications that use them, I'd like to discuss the use cases around that feature.


was (Author: gilbert.pilz):
At the moment CAMP is application-centric. It doesn't support managing the lifecycle of a service except as an opaque side effect to the actions that are performed on an application. Starting with a plan resource that references a specific service resource (these are misnamed - BTW), you create a running application by POSTing to the assemblies_factory resource. During the processing of this request the Provider is expected to do "something" with regards to thing that is described by the service resource; either bind the new application to an existing, running instance of the thing described by the service resource or create a new instance of the thing described by the service resource and bind the new thing to this newly created entity, or ... All the CAMP Consumer knows is that, once the assembly resource is created and stable (i.e. the application is running), an instance of the thing described by the service will be up and doing its job for the application. CAMP hints, but doesn't require, that this running instance will be represented by a component.

My problem with the idea of supporting the representation of standalone services and managing their lifecycle is that I don't know how you would bind such services to an application. The assembly resource represents a running application - I'm stuck on how an application that requires a particular service could actually be "running" if it weren't already bound to the services that it required. If, instead of trying to bind the running standalone service to an assembly resource we try to bind it to a plan resource, I can't see how this is that different from what we have today. The "service resource" is supposed to tell you everything about the thing that your application will have access to once it is launched. Whether that thing is already running or not is, from the applications viewpoint, irrelevant.

I'm not saying we can't expand the focus of CAMP to be less application centric. If we want to support the management of services independently of the applications that use them, I'd like to discuss the use cases around that feature.

> Could remove "artifacts" or make them optional
> ----------------------------------------------
>
>                 Key: CAMP-175
>                 URL: https://issues.oasis-open.org/browse/CAMP-175
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>    Affects Versions: 1.2
>            Reporter: Alex Heneveld
>            Assignee: Alex Heneveld
>            Priority: Minor
>
> Some people we've talked to find the "artifacts" entry point for the plan confusing. Personally I like it and IMHO it *should* become the standard way to do things.
> But right now people mostly seem to be building things up and so the "services" entry point is preferred -- look at how docker/fig/compose do it, and cloud foundry, and apache brooklyn.
> To simplify we could remove all mention of "artifacts" or make them optional.
> Or not ... this is just something to be aware of.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]