Proposal: Adding mount options to functions.

[alshabib]

• Brief summary including motivation/context

The proposed change would allow functions to mount volumes and other directories through the normal docker configuration. This would allow a function to process relatively large amounts of data without having to pass it through http/stdin.

Any design changes

Add docker mount struct to the CreateFunctionRequest struct and passing it along in the create function handler

Pros + Cons

Pros:

• Functions will be able to have volumes.

Cons:

• Volumes should be available on all nodes running functions (but that is rather expected)

Effort required Little, it's a two line change.

[Docteur-RS]

I also really wish that volumes were exposed.... We use Openfaas to download and uncompress files before uploading them on S3. But the files are too big to be downloaded on the Kubernetes node itself. We need a volume !
To fix this we had to make our own deployments matching the ones created by openfaas and add the volumes ourselves. It's working but we can't use coldstart anymore... Also the volumes are always up even if the fonctions are not in use.

[aslanpour]

I also have a use case that requires applying --volume to the container to allow USB access for a container to connect to the TPU device that is attached to my Pi. I am not sure if there is a way other than --volume to achieve this.

[alexellis]

I own a Coral edge TPU, so find out exactly what is required and copy and paste the pod spec here. We will not be enabling privileged mode for functions, which I saw you request a day or two ago. I sent you some examples on the issue with devices etc.

Did you try them?

[aslanpour]

Thank you, Alex. I got your point. I am going to document how I gave functions TPU, GPU, etc access and will share it here later.

[Docteur-RS]

Finaly we searched for another technlogy... We really need big volumes attached to our functions.

We tried Fission. It does provide a new volume for each new function but unfortunatly it doesn't scale back to 0. This means that we always have one pod with a huge mounted volume. A pod that does nothing... Just waiting there to serve a request. So tons of money lost doing nothing really.

We ended up using Gitfaas.... It creates one pod per request and you have a complete access to the deployment's specs. So we have a clean volume created each time.
It also allows to define the volume size at startup. So no money loss over oversized volumes. And it scales back to 0. No money lost here either.

I know that Openfaas has chosen to fork processes to gain speed. But as leaders on this subject I don't like it when they force people into thinking that FAAS must always be short lived and fast. It's just the road they chose to go down.
Volumes support is simply impossible to achieve in openfaas due to it's technical implementation. And I'm okay with this.

Each piece of tech has its force and weakness.