Skip to content

json-schemas for custom resource authoring#5

Open
solsson wants to merge 4 commits into
mainfrom
cr-schemas
Open

json-schemas for custom resource authoring#5
solsson wants to merge 4 commits into
mainfrom
cr-schemas

Conversation

@solsson

@solsson solsson commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

No description provided.

Yolean k8s-qa (buckety maintainer) and others added 4 commits July 22, 2026 09:01
Editor validation for Buckety maintainers, the
kubernetes-json-schema pattern: schema/ carries generated
draft-07 schemas for the full CR document, referenced via
yaml-language-server annotations. The suffix is a
specialize/generalize ladder walked by switching the URL:

  buckety.schema.json               any driver, parameters open
  buckety-objectstore.schema.json   family-common only (portable CR)
  buckety-gcs / -s3 / -kadm         full per-driver parameters
  bucketyaccess.schema.json

The family rung is the interesting one: a yaml annotated with it
provably stays provisionable on any bucket backend, because the
schema rejects driver-specific parameters at edit time. Its
parameter definitions ship as
pkg/drivers/objectstore/schema/v0.1/parameters.schema.json,
consistent with the per-driver layout.

scripts/gen-cr-schemas composes the outputs from the CRD yamls
(shape, descriptions, CEL stripped) and the parameters schemas -
nothing is hand-written twice, and CI asserts schema/ is
committed. Verified against all 66 example CR documents (the
only rejections are webhook-fallback-validation's deliberately
invalid fixtures) plus negative cases for unknown, gcs-only and
malformed values. Editor schemas are advisory; admission remains
the authority and validates against the backend the CR names.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Driver-suffixed for scenario CRs, buckety-objectstore for the
portable-blobs-cr pair (both sides get the identical line, so
the byte-identity assert still holds), bucketyaccess for access
files, and the generic buckety schema for
webhook-fallback-validation's deliberately invalid fixtures so
editors do not flag them red. Fulfils the SPEC Schemas section's
long-standing promise that example YAMLs carry the annotations.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The CI schema/ regen guard covers generated output vs sources,
but the sources themselves - each driver's parameters.schema.json
- were hand-synced with ValidateParameters, so a parameter added
in code but not published would regenerate cleanly and ship
wrong. TestParametersSchemaInSync closes that link per driver:
every schema property must be code-known (probe never returns
'unknown parameter'), and every key the unknown-parameter error
advertises must be in the schema. The gcs and s3 twins also
enforce SPEC Driver families rule 1 at the schema level: every
object-store family-common parameter must exist in the driver's
own schema. kadm additionally pins the config.* pass-through to
patternProperties. Mutation-checked: dropping versioning from the
gcs schema fails the test.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The user-facing schema name follows the vocabulary consumers
already use (blobs namespaces, site-userdata-blobs), not the
internal family package name. pkg/drivers/objectstore keeps the
SPEC term; schema/README.md documents the bridge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant