Conversation
|
Hi @yunnian , thanks for the contribution and for sharing your use case! The dynamic per-session mounting scenario you described is exactly the kind of workflow we want to support. We've been working on a formal volume support proposal that treats volumes as first-class citizens in the Lifecycle API. Our design takes a slightly different approach - we unify volume definition and mount configuration into a single structure: volumes:
- name: user-session-data
pvc:
claimName: user-session-data
mountPath: /workspace
subPath: uid-1-sessionId-1
accessMode: RWThis keeps the API simpler for the common case (one volume = one mount point), while still supporting subPath for your per-session isolation needs. Would you be interested in collaborating on pvc backend support? We'd love your input on the implementation, especially since you have a concrete production scenario. Feel free to check out the OSEP and let us know if the proposed design covers your needs! |
|
@hittyt |
Summary
Previously I only supported custom mounts via batchsandbox-template.yaml, which does not satisfy the need to dynamically mount per‑session data directories. Each user/agent session can generate files; when the container is destroyed and the session resumes, those files must be re-mounted and restored. Therefore the mount path needs to accept dynamic identifiers (e.g., uid-sessionid) so it can map back to the correct persisted data. This change adds request-level volumes and mounts to support that workflow.
Example (request-level mounts/volumes):
中文解释:
之前我做了在batchsandbox-template.yaml模板中自定义mount相关的处理,但无法满足动态加载数据目录的情况。
比如用户和智能体的每次会话都会产生一些数据文件,容器销毁后下次再接着对话时要把数据文件进行重新挂载恢复,所以挂载的文件目录应该支持传入类似uid-sessionid这种信息以便能够映射和恢复之前的数据文件,所以才有了这次的提交,请审阅
现在能够支持接口级别的自定义 :
Testing
Breaking Changes
Checklist