[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (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:all-tabpanel ]
Alex Heneveld updated CAMP-55:
------------------------------
Proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49901/camp-spec-v1.1-wd15-issue-55.docx (was: 1. Define a general "application lifecycle" diagram with just 3 states: uploaded / deployed / active.
- uploaded: the app is ready to be deployed ("deploy" request)
- deployed: an assemblyTemplate has been created for this app, ready to be instantiated one or more times.
- active: at least one run-time has been instantiated (one Assembly) from the assemblyTemplate. In this state we can still "instantiate", and maybe even "customize".
2. Then define a finer state machine for "application instances", i.e. for each Assembly. That one would have: running / suspended / stopped (maybe) / ... And such a state machine would apply to each "run-time" or instance of an Application. Such finer states only make sense when the application is in its "active" state.
See attached ppt for how we could update the lifecycle diagram. See: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48331/CAMP-lifecyclediagrams-issue55.pptx
Latest concrete proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49552/camp-spec-v1.1-wd11-issue55-v3.doc)
SUBMITTING a new proposal based on WD15 which combines the previous section 2.2 and chapter 3 into chapter 3:
* Instead of describing application lifecycle separately (previously in chapter 3) from how the management models change following the same pattern, I have folded together sections 2.2 and 3
* I have tried to keep all the information which pertains to actual elements in the API, but removed some places where the discussion and vocabulary which does not (AFAIK) pertain to anything currently in the API (such as application state, exporting PDP)
* I have recommended using Representation Skew to express some of the same information
* I have also slightly tuned previous section 2.1 (now chapter 2) so that unrelated concepts are in separate sections
There are a lot of further incremental improvements which could be made to the text but I think this makes it easier and simpler to work on, without repeating ourselves. I look to others for any further enhancements we wish to make at this time.
( Also I am REMOVING these comments from the "proposal" field:
1. Define a general "application lifecycle" diagram with just 3 states: uploaded / deployed / active.
- uploaded: the app is ready to be deployed ("deploy" request)
- deployed: an assemblyTemplate has been created for this app, ready to be instantiated one or more times.
- active: at least one run-time has been instantiated (one Assembly) from the assemblyTemplate. In this state we can still "instantiate", and maybe even "customize".
2. Then define a finer state machine for "application instances", i.e. for each Assembly. That one would have: running / suspended / stopped (maybe) / ... And such a state machine would apply to each "run-time" or instance of an Application. Such finer states only make sense when the application is in its "active" state.
See attached ppt for how we could update the lifecycle diagram. See: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48331/CAMP-lifecyclediagrams-issue55.pptx
OLD - Latest concrete proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49552/camp-spec-v1.1-wd11-issue55-v3.doc )
The NEW (WD15) proposal is at: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49901/camp-spec-v1.1-wd15-issue-55.docx
> 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
> Assignee: Alex Heneveld
> 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]