config-linux: Drop the default-filesystem section#678
config-linux: Drop the default-filesystem section#678wking wants to merge 1 commit intoopencontainers:masterfrom
Conversation
Users who need these mounts would have to explicitly set them up in their configuration (as runtime-tools continues to do [1]) if they wanted to guarantee their presence. Users who don't need them can omit them from their configuration. I don't see how keeping a SHOULD-strength runtime requirement helps either of those workflows. [1]: opencontainers/runtime-tools#24 Signed-off-by: W. Trevor King <wking@tremily.us>
|
This section still looks useful to me. |
So do you prefer #679? Or do you like master how it is? If you like master, do you read the current master wording as a suggestion to runtime authors or as a suggestion to config authors? |
|
I prefer the master version |
And I'm citing your earlier comment for the “this is advice to config authors” interpretation. Is that actually your interpretation? Do you think the master wording is clearly not advice to runtime authors (it's not clear to me)? It might be easier to talk about this if we talk over how SHOULD validation will work. Will this SHOULD be checked by runtime-tools' |
|
Closing as this section is marked as |
The mount-requirement was softened to a SHOULD in [1]. It's not clear
to me whether that SHOULD is directed at config authors ("you should
explicitly include mounts for these") or at runtimes ("you should
provide these even if the config doesn't ask for them"), but my
attempts to clarify that one way or the other were both rejected
[2,3]. The current runtime-tools and runC approach favors the
config-author direction [4], which is what I'd asked for in the
original thread post, so I'm tagging this obsolete.
[1]: opencontainers/runtime-spec#666
[2]: opencontainers/runtime-spec#679 (comment)
[3]: opencontainers/runtime-spec#678 (comment)
[4]: opencontainers/runtime-tools#24
3 participants
Users who need these mounts would have to explicitly set them up in their configuration (as runtime-tools continues to do) if they wanted to guarantee their presence. Users who don't need them can omit them from their configuration. I don't see how keeping a SHOULD-strength runtime requirement helps either of those workflows.
This is one of the possible approaches I'd floated in #666.