Repository navigation
Make sandbox_class in workers immutable - #1257
Julian Gutierrez Oschmann (juli4n) merged 1 commit into
Conversation
What does this buy us? I ask because I'm looking at having workers self register which classes they can handle, which may vary (thinking forward a bit, but imagine if gvisor + uVM were one binary) |
This prevents unsupported modifications to the worker resource, preventing accidental updates that could break the system. If we want to allow workers to self register their sandbox class, I would think we would expand the WorkerService to handle sandbox class as well as capacity. This does not require the sandbox class in the UpdateWorker API to be mutable. |
Changing the sandbox_class requires creating a new worker, you can't change the sandbox_class of a running worker.
eae1aa4 to
88abef2
Compare
| changed = true | ||
| } | ||
| if w.GetSandboxClass() != string(pool.Spec.SandboxClass) { | ||
| // Expected mid-rollout: sandboxClass drives the worker pod's shape, so |
There was a problem hiding this comment.
I wonder if the WorkerPool controller should add the sandbox class to the Pod as an annotation (in buildDeploymentApplyConfig). That way, the Pod is self-descriptive and this whole race condition goes away.
Not part of this PR for sure.
44f4000
into
agent-substrate:main
Changing the sandbox_class requires creating a new worker, you can't change the sandbox_class of a running worker.