Clarify pending status, introduce running #340
Conversation
There was a problem hiding this comment.
It certainly makes sense to me to have both pending and running, for the reasons mentioned.
My only reservation lies in what I perceive as an inherent difference between "conclusive" statuses like failure, unknown and success and "transient" statuses like pending and running. Is more prescription warranted in the spec around the mechanism for tools to report back the "conclusive" status for actions whose statuses were formerly pending or running? Would a tool be expected to generate a new claim and result with this "conclusive" status? Or just modify the result on/associated with an existing claim?
Technically, this question existed previous to this PR (it would've been applicable when just pending or underway was around), so it doesn't need to be addressed here... just posing it for thoughts.
The expectation is result is a modifiable sub-document, it contains fields that are outputs from the execution of the bundle (per the other PR), and they can be set without requiring a new claim to be created. |
This makes sense. In a follow-up, we might consider adding specification that status updates from transient to completed statuses either should or must update the result object and either should not or must not update the associated claim or claim revision... |
carolynvs
force-pushed
the
clarify-installation-status
branch
from
be4a0c9 to
d16b48f
Compare
|
Follow-up issues should be filed in cnab-go and libcnab-rust |
| - `pending`: Execution has been requested and has not begun. This should be considered a temporary status, and the runtime SHOULD work to resolve this to either `failure` or `success`. | ||
| - `running`: Execution is in progress and has not completed. This should be considered a temporary status, and the runtime SHOULD work to resolve this to either `failure` or `success`. | ||
| - `unknown`: The state is unknown. This is an error condition. | ||
| - `success`: Completed successfully. |
There was a problem hiding this comment.
Perhaps we should have cancelled as well?
| - `pending`: in progress. This should only be used if the invocation container MUST exit before it can determine whether all operations are complete. Note that `pending` is a _long term status_ that indicates that the installation's final state cannot be determined by the system. For this reason, it should be avoided. When used, `pending` should be considered a temporary status, and the runtime SHOULD work to resolve this to either `failure` or `success`. | ||
| - `unknown`: the state is unknown. This is an error condition. | ||
| - `success`: completed successfully | ||
| - `failure`: Failed before completion. |
There was a problem hiding this comment.
It might be more consistent to use an adjective for each status
| - `failure`: Failed before completion. | |
| - `failed`: Failed before completion. |
| - `pending`: Execution has been requested and has not begun. This should be considered a temporary status, and the runtime SHOULD work to resolve this to either `failure` or `success`. | ||
| - `running`: Execution is in progress and has not completed. This should be considered a temporary status, and the runtime SHOULD work to resolve this to either `failure` or `success`. | ||
| - `unknown`: The state is unknown. This is an error condition. | ||
| - `success`: Completed successfully. |
There was a problem hiding this comment.
| - `success`: Completed successfully. | |
| - `succeeded`: Completed successfully. |
The current definition for the pending (previously underway) status is difficult to understand when it is acceptable to use and what it really means about the state of the installation. It's described as both a long term state and temporary. It is also described as "to be avoided". We would like to redefine the state to make it more clear on what the state means, and to make it acceptable for tools to use. Pending now means that the operation has been requested (most likely queued) but has not begun executing. Tools that are immediately executing commands as they are issued would most likely choose to not use this state. However solutions that accept bundle operations from many users at once, for example a cnab operator, may choose to use this state. This also introduces a new state: running. Tools may use this state to indicate that a bundle is currently executing an operation. This can be used by tools to provide operational insight into the activity of the system. For example, when an upgrade takes 30 minutes and people don't know that it's already running, it could easily be initiated more than once by multiple people on the same installation. Allowing tools to make the current status of the installation visible, helps avoid this situation. Signed-off-by: Carolyn Van Slyck <[email protected]>
Signed-off-by: Carolyn Van Slyck <[email protected]>
carolynvs
force-pushed
the
clarify-installation-status
branch
from
d16b48f to
fbbed9e
Compare
|
I will open a follow-on PR to standardize our verbs and add cancelled. |
Synchronize the claim status names with recent spec changes from * cnabio/cnab-spec#344 * success -> succeeded * failure -> failed * cnabio/cnab-spec#345 * +cancelled * cnabio/cnab-spec#340 * +running Signed-off-by: Carolyn Van Slyck <[email protected]>
* Sync claim status names with the spec Synchronize the claim status names with recent spec changes from * cnabio/cnab-spec#344 * success -> succeeded * failure -> failed * cnabio/cnab-spec#345 * +cancelled * cnabio/cnab-spec#340 * +running Signed-off-by: Carolyn Van Slyck <[email protected]> * Match claim status const names with value Update the const names to match the new values, and deprecate StatusSuccess and StatusFailure. Signed-off-by: Carolyn Van Slyck <[email protected]>
The current definition for the pending (previously underway) status is difficult to understand when it is acceptable to use and what it really means about the state of the installation. It's described as both a long term state and temporary. It is also described as "to be avoided".
We would like to redefine the state to make it more clear on what the state means, and to make it acceptable for tools to use. Pending now means that the operation has been requested (most likely queued) but has not begun executing. Tools that are immediately executing commands as
they are issued would most likely choose to not use this state. However solutions that accept bundle operations from many users at once, for example a cnab operator, may choose to use this state.
This also introduces a new state: running. Tools may use this state to indicate that a bundle is currently executing an operation. This can be used by tools to provide operational insight into the activity of the system. For example, when an upgrade takes 30 minutes and people don't
know that it's already running, it could easily be initiated more than once by multiple people on the same installation. Allowing tools to make the current status of the installation visible, helps avoid this situation.
Closes #312