Skip to content
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

Allow mounting host host directories to kind nodes #62

Closed
mitar opened this issue Oct 9, 2018 · 18 comments
Closed

Allow mounting host host directories to kind nodes #62

mitar opened this issue Oct 9, 2018 · 18 comments

Comments

@mitar
Copy link
Contributor

@mitar mitar commented Oct 9, 2018

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
Copy link
Member

@BenTheElder BenTheElder commented Oct 9, 2018

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

@mitar
Copy link
Contributor Author

@mitar mitar commented Oct 9, 2018

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

@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Oct 9, 2018

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
Copy link
Member

@BenTheElder BenTheElder commented Oct 24, 2018

/priority backlog
I definitely intend to support this

@BenTheElder BenTheElder changed the title Accessing host volumes through kind Allow mounting host host directories to kind nodes Oct 26, 2018
@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Oct 26, 2018

/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
Copy link
Member

@BenTheElder BenTheElder commented Nov 21, 2018

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
Copy link
Member

@fabriziopandini fabriziopandini commented Nov 23, 2018

+1 noted

@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Feb 4, 2019

[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 BenTheElder removed this from the 2019 goals milestone Feb 4, 2019
@BenTheElder BenTheElder added this to the 1.0 milestone Feb 4, 2019
@BenTheElder BenTheElder added this to To do in 0.2 via automation Feb 4, 2019
@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Feb 6, 2019

[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
Copy link
Contributor Author

@mitar mitar commented Feb 7, 2019

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

@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Feb 8, 2019

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 BenTheElder removed this from the 1.0 milestone Feb 11, 2019
@BenTheElder BenTheElder added this to the 0.2 milestone Feb 11, 2019
@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Feb 11, 2019

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

@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Feb 19, 2019

Fixed in #313

Quick example usage here: #313 (comment)

Will document more as we finish fleshing it out.

0.2 automation moved this from To do to Done Feb 19, 2019
@mitar
Copy link
Contributor Author

@mitar mitar commented Feb 19, 2019

Awesome! Thanks!

@BenTheElder
Copy link
Member

@BenTheElder BenTheElder commented Feb 19, 2019

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
Copy link
Contributor Author

@mitar mitar commented Feb 19, 2019

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
Copy link
Member

@BenTheElder BenTheElder commented Feb 19, 2019

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

@kargakis
Copy link

@kargakis kargakis commented Feb 22, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
0.2
  
Done
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants