[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=32540#action_32540 ] 

Jacques Durand  commented on CAMP-55:
-------------------------------------

>The action names on the lines between the stats suggest that we will have methods for each like "instantiate". 
>What actually happens is you do a POST on an Assembly Template resource, and produce an Assembly 

Indeed, we don't pretend that the state transitions - at least in the general "application lifecycle" diagram - must be driven by named methods. However we may want more homogeneity when transitioning states at the application instance level (TBD by issue CAMP31).

So let me complete the proposal with the following text:to comment the figure (to be harmonized with current state defs in 3.1, 3.2):

"The lifecycle of an application and of its instances can be represented by two related state diagrams:
(a) the general application lifecycle diagram, showing the general states of an application through its entire lifecycle. One of these states is "active", meaning this application has executing instances.
(b) the application instance state diagram, showing the detailed states of a particular application instance, when this application itself is in the "active" state of its lifecycle (see (a)).

"Transitions in the general application lifecycle diagram are governed by specific actions on different resources:

- Transitioning to "uploaded" state means importing an application package (PDP) on the provider site and verifying that this PDP is valid. In that state all static information necessary to deploy an application is available on Provider site and validated. In terms of resources, reaching this state means adding a PDP to the provider site.
- Transitioning to "deployed" state ("deploy" or "register" operation) means creating the application template resources described in the PDP and matching them to existing Platform components. In that state the application is recognized as viable for this platform, and the path to its activation is clear with all resources ready to be allocated, i.e. ready to run. In terms of resources, reaching this state means creating (from the PDP) an "assembly template" for the application on the provider site.
- Transitioning to "active" state ("instantiate" operation) means actually starting the application so that it is now under control of its users.  In that state the application is operational and responsive to its users. In terms of resources, In terms of resources, reaching this state means creating (from an assembly Template) one or more "assemblies" representing application instances at the provider site."

Transitions for the application instance state diagram are leading to the different states in which an active application instance can find itself. Such transitions are governed by (here, solution to issue CAMP31)".

> 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