Resources
The LocalWorker custom resource, and the group backups will live in.
View as MarkdownAlpha, and not yet reconciled
LocalWorker exists as a CRD and its shape is deliberately minimal, the least that expresses
the intent. Nothing acts on it yet. Treat this page as the contract being designed rather
than an API to build against: v1alpha1 means the fields can change.
The group
| Group | Version | Kind | Scope |
|---|---|---|---|
worker.saved.sh | v1alpha1 | LocalWorker | Namespaced |
Namespaced, not cluster-scoped, on purpose. A worker holds one workspace's credential and reaches one set of sources, and that is a namespace's concern rather than a cluster's.
LocalWorker
apiVersion: worker.saved.sh/v1alpha1
kind: LocalWorker
metadata:
name: prod-worker-1
namespace: saved
spec:
image: ghcr.io/savedhq/local-worker:v0.1.0
configSecretRef: saved-worker-config| Field | Type | Notes |
|---|---|---|
spec.image | string | The worker image to run. Optional; the operator's default is a version it was built against |
spec.configSecretRef | string | Name of a Secret in the same namespace holding config.yaml |
status.conditions | []metav1.Condition | Standard condition list, with the status subresource enabled |
configSecretRef names a Secret, not a ConfigMap, and that is not a preference. The file
it points at carries the worker key and every source password. See
Configuration.
The name of the resource is a Kubernetes name. It is not the
worker ID, which is issued when you provision the worker and
is what the token in that Secret is bound to. One LocalWorker runs one provisioned worker,
because one credential means one process.
What the shape still needs
Two fields do not express everything the Deployment has to get right, and the gap is what the API has left to grow:
| Concern | Today | Where it is heading |
|---|---|---|
| Staging volume | Not expressible | A volume claim or size on the spec, because dumps need room for two copies |
| Node placement | Not expressible | Scheduling constraints, so an image lands on an architecture that can run it |
| Resources | Not expressible | Standard requests and limits |
| Whether it is polling | Not reported | A condition, read from our API rather than from the pod being up |
A running pod is not the same as a working worker: it can start cleanly, connect, and still serve zero backups because its config declares none. Whatever the status ends up carrying, it has to answer that, not just "the container did not crash".
Backups are not resources here
Not in this group and not in this version. Backups are declared through
sctl apply, the API or the dashboard, and the operator manages the
worker that runs them.
When backup resources arrive they get their own API group, backup.saved.sh. A worker is
a piece of running infrastructure and a backup is a policy about data. They have different
lifecycles, often different owners, and deleting one should very clearly not delete the other.