Add warn about using the ignored --mount option

[henry3260]

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 --mount flag is ignored and can be removed

After:

First Case:

Second Case:

[k8s-ci-robot]

[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.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

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.

[minikube-bot]

Can one of the admins verify this patch?

[medyagh]

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

[henry3260]

@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!

[nirs]

Please do not merge --mount and mount-string in this PR. This is not related to the issue.

We have another issue for having the new --mount flags supporting multiple mounts. We don't want to introduce the new behavior supporting only one mount.

See #21178 (comment)

[henry3260]

Please do not merge --mount and mount-string in this PR. This is not related to the issue.

We have another issue for having the new --mount flags supporting multiple mounts. We don't want to introduce the new behavior supporting only one mount.

See #21178 (comment)

So do we still need to add a warning about using the --mount option in this pr?

[nirs]

Please do not merge --mount and mount-string in this PR. This is not related to the issue.
We have another issue for having the new --mount flags supporting multiple mounts. We don't want to introduce the new behavior supporting only one mount.
See #21178 (comment)

So do we still need to add a warning about using the --mount option in this pr?

If we introduce the new --mount flag we don't need a warning. But this PR is fine for now since we don't have the new --mount flag yet. I would remove the second commit and keep it as is in case we cannot finish the new --mount flag in time of the next release.