Skip to content

spec: fix spelling, adjust commas, etc. #327

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

Merged
merged 2 commits into from
Nov 13, 2018
Merged

spec: fix spelling, adjust commas, etc. #327

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
985cb84
spec: fix spelling, adjust commas, etc.
Nov 12, 2018
9cc7602
spec: fix another spelling mistake
Nov 13, 2018
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
22 changes: 8 additions & 14 deletions spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -393,24 +393,18 @@ These limits apply for messages generated by both COs and plugins.
* A `repeated` or `map` field listed as `REQUIRED` MUST contain at least 1 element.
* A field noted as `OPTIONAL` MAY be specified and the specification SHALL clearly define expected behavior for the default, zero-value of such fields.

Scalar fields, even REQUIRED ones, will be defaulted if not specified, and any field set to the defaul value will not be serialized over the wire as per [proto3](https://developers.google.com/protocol-buffers/docs/proto3#default).
Scalar fields, even REQUIRED ones, will be defaulted if not specified and any field set to the default value will not be serialized over the wire as per [proto3](https://developers.google.com/protocol-buffers/docs/proto3#default).

#### Timeouts

Any of the RPCs defined in this spec MAY timeout and MAY be retried.
The CO MAY chooses the maximum time it is willing to wait for a call,
how long it waits between retries, and how many time it retries (these
values are not negotiated between plugin and CO).

Idempotency requirements ensure that a retried call with the same fields
continues where it left off when retried. The only way to cancel a call
is to issue a "negation" call if one exists (for example, issue a
`ControllerUnpublishVolume` call to cancel a pending
`ControllerPublishVolume` operation, etc.). In some cases, a CO MAY not
be able to cancel a pending operation, because it depends on the result
of the pending operation in order to execute the "negation" call (for
example, if a `CreateVolume` call never completes, a CO may not have the
`volume_id` to call `DeleteVolume` with).
The CO MAY choose the maximum time it is willing to wait for a call, how long it waits between retries, and how many time it retries (these values are not negotiated between plugin and CO).

Idempotency requirements ensure that a retried call with the same fields continues where it left off when retried.
The only way to cancel a call is to issue a "negation" call if one exists.
For example, issue a `ControllerUnpublishVolume` call to cancel a pending `ControllerPublishVolume` operation, etc.
In some cases, a CO MAY NOT be able to cancel a pending operation because it depends on the result of the pending operation in order to execute the "negation" call.
For example, if a `CreateVolume` call never completes then a CO MAY NOT have the `volume_id` to call `DeleteVolume` with.

### Error Scheme

Expand Down