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

mount the dedicated storage for each function #1408

Merged
merged 6 commits into from
Jul 26, 2024

Conversation

akihikokuroda
Copy link
Collaborator

Summary

Mount the dedicated storage for each function

Details and comments

The dedicated storage area is mounted at /function_data for the function provider. When the function doesn't have the associated provider, the storage mounted at /function_date is the same storage as /data.

@akihikokuroda
Copy link
Collaborator Author

Based on the current function design, when the Function is provided in the custom image, the code running in the ray nodes is the function code only. The user code doesn't run in the ray nodes so it can not access to the directory.

@Tansito Tansito marked this pull request as draft July 15, 2024 21:16
@akihikokuroda akihikokuroda marked this pull request as ready for review July 18, 2024 19:29
Comment on lines +358 to +360
- mountPath: /function_data
name: user-storage
subPath: {{`{{ function_data }}`}}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to mount this with any kind of restricted permissions? In theory, and correct me if I'm wrong here, whoever is running the function (user or provider) would be able to access this location via the container...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that with the current custom image function design, the only the code in the custom image is executed in the Ray node. No user code is sent or executed in the Ray node so only the function code read/write to this directory.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Users could in theory find a way around that restriction (if we misimplement something, CVS / exploits, etc.) so it's a risk, we'd just need to determine if it's an acceptable one

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we just add the path when a function is from a provider? That could solve part of the problem. And correct me if I'm wrong here @akihikokuroda but all the providers will write here so they could potentially see files from other providers with this approach. What is the problem to use the name of provider as sub-path instead of function_data?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My idea was that in that way we could attach the specific provider path only when it's a function from the specific provider (but I don't know if there are limitations in this approach).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought function-data was the provider space and data was for users ? since users would already go to data on their own functions

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the provider, it may be useful to have both while they develop the function because it is the same environment when the function is executed by the user.

Copy link
Member

@Tansito Tansito Jul 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought function-data was the provider space and data was for users ?

yep

since users would already go to data on their own functions

basically that's my comment, for functions that come from the user we are adding /function_data too. It's true that /function_data and /data are going to point to user.username path so not a bid deal but probably we can just avoid add /function_data for user functions.

BTW, another answer that I would understand is: "well, we don't overcomplicate more the template this way" and I would agree. Yep.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Django template in helm template is very tricky :-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hahaha I agree, I agree. I'm just reviewing the rest of the code, Aki and I will update my review 👍

@akihikokuroda
Copy link
Collaborator Author

@Tansito @psschwei I would like to complete this. What are the remaining concern? Thanks!

@psschwei
Copy link
Collaborator

Good from my side. Just need to resolve David's question about mounting /data

@Tansito
Copy link
Member

Tansito commented Jul 26, 2024

Sorry, I didn't read your answers yesterday.

@akihikokuroda
Copy link
Collaborator Author

The Function can write something that it wants to share with the user. I'm planing providing the loggers to the function one for private logs and the other for the shared with the user. The later log is written in the file in /data directory.

Copy link
Member

@Tansito Tansito left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logic LGTM Aki, thank you! BTW something I would like to improve in the near future are logs. We need to introduce more logs in general if not debug this in case of an error would be a nightmare 😅

@akihikokuroda akihikokuroda merged commit 843ee36 into Qiskit:main Jul 26, 2024
14 checks passed
@akihikokuroda akihikokuroda deleted the functionstorage branch July 26, 2024 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants