gentype: add a create-only client for non-object request/response types - #646
Merged
Conversation
Some aggregated-apiserver API types are pure request/response "action" payloads with no real persisted identity -- e.g. an editor-model resolver or a token-exchange endpoint that only ever accepts POST -- and so deliberately carry no metav1.ObjectMeta. k8s.io/client-go/gentype.Client[T] (which every client-gen-generated typed client has been built on since kubernetes/kubernetes#121439) requires its type parameter to satisfy metav1.Object, even when the generated client only exposes Create: Client[T].Create never actually calls any metav1.Object method on T -- only Update/Get/Delete do (obj.GetName(), to build the REST path) -- but the constraint is declared on the whole generic struct rather than per-method, so every type needs it regardless of which verbs its generated client actually has. This adds a parallel Client[T runtime.Object]/FakeClient[T runtime.Object] pair, matching k8s.io/client-go/gentype's shape (NewClient, Option, PrefersProtobuf, GetClient, GetNamespace, Create) but scoped to exactly what a create-only client needs, for use by kmodules/code-generator's client-gen when it detects a +genclient:onlyVerbs=create type with no ObjectMeta (see the matching client-gen patch). Signed-off-by: Tamal Saha <tamal@appscode.com>
![kodiakhq[bot]](https://avatars.githubusercontent.com/in/29196?s=60&v=4){kind=small}
tamalsaha
added a commit
to kubedb/apimachinery
that referenced
this pull request
Sep 2, 2026
…Meta Reverses the +genclient removal from the previous commit. That was a reasonable fix at the time (nothing calls the generated client, and a metav1.Object-requiring client is architecturally wrong for a pure request/response payload type), but it's no longer the best available option: kmodules/code-generator's client-gen now detects exactly this shape -- a +genclient:onlyVerbs=create type with no metav1.ObjectMeta -- and builds its client on kmodules.xyz/client-go/gentype's create-only Client[T runtime.Object] instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object. See that package's doc comment for the full rationale (Client[T].Create never actually calls any metav1.Object method on T; the constraint is just declared on the whole generic struct rather than per-method). This keeps the generated DatabaseSummaries() client working for any future caller without DatabaseSummary claiming a real Kubernetes identity it doesn't have -- no ObjectMeta, no CRD (still no +kubebuilder:object:root=true/+kubebuilder:resource markers, since controller-gen needs ObjectMeta to treat a type as a CRD root and ui-server serves this type via API aggregation, not a CRD). Bumps kmodules.xyz/client-go to pick up the new gentype subpackage (kmodules/client-go#646). Verified with make check-license, lint, build, unit-tests, and a full make gen (update-codegen, manifests, openapi) against the gengo-builder release-1.34 image (rebuilt locally with the matching client-gen patch, not yet published) -- zero apis/ CRD manifest diff, matching the fact that this type still has no CRD. Signed-off-by: Tamal Saha <tamal@appscode.com>
tamalsaha
added a commit
to kmodules/resource-metadata
that referenced
this pull request
Sep 2, 2026
…ease-1.34 Mirrors the same migration already done for kubedb.dev/apimachinery, kubevault.dev/apimachinery, voyagermesh.dev/apimachinery and kubeops.dev/petset: replaces the old generate-groups.sh based clientset target with update-codegen.sh, a generic script bundled into CODE_GENERATOR_IMAGE (see appscodelabs/gengo-builder's scripts/update-codegen.sh for the full env-var interface). GENERATORS is scoped to deepcopy+client only (no lister/informer), matching what the old generate-groups.sh call here actually generated. apis/shared has no client of its own (it's not part of API_GROUPS) but still needs deepcopy, hence EXTRA_DEEPCOPY_PKGS. openapi-shared/ openapi-% are updated for the new openapi-gen CLI (positional packages + --output-dir/--output-pkg/--output-file instead of --input-dirs/ --output-package); their --input-dirs list also drops go.bytebuilders.dev/catalog/api/v1alpha1, an unresolvable reference (no such package is in go.mod/vendor, or imported anywhere under apis/ -- only an unrelated cmd/import-crds tool references a same-named but different package) that the old openapi-gen silently tolerated but the new one hard-fails on. 12 +genclient types across editor/identity/meta (EditorModel, AuditTokenRequest, InboxTokenRequest, ChartPresetQuery, ClusterStatus, Render, RenderDashboard, RenderMenu, RenderRawGraph, ResourceGraph, ResourceManifests, ResourceQuery) are request/response payloads with no metav1.ObjectMeta -- the new gentype-based client-gen would otherwise require adding it (or dropping +genclient) for all 12, same as kubedb.dev/apimachinery's DatabaseSummary needed. Instead, this bumps kmodules.xyz/client-go to pick up its new create-only gentype.Client[T runtime.Object] (kmodules/client-go#646) and the matching kmodules/code-generator client-gen patch that detects this shape (+genclient:onlyVerbs=create with no ObjectMeta) and builds the client on it instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object -- so none of apis/ needed any changes at all, for any of the 12 types. Verified with make check-license, lint, build, and a full make gen (update-codegen, manifests, openapi) against the real gengo-builder release-1.34 image -- zero apis/ diff, and the only crds/ diff is the newer controller-gen (ac-0.19.0, up from whatever this repo's release-1.32-era CODE_GENERATOR_IMAGE shipped) dropping the null creationTimestamp field CRD YAML used to carry. make unit-tests passes except hub.TestRegister, which needs a live cluster (KUBERNETES_MASTER) that this repo's CI provisions via kind but wasn't available to verify locally -- not something this migration touches. Signed-off-by: Tamal Saha <tamal@appscode.com>
tamalsaha
added a commit
to kubedb/apimachinery
that referenced
this pull request
Sep 2, 2026
…Meta Reverses the +genclient removal from the previous commit. That was a reasonable fix at the time (nothing calls the generated client, and a metav1.Object-requiring client is architecturally wrong for a pure request/response payload type), but it's no longer the best available option: kmodules/code-generator's client-gen now detects exactly this shape -- a +genclient:onlyVerbs=create type with no metav1.ObjectMeta -- and builds its client on kmodules.xyz/client-go/gentype's create-only Client[T runtime.Object] instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object. See that package's doc comment for the full rationale (Client[T].Create never actually calls any metav1.Object method on T; the constraint is just declared on the whole generic struct rather than per-method). This keeps the generated DatabaseSummaries() client working for any future caller without DatabaseSummary claiming a real Kubernetes identity it doesn't have -- no ObjectMeta, no CRD (still no +kubebuilder:object:root=true/+kubebuilder:resource markers, since controller-gen needs ObjectMeta to treat a type as a CRD root and ui-server serves this type via API aggregation, not a CRD). Bumps kmodules.xyz/client-go to pick up the new gentype subpackage (kmodules/client-go#646). Verified with make check-license, lint, build, unit-tests, and a full make gen (update-codegen, manifests, openapi) against the gengo-builder release-1.34 image (rebuilt locally with the matching client-gen patch, not yet published) -- zero apis/ CRD manifest diff, matching the fact that this type still has no CRD. Signed-off-by: Tamal Saha <tamal@appscode.com>
tamalsaha
added a commit
to kmodules/resource-metadata
that referenced
this pull request
Sep 2, 2026
…ease-1.34 Mirrors the same migration already done for kubedb.dev/apimachinery, kubevault.dev/apimachinery, voyagermesh.dev/apimachinery and kubeops.dev/petset: replaces the old generate-groups.sh based clientset target with update-codegen.sh, a generic script bundled into CODE_GENERATOR_IMAGE (see appscodelabs/gengo-builder's scripts/update-codegen.sh for the full env-var interface). GENERATORS is scoped to deepcopy+client only (no lister/informer), matching what the old generate-groups.sh call here actually generated. apis/shared has no client of its own (it's not part of API_GROUPS) but still needs deepcopy, hence EXTRA_DEEPCOPY_PKGS. openapi-shared/ openapi-% are updated for the new openapi-gen CLI (positional packages + --output-dir/--output-pkg/--output-file instead of --input-dirs/ --output-package); their --input-dirs list also drops go.bytebuilders.dev/catalog/api/v1alpha1, an unresolvable reference (no such package is in go.mod/vendor, or imported anywhere under apis/ -- only an unrelated cmd/import-crds tool references a same-named but different package) that the old openapi-gen silently tolerated but the new one hard-fails on. 12 +genclient types across editor/identity/meta (EditorModel, AuditTokenRequest, InboxTokenRequest, ChartPresetQuery, ClusterStatus, Render, RenderDashboard, RenderMenu, RenderRawGraph, ResourceGraph, ResourceManifests, ResourceQuery) are request/response payloads with no metav1.ObjectMeta -- the new gentype-based client-gen would otherwise require adding it (or dropping +genclient) for all 12, same as kubedb.dev/apimachinery's DatabaseSummary needed. Instead, this bumps kmodules.xyz/client-go to pick up its new create-only gentype.Client[T runtime.Object] (kmodules/client-go#646) and the matching kmodules/code-generator client-gen patch that detects this shape (+genclient:onlyVerbs=create with no ObjectMeta) and builds the client on it instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object -- so none of apis/ needed any changes at all, for any of the 12 types. Verified with make check-license, lint, build, and a full make gen (update-codegen, manifests, openapi) against the real gengo-builder release-1.34 image -- zero apis/ diff, and the only crds/ diff is the newer controller-gen (ac-0.19.0, up from whatever this repo's release-1.32-era CODE_GENERATOR_IMAGE shipped) dropping the null creationTimestamp field CRD YAML used to carry. make unit-tests passes except hub.TestRegister, which needs a live cluster (KUBERNETES_MASTER) that this repo's CI provisions via kind but wasn't available to verify locally -- not something this migration touches. Signed-off-by: Tamal Saha <tamal@appscode.com>
tamalsaha
added a commit
to kubedb/apimachinery
that referenced
this pull request
Sep 2, 2026
…Meta (#1889) Reverses the +genclient removal from the previous commit. That was a reasonable fix at the time (nothing calls the generated client, and a metav1.Object-requiring client is architecturally wrong for a pure request/response payload type), but it's no longer the best available option: kmodules/code-generator's client-gen now detects exactly this shape -- a +genclient:onlyVerbs=create type with no metav1.ObjectMeta -- and builds its client on kmodules.xyz/client-go/gentype's create-only Client[T runtime.Object] instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object. See that package's doc comment for the full rationale (Client[T].Create never actually calls any metav1.Object method on T; the constraint is just declared on the whole generic struct rather than per-method). This keeps the generated DatabaseSummaries() client working for any future caller without DatabaseSummary claiming a real Kubernetes identity it doesn't have -- no ObjectMeta, no CRD (still no +kubebuilder:object:root=true/+kubebuilder:resource markers, since controller-gen needs ObjectMeta to treat a type as a CRD root and ui-server serves this type via API aggregation, not a CRD). Bumps kmodules.xyz/client-go to pick up the new gentype subpackage (kmodules/client-go#646). Verified with make check-license, lint, build, unit-tests, and a full make gen (update-codegen, manifests, openapi) against the gengo-builder release-1.34 image (rebuilt locally with the matching client-gen patch, not yet published) -- zero apis/ CRD manifest diff, matching the fact that this type still has no CRD. Signed-off-by: Tamal Saha <tamal@appscode.com>
tamalsaha
added a commit
to kmodules/resource-metadata
that referenced
this pull request
Sep 2, 2026
…ease-1.34 (#672) Mirrors the same migration already done for kubedb.dev/apimachinery, kubevault.dev/apimachinery, voyagermesh.dev/apimachinery and kubeops.dev/petset: replaces the old generate-groups.sh based clientset target with update-codegen.sh, a generic script bundled into CODE_GENERATOR_IMAGE (see appscodelabs/gengo-builder's scripts/update-codegen.sh for the full env-var interface). GENERATORS is scoped to deepcopy+client only (no lister/informer), matching what the old generate-groups.sh call here actually generated. apis/shared has no client of its own (it's not part of API_GROUPS) but still needs deepcopy, hence EXTRA_DEEPCOPY_PKGS. openapi-shared/ openapi-% are updated for the new openapi-gen CLI (positional packages + --output-dir/--output-pkg/--output-file instead of --input-dirs/ --output-package); their --input-dirs list also drops go.bytebuilders.dev/catalog/api/v1alpha1, an unresolvable reference (no such package is in go.mod/vendor, or imported anywhere under apis/ -- only an unrelated cmd/import-crds tool references a same-named but different package) that the old openapi-gen silently tolerated but the new one hard-fails on. 12 +genclient types across editor/identity/meta (EditorModel, AuditTokenRequest, InboxTokenRequest, ChartPresetQuery, ClusterStatus, Render, RenderDashboard, RenderMenu, RenderRawGraph, ResourceGraph, ResourceManifests, ResourceQuery) are request/response payloads with no metav1.ObjectMeta -- the new gentype-based client-gen would otherwise require adding it (or dropping +genclient) for all 12, same as kubedb.dev/apimachinery's DatabaseSummary needed. Instead, this bumps kmodules.xyz/client-go to pick up its new create-only gentype.Client[T runtime.Object] (kmodules/client-go#646) and the matching kmodules/code-generator client-gen patch that detects this shape (+genclient:onlyVerbs=create with no ObjectMeta) and builds the client on it instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object -- so none of apis/ needed any changes at all, for any of the 12 types. Verified with make check-license, lint, build, and a full make gen (update-codegen, manifests, openapi) against the real gengo-builder release-1.34 image -- zero apis/ diff, and the only crds/ diff is the newer controller-gen (ac-0.19.0, up from whatever this repo's release-1.32-era CODE_GENERATOR_IMAGE shipped) dropping the null creationTimestamp field CRD YAML used to carry. make unit-tests passes except hub.TestRegister, which needs a live cluster (KUBERNETES_MASTER) that this repo's CI provisions via kind but wasn't available to verify locally -- not something this migration touches. Signed-off-by: Tamal Saha <tamal@appscode.com>
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.
Summary
Some aggregated-apiserver API types are pure request/response "action" payloads with no real persisted identity (e.g. an editor-model resolver or a token-exchange endpoint that only ever accepts POST), and deliberately carry no
metav1.ObjectMeta.k8s.io/client-go/gentype.Client[T](which everyclient-gen-generated typed client has been built on since kubernetes/kubernetes#121439) requires its type parameter to satisfymetav1.Object, even when the generated client only exposesCreate:Client[T].Createnever actually calls anymetav1.Objectmethod onT-- onlyUpdate/Get/Deletedo (obj.GetName(), to build the REST path) -- but the constraint is declared on the whole generic struct rather than per-method, so every type needs it regardless of which verbs its generated client actually has.This adds a parallel
Client[T runtime.Object]/FakeClient[T runtime.Object]pair, matchingk8s.io/client-go/gentype's shape (NewClient,Option,PrefersProtobuf,GetClient,GetNamespace,Create) but scoped to exactly what a create-only client needs.Paired with a kmodules/code-generator patch so
client-genautomatically builds a type's generated client on this package instead when it detects+genclient:onlyVerbs=create(no other verb) combined with nometav1.ObjectMetamember.Verification
go build ./gentype/...andgo vet ./gentype/...pass. Verified end-to-end againstkmodules.xyz/resource-metadata's 12 affected types (via a localgo.modreplace) -- both the real and fake generated clients compile against this package with zero changes needed to anyapis/type.