Allow mounting host host directories to kind nodes

[mitar]

It seems there is no way to request some host volumes to be mounted inside the kind container. So then pods cannot access those host volumes through hostPath. This is useful for us to bring testing data in.

[BenTheElder]

definitely, this relates to #28, mostly we need to think about how best to expose this. cc @munnerz

[mitar]

Is there any workaround for now? Any way to hook into argument list being passed when creating a control plane container?

[BenTheElder]

There is not, that sort of thing would create some interesting stability guarantees, eg at some point I think we may want to move to a docker client library instead of execing docker at which point any option to hook it with arbitrary args would no longer work.

I'd like to avoid breaking changes going forward as much as possible, so I'd like to think about how exactly we expose options like this. I think we can provide config for host path mounts specifically, and think a bit about how that relates to multi-node (which is forthcoming...)

The closest work around right now is patching kind itself...

[BenTheElder]

/priority backlog
I definitely intend to support this

[BenTheElder]

/assign
/lifecycle active
I'll file a PR after #77, also going to clean up the node lifecycle stuff a bit along with it.

[BenTheElder]

we'll want to consider customizations like this when we add topology / multi-node @fabriziopandini

I've hesitated back off on PRing this because while the change is fairly simple, the config should be forward thinking with respect to multi-node. 🤔

[fabriziopandini]

+1 noted

[BenTheElder]

[Using this to track volumes as well IE #246]

Multi-node is pretty solidly landed, experimenting with this again currently. This is actually active again, apologies for the delay.

[BenTheElder]

[apologies, turns out the config format for this is tricky and very coupled to docker ... stay tuned ...]

The docker client library is imo, even worse for this. Evaluating options to make this better than literally plumbing through extra user provided flags to the container creation.

[mitar]

Looking forward to this. For now we have to use a fork to pass those arguments through.

[BenTheElder]

I did some more looking yesterday, what we can do to start is mimic the format used by Kubernetes CRI to describe container mounts, which is of course quite reasonable.
/priority important-soon

[BenTheElder]

We discussed this in today's meeting, triaging to the next minor release ideally, and following Kubernetes CRI for how to describe this.

[BenTheElder]

Fixed in #313

Quick example usage here: #313 (comment)

Will document more as we finish fleshing it out.

[mitar]

Awesome! Thanks!

[BenTheElder]

Sorry for the delay again, this has worked for a while but there was some debate about the best way to borrow from the upstream CRI concepts (vendor vs copy etc.).. we came to agreement in today's meeting so it's in now 😅

[mitar]

No worries. I have been using a fork in meantime. This is now the last thing which required a fork for me. Which is great. I will test this out soon.

[BenTheElder]

Great!
I think we will need some UX improvements (relative paths?) but it's a start 😅

[0xmichalis]

Quick example usage here: #313 (comment)

I guess for most testing environments this is not going to be a problem (because AFAIK most envs care about a 1 master + 1 worker setup) but fwiw this is not going to work with multiple workers, right?