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

Support volume type "hostPath" for volume mounting #15546

Open
vthurimella opened this issue Oct 2, 2024 · 7 comments
Open

Support volume type "hostPath" for volume mounting #15546

vthurimella opened this issue Oct 2, 2024 · 7 comments
Labels
area/API API objects and controllers kind/feature Well-understood/specified features, ready for coding.

Comments

@vthurimella
Copy link

In what area(s)?

/area API

Describe the feature

Adding support for the "hostPath" volume type in Knative Serving would allow users to mount directories from the host node's filesystem into their Knative service containers. This feature would enable access to local storage on the node, facilitating use cases such as accessing node-specific data or utilizing local caches, while maintaining the serverless benefits of Knative.

@vthurimella vthurimella added the kind/feature Well-understood/specified features, ready for coding. label Oct 2, 2024
@knative-prow knative-prow bot added the area/API API objects and controllers label Oct 2, 2024
@skonto
Copy link
Contributor

skonto commented Oct 3, 2024

Hi @vthurimella see comment here #13690 (comment).
Could you elaborate on this one? Is it an AI use case?

@vthurimella
Copy link
Author

My use case involves scientific workflows with AI components. We use Knative as a dynamic resource allocator across a shared cluster. Our Knative tasks generate files that must be written to the specific node where execution occurs. We have a robust system for file tracking and inter-node file transfer. Without hostPath support, we cannot efficiently manage data locality, which is crucial for our workflow performance (right now we have the task call a file service on the execution node that has a hostPath mounted). This feature would significantly help me integrate Knative into my application.

@skonto
Copy link
Contributor

skonto commented Oct 7, 2024

@dprotaso gentle ping, wdyth?

@vthurimella
Copy link
Author

Thank you for considering this feature request! I understand that adding hostPath support might not be feasible for the main project due to various constraints or design considerations.

If it's not possible to integrate this into Knative directly, I would appreciate any guidance on how I could modify the code myself to add the hostPath functionality for my specific use case and deploy it in my own application. This way, I could get the functionality I need for my installation without affecting the broader project.

Any information on which parts of the codebase I should focus on, or any architectural considerations I should keep in mind, would be extremely helpful. This would allow me to tailor the solution to my applications needs while maintaining the core benefits of Knative in my setup.

@rhuss
Copy link
Contributor

rhuss commented Oct 10, 2024

I think It makes sense to allow hostPath volumes, similar to support persistent volumes. This can be hidden behind a feature flag.

@vthurimella looks for kubernetes.podspec-persistent-volume-claim in the source, starting from pkg/apis/config/features.go and follow its usage trail. You should be able to implement hostPath in a similar way.

@vthurimella, just out of curiosity, what is the reason for choosing Knative as resource allocator ? Which feature of Knative serving is the most important to you ?

@skonto
Copy link
Contributor

skonto commented Oct 15, 2024

@vthurimella You can have hostPath access via a pvc however there are limitations see discussion here, this has been asked multiple times before. @dprotaso what is your take on this one? Should we stay opinionated here or add it as a feature as discussed before?

@dprotaso
Copy link
Member

I think it should be fine to add behind a feature flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/API API objects and controllers kind/feature Well-understood/specified features, ready for coding.
Projects
None yet
Development

No branches or pull requests

4 participants