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] Commented: (CAMP-55) Lifecycle Diagram is conflating two levels of states, leading to inconsistencies


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

Alex Heneveld commented on CAMP-55:
-----------------------------------

i think i better understand the proposal now -- the states are extensible, so in effect the camp-provided enumeration is a convenience but not enforced

i like that better

however in order for extended states to be useful, they need to be interrogable, so a consumer can discover that e.g. an assembly is not operational when it is in (for example) my extended STOPPED_PROCESS state

what questions we want to ask however then becomes the question.

for an AssemblyTemplate i think it is simple -- i need to know "can I instantiate this now?".  e.g. AssemblyTemplateResourceState has attribute "instantiable" and the current DEPLOYED (which is confusing to me as it suggests there are Assembly instances but that is another discussion; I'd prefer UNRESOLVED) would say instantiable=false whereas RUNNABLE (for which i'd prefer RESOLVED) says instantiable=true

for an Assembly it is tricker.  i guess i want to know "is it running nicely" ?  or alternatively, "is this be expected to be operational" and "is it in the expected state without signficicant issues" ?  the former is redundant if we have the latter:

    isRunningNicely == (isExpectedToBeOperational && isInExpectedStateWithoutIssues)

BUT this all seems ugly and complicated ... even if the semantics are about right.  especially the idea of different attributes for resource states for AssemblyTemplate (isInstantiable) vs Assembly (isRunningNicely).  so i'm not sure what to do...

> 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 
>            Priority: Critical
>
> 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

        


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