Skip to content

docs: design proposal for deterministic generation of identity, references, fuzzers and controllers - #13487

Draft
ldanielmadariaga wants to merge 2 commits into
GoogleCloudPlatform:masterfrom
ldanielmadariaga:kcc-bg-controllers-design
Draft

ldanielmadariaga wants to merge 2 commits into
GoogleCloudPlatform:masterfrom
ldanielmadariaga:kcc-bg-controllers-design

Conversation

@ldanielmadariaga

Copy link
Copy Markdown
Collaborator

Design proposal for extending deterministic generation beyond types (Step 1, #13394) to identity and reference files, fuzzers and archetype-A controllers for greenfield resources.

Part of #13411.

Doc: docs/designs/deterministic-generation-identity-and-controllers.md

Highlights:

  • Fit per artifact. Identity, references, archetype-A controllers and fuzzers are strong fits. Fixtures fit only as skeletons. Compute-style and irregular APIs, and all brownfield work, stay in the agent flow.
  • Delivery is a staged ratchet: types → identity/reference → fuzzer → controller, one stage per PR. Each stage's kinds are listed in generate.sh, and a kind advances only when its blocking judgement-queue entries are cleared. Includes PR-size estimates per stage, based on 85 merged greenfield PRs, and compares this against generating everything at once.
  • Layout. Generated code lives in *.generated.go, and hand-written functions win, as in generate-mapper.
  • Phases 0–2 (identity, fuzzer, archetype-A controller). Each has an offline regeneration gate over existing kinds and a pilot gate on new kinds.
  • Known shortcoming, flagged but not fixed: controllers return (true, nil) from Delete on NOT_FOUND to avoid a reconciliation loop. The Adapter interface documents (false, nil), and the caller discards the bool.

Open items for maintainers are in section 12: unset-field semantics, blocking beta on open queue entries, the Delete return value, skip-listed services, and where stage PRs split.

NONE
…ences, fuzzers and controllers

Follow-up to the Step 1 design (GoogleCloudPlatform#13394), tracked in GoogleCloudPlatform#13411.

Proposes applying the Step 1 principle ("emit what the proto states,
record what it doesn't") to the greenfield artifacts that come after
types: identity and reference files, fuzzers, and archetype-A
controllers, with skeleton fixtures.

Delivery is a staged ratchet (types -> identity/reference -> fuzzer ->
controller), one stage per PR. Each stage's kinds are listed in
generate.sh, and a kind advances only when a PR advances it and its
blocking judgement-queue entries are cleared.

The doc covers the fit verdict per artifact, the decisions taken so
far, PR-size estimates per stage, the design, the implementation
phases with their offline and pilot gates, and the blockers and
pitfalls. It flags, without fixing, the mismatch between the documented
Adapter.Delete contract and the (true, nil) NOT_FOUND convention.
@google-oss-prow

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from ldanielmadariaga. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Start with the work that doesn't depend on the open Step 1 PRs: the API model (PR 0.1) and the deterministic fuzzer (phase 1) in parallel, then archetype-A controllers. Identity and reference generation (PRs 0.2-0.7) follows GoogleCloudPlatform#13401. The order of stages each kind goes through is unchanged; existing kinds already have hand-written identities.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment