validate: Soften unrecognized rlimit types to SHOULD violations #481
Conversation
This file contains hidden or 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
wking
force-pushed
the
warn-on-potentially-invalid-rlimits
branch
2 times, most recently
from
0e28021 to
0696cb8
Compare
wking
force-pushed
the
warn-on-potentially-invalid-rlimits
branch
from
0696cb8 to
d395004
Compare
zhouhao3
reviewed
Oct 10, 2017
|
|
||
| // CheckRlimits checks v.spec.Process.Rlimits | ||
| func (v *Validator) CheckRlimits() (errs error) { | ||
| if v.platform == "windows" { |
There was a problem hiding this comment.
Can you add a warning output on this side? such as:
logrus.Warnf("process.rlimits validation not yet implemented for platform %q", v.platform)
Also, does this have some overlap with the validation of the platform in rlimitValid?
There was a problem hiding this comment.
Can you add a warning output on this side?
I don't think we want that. “Not yet implemented” warnings are for cases where runtime-tools has not yet caught up with the spec's requirements. But Windows does not, and likely never will support rlimits and the spec does not define rlimits for Windows.
Also, does this have some overlap with the validation of the platform in
rlimitValid?
I'm touching rlimitValid in this PR. Do you think we need rlimitValid changes beyond those?
|
rebase required @wking , in the current specerror/config.go, the releated code is PosixProcRlimitsTypeGeneError. |
wking
force-pushed
the
warn-on-potentially-invalid-rlimits
branch
from
d395004 to
7553161
Compare
The spec isn't particuarly clear on this, saying [1]:
* Linux: valid values are defined in the
[`getrlimit(2)`][getrlimit.2] man page, such as `RLIMIT_MSGQUEUE`.
* Solaris: valid values are defined in the
[`getrlimit(3)`][getrlimit.3] man page, such as `RLIMIT_CORE`.
and [2]:
For each entry in `rlimits`, a [`getrlimit(3)`][getrlimit.3] on
`type` MUST succeed.
It doesn't say:
Linux: The value MUST be listed in the getrlimit(2) man page...
and it doesn't require the runtime to support the values listed in the
man page [3,4]. So there are three sets:
* Values listed in the man page
* Values supported by the host kernel
* Values supported by the runtime
And as the spec stands, these sets are only weakly coupled, and any of
them could be a sub- or superset of any other. In practice, I expect
the sets to all coincide, with the kernel occasionally adding or
removing values, and the man page and runtimes trailing along behind.
To address that, this commit weakens the previous hard error to a
SHOULD-level error. The PosixProcRlimitsTypeValueError constant is
new to this commit, because the spec contains neither a MUST nor a
SHOULD for this condition, although I expect a SHOULD-level suggestion
was implied by [1].
Also make CheckRlimits a no-op on Windows, because the spec does not
define process.rlimits for that OS [5].
[1]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0/config.md#L168-L169
[2]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0/config.md#L168-L169
[3]: opencontainers/runtime-spec#813
[4]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0/config.md#L463
[5]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0/config.md#posix-process
Signed-off-by: W. Trevor King <[email protected]>
|
On Mon, Oct 23, 2017 at 07:55:53AM +0000, 梁辰晔 (Liang Chenye) wrote:
… in the current specerror/config.go, the releated code is
PosixProcRlimitsTypeGeneError.
Rebased with d395004 → 7553161. I kept a specific-to-this-situation
error (now PosixProcRlimitsTypeValueError) because this check is based
on the man-page reference. The PosixProcRlimitsTypeGeneError, on the
other hand, is [1]:
* a MUST, and
* a runtime requirement, not a config requirement.
[1]: https://github.com/opencontainers/runtime-tools/blob/6554addc535ff61f02ce943e1a048148944be497/specerror/config.go#L45-L46
|
|
LGTM |
|
and add an track liangchenye/markdown-to-json#1 |
|
LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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 PR builds on #480; review that first.
The spec isn't particuarly clear on this, saying:
and:
It doesn't say:
and it doesn't require the runtime to support the values listed in the man page (opencontainers/runtime-spec#813). So there are three sets:
And as the spec stands, these sets are only weakly coupled, and any of them could be a sub- or superset of any other. In practice, I expect the sets to all coincide, with the kernel occasionally adding or removing values, and the man page and runtimes trailing along behind.
To address that, this commit weakens the previous hard error to a SHOULD-level error. The
PosixProcRlimitsValueErrorconstant is new to this commit, because the spec contains neither a MUST nor a SHOULD for this condition, although I expect a SHOULD-level suggestion was implied by this. TheposixProcRefconstant is cherry-picked from #458.Also make
CheckRlimitsa no-op on Windows, because the spec does not defineprocess.rlimitsfor that OS.