-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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.
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
Add equivalent of bind-recursive option to the Mount type class #3242
base: main
Are you sure you want to change the base?
Conversation
The branch is intentionally one commit behind the current |
docker/types/services.py
Outdated
@@ -235,6 +235,9 @@ class Mount(dict): | |||
``default```, ``consistent``, ``cached``, ``delegated``. | |||
propagation (string): A propagation mode with the value ``[r]private``, | |||
``[r]shared``, or ``[r]slave``. Only valid for the ``bind`` type. | |||
recursive (string): Bind mount recursive mode, one of ``enabled``, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
recursive (string): Bind mount recursive mode, one of ``enabled``, | |
recursive (string): Bind mount recursive mode, one of ``enabled``, |
raise errors.InvalidArgument( | ||
'Invalid recursive bind option, must be one of ' | ||
'"enabled", "disabled", "writable", or "readonly".' | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
The CLI also does some validation, not sure if we should do those too? 🤔
https://github.com/docker/cli/blob/v25.0.5/opts/mount.go#L183-L196
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure - some other options are also validated loosely here or not at all, so I'm sticking with that, only added this InvalidArgument
error for unknown options since we need to enumerate the possible values to map them to mount config options anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(disclaimer: I'm a maintainer for the docker CLI, but I'm not very good at Python, or very familiar with existing code in this repository for that matter).
In general (in docker/cli), we try to keep client-side validation "light" where possible, so that we can defer to the API as source of truth (also accounting for situations where only the daemon can fully validate, as well as preventing the CLI from disallowing options that may be supported at some point in future).
That said, for some cases we do some validation on the client side, either where we are sure (or "very confident") certain validation would never change, or for situations where performing the API request (when invalid) would be much more "heavyweight" than a local check, and where a client-side validation can provide a better experience to the user (e.g. producing a more specific error message).
All of the above out of the way, it would be good to verify the behavior when using one of those invalid combinations; the API should validate those, but it'd be good to check if it does, and if so, if the error-message is useful enough to the user to resolve the problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks for the insights, @thaJeztah. For me the only concern is this:
we are sure (or "very confident") certain validation would never change
I think it's the case for the referred checks done in CLI for the bind options, and the check in Python will have minimal overhead, so I'm fine with adding it here. Let's see what others have to say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to emphasize; If the API already responds with a reasonable error, then I'm (personally) perfectly fine with keeping it light.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I mean trade-offs: Validate more means more maintenance. But I'd rather prefer checks in this library than on users side 😅. I guess in our use case it doesn't matter all that much as we won't have this options user controlled, but just use sensible value/combinations. But I agree, it mostly depends on if/how errors are raised if invalid combinations hit the API directly.
On the other hand, since we don't have such validation so far, probably better to skip them too for consistency. 🤷♂️
With the recursive mount behavior change in Docker 25, it is not possible to make recursive mounts writable with the current API. Add the `recursive` option which is equivalent of bind-recursive in CLI. This also allows for setting the mount to be non-recursive (added earlier in API v1.41). Signed-off-by: Jan Čermák <[email protected]>
ee5a45d
to
07e35d3
Compare
With the recursive mount behavior change in Docker 25, it is not possible to make recursive mounts writable with the current API. Add the
recursive
option which is equivalent of bind-recursive in CLI. This also allows for setting the mount to be non-recursive (added earlier in API v1.41).Ugly workarounds like this are needed to adjust the behavior now, it will be nice to have this in the standard Python API.
Related: