Custom volume options

[mausch]

#1834

[k8s-ci-robot]

Welcome @mausch!

It looks like this is your first PR to kubernetes-sigs/kind 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kind has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @mausch. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mausch
To complete the pull request process, please assign bentheelder
You can assign the PR to them by writing /assign @bentheelder in a comment when ready.

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

[BenTheElder]

/hold
We're definitely not binding ourselves to the docker CLI, in the future we may use the client library.

Also as I said these volumes are an internal detail subject to change.

[mausch]

We're definitely not binding ourselves to the docker CLI, in the future we may use the client library.

This would be a problem if the client library didn't support these options, right? But that doesn't seem to be the case I don't think? ContainerCreate can be passed a HostConfig which has a Mounts property which has the necessary VolumeOptions

Also as I said these volumes are an internal detail subject to change.

Well, this is explicitly an unsupported feature with a big warning... meaning you could just remove this feature altogether if there is some actual reason to do so 🙂

[BenTheElder]

if you look in the recent history this was actually N volumes covering specific subsets of /var, we've temporarily reverted to one volume.
how is this handled if we switch back to N volumes ...?

[mausch]

Good question! I see that happened in 8201cd9 .
If you had to switch back to N volumes you could just remove this environment variable altogether. I think it being explicitly unsupported gives you the right to do that at any moment and nobody has the right to complain about it ;-)
Tbh personally I'm mostly interested in /var/lib/containerd specifically, so if it were ever removed I'd maybe reimplement it (using a different env var name to avoid confusion!) and send another PR.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[mausch]

3+ months later and the project detail that caused the main criticism to this PR ("volumes are an internal detail subject to change") has not been changed.
Anyway personally speaking I no longer have a need for this change. I'm lucky that I could afford some 1TB drives so disk space is no longer an issue for me. However this isn't the case for most people in the world, and I really think we should try to make every effort to accommodate for people with less resources.
Anyway it's pretty clear that you're against a change like this and like I said I no longer need it so feel free to close it.

[aojea]

Anyway personally speaking I no longer have a need for this change. I'm lucky that I could afford some 1TB drives so disk space is no longer an issue for me. However this isn't the case for most people in the world, and I really think we should try to make every effort to accommodate for people with less resources.
Anyway it's pretty clear that you're against a change like this and like I said I no longer need it so feel free to close it.

I'm sad that you have that impression, is not common to need such amount of disk space, actually you were the first requesting it, lots of CIs are running thousands of KIND clusters daily in less that 14 Gb without any issues
https://docs.github.com/es/free-pro-team@latest/actions/reference/specifications-for-github-hosted-runners

/close

Ben explained the technical problems to maintain a solutions like yours in the long term, anyway, we hope to see you again
Thanks

[k8s-ci-robot]

@aojea: Closed this PR.

In response to this:

Anyway personally speaking I no longer have a need for this change. I'm lucky that I could afford some 1TB drives so disk space is no longer an issue for me. However this isn't the case for most people in the world, and I really think we should try to make every effort to accommodate for people with less resources.
Anyway it's pretty clear that you're against a change like this and like I said I no longer need it so feel free to close it.

I'm sad that you have that impression, is not common to need such amount of disk space, actually you were the first requesting it, lots of CIs are running thousands of KIND clusters daily in less that 14 Gb without any issues
https://docs.github.com/es/free-pro-team@latest/actions/reference/specifications-for-github-hosted-runners

/close

Ben explained the technical problems to maintain a solutions like yours in the long term, anyway, we hope to see you again
Thanks

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/test-infra repository.

[mausch]

@aojea Hi Antonio, I think there's been a misunderstanding here, just wanted to clarify things.
Firstly saying that I bought some 1TB drives doesn't mean that I actually need 1TB for KIND clusters specifically. But KIND is a tool for local development, and people use their computers for many different things not just KIND 🙂
So KIND competes for disk space with everything else on the machine e.g. databases, code repositories, build artifacts, and also non-development stuff.
In my case for example, a KIND volume having all the images I need is around 100GB. I don't think this is a particularly big cluster really. And for, say, a 250GB drive this is a nontrivial amount of disk space. Therefore the need to be flexible about where KIND puts its volume.

Anyway have a great 2021 🎉

[aojea]

lol, thanks for the clarification, I was totally getting it wrong :D
I have a similar issue, I have 2 partitions: one for the system and other for the home folder.
My solution is to move the docker data directory to the new partition using the -g option:
ExecStart =/usr/bin/dockerd -g /new/docker/root/dir -H fd://
Moving only kind data doesn't solve my problem