Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify pending status, introduce running #340

Merged
merged 2 commits into from
Mar 4, 2020
+6 −4
Merged

Clarify pending status, introduce running #340

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c8eabd5
Clarify pending status, introduce running
carolynvs-msft Feb 28, 2020
fbbed9e
Clarify that running and pending are temporary still.
carolynvs-msft Mar 2, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions 400-claims.md
View file
Original file line number Diff line number Diff line change
@@ -98,10 +98,11 @@ The fields above are defined as follows:
- `revision` (REQUIRED): An [ULID](https://github.com/ulid/spec) that MUST change each time the claim is modified. It MUST NOT change when a [non-modifying operation](https://github.com/cnabio/cnab-spec/blob/master/101-bundle-json.md#custom-actions) is performed on an installation.
- `started` (OPTIONAL): A timestamp indicating when execution of the operation started.
- `status` (REQUIRED): Indicates the status of the last phase transition. Valid statuses are:
- `failure`: failed before completion
- `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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be more consistent to use an adjective for each status

Suggested change
- `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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should have cancelled as well?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `success`: Completed successfully.
- `succeeded`: Completed successfully.

- `stopped` (OPTIONAL): A timestamp indicating when the execution of the operation stopped.

> Note that credential data is _never_ stored in a claim. For this reason, a claim is not considered _trivially repeatable_. Credentials MUST be supplied on each action. Implementations of the claims specification are expected to retrieve the credential requirements from the `bundle` field.
1 change: 1 addition & 0 deletions schema/claim.schema.json
View file
Original file line number Diff line number Diff line change
@@ -29,6 +29,7 @@
"failure",
"success",
"pending",
"running",
"unknown"
],
"type": "string"