Open leonpawelzik opened 1 week ago
Nice!
Two high-level thoughts that came to my mind:
- I also like the abstraction of the queue name, although we have to do this watertight - there should not be a project without a cluster queue (or it should be marked as unable to submit workloads), and the link between projects and queue(s) needs to be tracked somewhere. Having the user debug project<->queue association bugs is probably the worst case DX-wise.
That is very true. Besides having the backend check the queue association whenever submitting a workload, I could see this as a good use case for Kubernetes finalizers, which could prevent queues from being deleted while they are referenced by a project.
Define Architecture and Basic Concepts for Project Mechanism
We need to take some time to define the architecture and basic concepts for a "project" mechanism within
jobq
. This project mechanism should allow jobs/workloads to be part of a project, team, or something similar.Goals:
jobq
to understand current implementation and how a project mechanism would fit.High-level design
Projects serve as a grouping mechanism (think: namespace) for workloads in the system.
Goals
As such, they serve the following goals:
Non-Goals
Explicit non-goals include:
Server-side changes
POST /projects
to create a new project)Client-side changes
Modify
SchedulingOptions
data model to remove manual Kueue association (i.e., thequeue_name
attribute).Entity-Relationship model
The following diagram illustrates the relationship between projects and other entities.
Open Questions