Generate kustomizeconfig - #882
Open
mandre wants to merge 4 commits into
Open
Conversation
Annotate every KubernetesNameRef (and *KubernetesNameRef / []KubernetesNameRef) field across api/v1alpha1, plus CloudCredentialsReference.SecretName, with a new '+orc:kustomize:ref=<Kind>' marker naming the ORC Kind (or core Secret) the field references. Each target Kind was cross-checked against the corresponding controller's dependency.New(DeletionGuard)Dependency[...] declaration rather than guessed from the field name, to correctly handle cases a naming heuristic would miss (e.g. User.PasswordRef -> Secret). These markers are inert on their own: controller-gen ignores them and CRD output is unaffected (verified byte-identical config/crd/bases before/after). They will be consumed by a generator added in a follow-up commit to produce examples/components/kustomizeconfig/kustomizeconfig.yaml, replacing what was previously a manually maintained (and already stale) file.
mandre
force-pushed
the
generate-kustomizeconfig
branch
from
August 14, 2026 16:09
94a48a7 to
a1f884c
Compare
…PI markers
examples/components/kustomizeconfig/kustomizeconfig.yaml was previously
maintained by hand, per the (now removed) instruction in api-design.md. It
had drifted significantly out of date: cross-references for Domain, Service,
Group, Role, RoleAssignment, ApplicationCredential, User (including
PasswordRef), RouterInterface, ShareNetwork, VolumeType, ServerGroup, and
FloatingIP.FloatingSubnetRef were all missing, along with several
spec.import.filter variants of existing entries.
cmd/kustomizeconfig-generator instead derives the file automatically:
- it scans api/v1alpha1 for '+orc:kustomize:ref=<Kind>' marker comments
(added in the previous commit)
- for every registered ORC Kind, it walks the real struct layout of that
Kind's Spec via reflection to compute the JSON path of each marked
field (handling embedded/inlined structs, list traversal, and
RouterInterface's bespoke non-wrapped Spec)
- it groups the results by referenced Kind and emits a kustomize
Component nameReference configuration, with a generated-file header
Wired into 'make generate' as a new 'generate-kustomizeconfig' target,
covered by 'make verify-generated'.
Verified:
- the regenerated file is a strict superset of the old one (zero entries
lost, confirmed via a structural diff ignoring the old file's
inconsistent use of '[]' in one path)
- a real 'kustomize build' exercise (with namePrefix + this component)
correctly rewrites one of the newly-discovered references
(Server.bootVolume.volumeRef -> Volume), and does not rewrite a
deliberately-wrong path, confirming the generated paths are load-bearing
and correct rather than accidentally permissive
- 'make manifests' output (config/crd/bases) is unaffected
Also updates website/docs/development/api-design.md: the file is now
generated, not manually maintained; documents the new marker convention.
A missing '+orc:kustomize:ref=<Kind>' marker on a KubernetesNameRef field produces no diff in the generated kustomizeconfig.yaml (the generator simply never learns about the field), so 'make verify-generated' cannot catch it. Add a 'kustomizeref' analyzer to tools/orc-api-linter, following the existing 'noopenstackidref' pattern: it uses KAL's inspector/markers helpers to flag any KubernetesNameRef, *KubernetesNameRef, or []KubernetesNameRef field in api/v1alpha1 that lacks the marker (fields on Status structs are exempt). KAL's generic marker parser already understands the 'identifier=value' marker syntax used here, so no custom parsing was needed for the check itself - only for the separate generator, which still needs the JSON path context that KAL's per-field marker API doesn't provide. Registered in plugin.go and enabled via .golangci.yml, so it runs automatically as part of 'make lint' / 'make lint-fix' (golangci-lint rebuilds the custom binary via the existing golangci-kal target). Verified: analyzer unit test passes; a full 'make lint' run against the repo is clean; deliberately stripping a marker from router_types.go is correctly flagged at the right file:line by the rebuilt binary, and restoring it returns to clean.
mandre
force-pushed
the
generate-kustomizeconfig
branch
from
August 14, 2026 16:12
a1f884c to
b7cc589
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
examples/components/kustomizeconfig/kustomizeconfig.yamlwas hardly maintained and stalled, let's generate it instead.This requires new
+orc:kustomize:ref=<Kind>marker for each field referencing aKubernetesNameRef, which are then processed by the newkustomizeconfig-generatorcommand.Also add a new
kustomizereflint to spot missing markers.