GitHub user aicam edited a comment on the discussion: Proposal - Supporting
user-provided ML models in workflows
## Design Update
### Key Decisions
1. **Isolate mounts per computing unit (CU)**
* **Context:** We currently support read-only operations for model inference,
which allows using shared volumes and mounting points across CUs.
* **Decision:** We are opting for dedicated per-CU dataset mounts.
* **Rationale:** This architecture prepares the system for upcoming write
support (model training), ensuring two users working with the same base model
can modify their mounts independently without conflict.
2. **Offload mounting from CU pods to a privileged per-node DaemonSet**
* **Context:** GeeseFS requires elevated privileges to perform mounts. Granting
these directly to CU pods introduces security risks, as users can execute
arbitrary code that could compromise adjacent pods on the node.
* **Decision:** CU pods will no longer run with mount privileges. Instead, a
dedicated per-node DaemonSet handles the mounts and attaches the resulting
volumes to the CU pods.
3. **Defer dataset resolution and mounting from compile time to runtime**
* **Decision:** Shift mount execution entirely to runtime.
* **Rationale:** Mounts are only required while a workflow is actively
executing so we do not want to perform mounting in compilation.
4. **Integrate model selection into the operator property panel**
* **Decision:** Use a specialized UI parameter kind built on @carloea2's
implementation (#5912) rather than introducing a parallel selection mechanism:
```python
model_dir = self.UiParameter("iris_classifier", UiParameterType.MODELS).value
```
* **Details:** The parameter resolves directly to the local directory where the
specific model version is mounted.
5. **Provide contextual sample code based on model and storage types**
* **Decision:** Auto-generate tailored Python UDF snippets based on the
selected model type and storage backing to accelerate user implementation.
---
### Under Research
*Next area of focus—design still in progress:*
* **Hardware Constraints (GPU & VRAM):** CUs currently enforce GPU allocation
limits. We are defining model-side metadata requirements and validation checks
to prevent GPU-dependent models from running on unallocated CUs.
* **OS-Level Portability:** Investigating how tightly coupled trained models
are to their original host OS environment and defining cross-platform execution
boundaries.
GitHub link:
https://github.com/apache/texera/discussions/6616#discussioncomment-17909726
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
