Zero is in development. Everything on this page is planned.

Specs and revisions

A spec is the plain-data description of a workload. A workload is something you deploy.

What a spec is

Specs are stored and sent as JSON: plain data. Users may write whatever their tools convert.

Zero has no templating language. Every default is written into the stored revision, so a plan shows it.

The API takes strict JSON. Duplicate keys are refused, and so are unknown fields. It is checked against one versioned JSON Schema. Errors name the field, the rule and the allowed values.

What a spec holds

A spec has three kinds of settings.

  1. What the workload is. Fixed for its life; changing it means a new workload. Its name, its kind (service, job, cron job or daemon), and whether it is stateful.
  2. What each pod runs: the revision. Changing any of it makes a new revision. It covers the containers (init, sidecar or main), and each container’s image, arguments, environment, user inside the image, limits, readiness, liveness, and stop signal and timeout. It also covers what the pod listens on and connects to, configuration files, scratch space, where volumes are mounted, the exact secret versions it uses, its restart policy, and how it reacts to a configuration change.
  3. Settings that change without a new revision. Replicas, spread by region and zone labels, how it is rolled out, and for a cron job its schedule and concurrency policy. Changing them restarts nothing, and a rollback does not bring old values back.

Zero assigns per-pod values. They are not written in the spec: each pod’s address, the host user it runs as, and which volume it gets.

Users write names, and Zero pins them at plan time. An image tag becomes its content digest and a secret name its current version. Both are written into the revision and shown in the plan.

What people define

A small, fixed set:

  • workloads;
  • secrets;
  • namespaces;
  • volumes, created from a workload’s spec, listed on their own, kept after the workload and deleted only explicitly;
  • node labels;
  • cross-cluster grants.

Roles are added when their model is designed. There are no custom kinds and no webhooks.

Revisions

A revision is an immutable, kept version of what a workload’s pods run.

To roll back, Zero creates a new revision from an earlier one’s content, and records which. A rollback is a new revision.

Data is never rolled back. Restoring a volume is a separate, recorded action that needs confirmation.

Changing a workload

Plan, then apply with the expected revision. A stale writer gets a conflict, not a silent overwrite. When two users change the same workload:

  1. Both plan against revision 7.
  2. The first apply makes revision 8.
  3. The second fails with a conflict naming revision 8, and must plan again.

Apply returns accepted. Whether the revision is applied and its pods ready is current state, seen separately.