config: Move valid-value rules to their own section #681
+5
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This wording just landed via 718f9f3 (origin/pr/673) minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#673), but the rule is generic and not unique to platform-specific properties. Also adjust the wording somewhat to match the more established wording from the "Extensibility" section. Signed-off-by: W. Trevor King <wking@tremily.us>
|
I think the original wording is much more straightforward and easier to understand than the changes in this PR. |
|
LGTM |
1 similar comment
|
LGTM |
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
May 24, 2017
This line landed in 718f9f3 (origin/pr/673) minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#673), but I'm not clear on the motivation. The wording reads to me like "you don't have to support valid values for platform-specific fields if you don't want to", but we already cover unsupported value handling with the "MUST generate an error when invalid or unsupported values are encountered" language separated out in c763e64 (config: Move valid-value rules to their own section, 2017-02-07, opencontainers#681). This commit removes the ambiguous line. Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Jun 1, 2017
This line landed in 718f9f3 (origin/pr/673) minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#673), but I'm not clear on the motivation. The wording reads to me like "you don't have to support valid values for platform-specific fields if you don't want to", but we already cover unsupported value handling with the "MUST generate an error when invalid or unsupported values are encountered" language separated out in c763e64 (config: Move valid-value rules to their own section, 2017-02-07, opencontainers#681). This commit removes the ambiguous line. Signed-off-by: W. Trevor King <wking@tremily.us>
Merged
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 4, 2017
In 718f9f3 (minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#673) we got: Implementations MUST error out when invalid values are encountered and MUST generate an error message and error out when encountering valid values it chooses to not support In c763e64 (config: Move valid-value rules to their own section, 2017-02-07, opencontainers#681), I'd moved that out into the current "Valid values" section with the line I'm removing in this commit. However, giving runtimes a blanket clause to ignore valid values makes it harder to use runtimes, because you can't be sure an OCI-compliant runtime supports the spec-defined value you need [1]. There have been concerns about requiring runtimes to support values which are not supported by the host system [2]. But since 766abd6 (runtime.md: Require 'create' to fail if config.json asks for the impossible, 2016-09-08, opencontainers#559) we've had runtime.md wording that gives the runtime the ability to compliantly die in those cases. That text had a wording tweak in 72e8062 (runtime: Explicitly make process.* timing implementation-defined, 2017-02-27, opencontainers#700), and is now: If the runtime cannot apply a property as specified in the configuration, it MUST generate an error and a new container MUST NOT be created. With this line removed, consumers will be able to rely on valid-value support in compliant runtimes, although many properties could use clearer runtimes-MUST-support wording for those values. However, we can sort those out on a per-property basis. And runtimes are still allowed to support extention values not defined in the spec (e.g. new capability types, or mount options, or whatever). Like all extentions, it is up to the runtime and runtime-caller to negotiate support in those cases. [1]: opencontainers#813 (comment) [2]: opencontainers#673 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 4, 2017
In 718f9f3 (minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#673) we got: Implementations MUST error out when invalid values are encountered and MUST generate an error message and error out when encountering valid values it chooses to not support In c763e64 (config: Move valid-value rules to their own section, 2017-02-07, opencontainers#681), I'd moved that out into the current "Valid values" section with the line I'm removing in this commit. However, giving runtimes a blanket clause to ignore valid values makes it harder to use runtimes, because you can't be sure an OCI-compliant runtime supports the spec-defined value you need [1]. There have been concerns about requiring runtimes to support values which are not supported by the host system [2]. But since 766abd6 (runtime.md: Require 'create' to fail if config.json asks for the impossible, 2016-09-08, opencontainers#559) we've had runtime.md wording that gives the runtime the ability to compliantly die in those cases. That text had a wording tweak in 72e8062 (runtime: Explicitly make process.* timing implementation-defined, 2017-02-27, opencontainers#700), and is now: If the runtime cannot apply a property as specified in the configuration, it MUST generate an error and a new container MUST NOT be created. With this commit, consumers will be able to rely on valid-value support in compliant runtimes. Many properties could use clearer runtimes-MUST-support wording for those values, but we can sort those out on a per-property basis in follow-up work. And runtimes are still allowed to support extention values not defined in the spec (e.g. new capability types, or mount options, or whatever). Like all extentions, it is up to the runtime and runtime-caller to negotiate support in those cases. [1]: opencontainers#813 (comment) [2]: opencontainers#673 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 4, 2017
In 718f9f3 (minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#673) we got: Implementations MUST error out when invalid values are encountered and MUST generate an error message and error out when encountering valid values it chooses to not support In c763e64 (config: Move valid-value rules to their own section, 2017-02-07, opencontainers#681), I'd moved that out into the current "Valid values" section with the line I'm removing in this commit. However, giving runtimes a blanket clause to ignore valid values makes it harder to use runtimes, because you can't be sure an OCI-compliant runtime supports the spec-defined value you need [1]. There have been concerns about requiring runtimes to support values which are not supported by the host system [2]. But since 766abd6 (runtime.md: Require 'create' to fail if config.json asks for the impossible, 2016-09-08, opencontainers#559) we've had runtime.md wording that gives the runtime the ability to compliantly die in those cases. That text had a wording tweak in 72e8062 (runtime: Explicitly make process.* timing implementation-defined, 2017-02-27, opencontainers#700), and is now: If the runtime cannot apply a property as specified in the configuration, it MUST generate an error and a new container MUST NOT be created. As it stands both before and after this commit, a runtime can *still* die in 'create' because it cannot apply values supported by the host. This commit is just a step towards requiring runtimes to support as many values as the host supports; it doesn't get us all the way there. Many properties could use clearer runtimes-MUST-support wording for those values, but we can sort those out on a per-property basis in follow-up work. And runtimes are still allowed to support extention values not defined in the spec (e.g. new capability types, or mount options, or whatever). Like all extentions, it is up to the runtime and runtime-caller to negotiate support in those cases. [1]: opencontainers#813 (comment) [2]: opencontainers#673 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This wording just landed via #673, but the rule is generic and not unique to platform-specific properties.
Also adjust the wording somewhat to match the more established wording from the “Extensibility” section.