Summary
We should implement a configuration file mechanism that allows defining default flavors for pods that match certain metadata criteria. This would enable automatic flavor assignment based on pod labels, annotations, or other metadata without requiring explicit flavor specification in each pod spec.
Use Cases
- Automatically assign CPU/memory flavors based on workload type labels (e.g.,
workload-type: gpu-intensive)
- Set default flavors for specific namespaces or teams
- Apply resource constraints based on pod annotations
- Streamline resource allocation for common workload patterns
Proposed Implementation
The configuration could include:
- Metadata selectors (labels, annotations, namespace patterns)
- Corresponding default flavor specifications
- Priority/precedence rules when multiple selectors match
- Fallback behavior when no selectors match
Questions for Discussion
- What configuration format should we use? (YAML, JSON, TOML?)
- Where should the configuration file be located and how should it be loaded?
- Should this be a cluster-level or namespace-level configuration?
- How should we handle conflicts when multiple rules match the same pod?
- What metadata fields should be supported for matching (labels, annotations, namespace, etc.)?
Looking forward to feedback and suggestions on the design approach!
Summary
We should implement a configuration file mechanism that allows defining default flavors for pods that match certain metadata criteria. This would enable automatic flavor assignment based on pod labels, annotations, or other metadata without requiring explicit flavor specification in each pod spec.
Use Cases
workload-type: gpu-intensive)Proposed Implementation
The configuration could include:
Questions for Discussion
Looking forward to feedback and suggestions on the design approach!