-
Notifications
You must be signed in to change notification settings - Fork 5.1k
Add warn about using the ignored --mount option #21741
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
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: henry3260
Once this PR has been reviewed and has the lgtm label, please assign comradeprogrammer for approval. For more information see the Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Hi @henry3260. Thanks for your PR.
I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
Can one of the admins verify this patch?
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 think instead of warnining, we should merge the
--mount
and
--mount-string flags into
--mount
and if ppl enter --mount true --mount-string /blahblah:/blahblah
we could still support it
with good unit testing we could just transition into "--mount " flag without breaking old syntax users
@nirs Thanks for reviewing! I’d like to ask for your guidance here.
I noticed an unexpected behavior:
When running:
./out/minikube start --mount="/home/henry:/mnt" --alsologtostderr --v=2 2>&1 | grep -i mount
the boolean/string parsing logic in start.go is triggered correctly.
However, the same flag condition inside start_flags.go (where interpretMountFlag(cmd) is called) does not execute.
Both conditions check cmd.Flags().Changed(createMount), but they produce different results at runtime.
Do you have any hints why the flag state behaves differently between these two code paths? I suspect the config is initialized too early, but I’m not fully sure where the state gets overridden. Any suggestions or directions would be appreciated!
fix #21291
We have 2 cases:
--mount: user expects to have HOME mounted in the guest. This does nothing and we want to show an example how to mount a specific directory in the guest.--mount --mount-string ...: warn that the--mountflag is ignored and can be removedAfter:
First Case:
image
Second Case:
image