[OASIS Issue Tracker] Commented: (CAMP-55) Lifecycle Diagram is conflating two levels of states, leading to inconsistencies

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32608#action_32608 ] 

Gilbert Pilz commented on CAMP-55:
----------------------------------

I think separating the lifecycles of the application from its individual instances is a good idea. However, I'm questioning the need to represent "UPLOADED" as an application lifecycle state. It seems to me that, from a high level, there are two ways to deploy a PDP onto a CAMP platform (1) POST the PDP directly to the Platform resource as a multipart attachment, or (2) (what is in the spec today) POST a URL to the PDP to the Platform resource.

In (1) there is no "UPLOADED" state (alternatively, you could claim that there is an automatic transition from the UPLOADED to the DEPLOYED state, but experience has shown that the TC has a resistance to this idea and, in any case, describing such automatic transitions is difficult), you go straight to DEPLOYED. In (2) the fact that we are using a URL means that the PDP could be anywhere. Maybe it's just me but it seems that, when we say something is a "state" in the CAMP spec, we are implying that the CAMP provider is involved somehow. So is an application in the UPLOADED state if the PDP is sitting on some unrelated HTTP server or on a github repository?

I think, as far as interoperability goes, we need to be precise about how you register/deploy a PDP onto the platform, but I don't think we need to model an UPLOADED state. 

> Lifecycle Diagram is conflating two levels of states, leading to inconsistencies
> --------------------------------------------------------------------------------
>
>                 Key: CAMP-55
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-55
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Jacques Durand 
>
> The issue with our current application  lifecycle diagram (and state machine): it conflates two concepts behind the notion of "application lifecycle": 
> (1) the general notion of application covering a broad lifecycle from upload to removal, 
> (2) the narrower notion of run-time with more dynamic states. 
> That leads to the following inconsistencies:
> - Because the same assemblyTemplate can be used to create several Assemblies (as expected for some apps when used in a SaaS context), each one of these assemblies can find itself in a different state (suspended, running...) What state is the application in now?
> - just because you delete one instance among several does not bring you back to "deployed".
> - a state diagram like ours generally assume that you can find yourself in only one state at a time. E.g. if you go from "deployed" to "Instantiated" then you are no longer "deployed". However, again after an instantiation the assemblyTemplate still exists and is available for new instantiations. That means that you can still do an "instantiate" operation when  in the "Instantiated" state. That reflexive  transition is missing in our diagram, yet would sound weird... (why would you "instantiate" again if in the "instantiated" state?). 
> - Also, can you still customize your assemblyTemplate between two instantiations? I'd assume so since we don't try hard to maintain 100% consistency between an Assembly and its assemblyTemplate (can modify the Assembly too).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira