The fake clientset does not work as expected

[robertmarsal]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Trying to use the fake client set to write some unit tests:

kongClientset := kongtestclient.NewSimpleClientset(&kongv1.KongPlugin{
	ObjectMeta: metav1.ObjectMeta{
		Name:      "test-plugin",
		Namespace: "test-ns",
	},
})

Where kongv1 is the following import: kongv1 "github.com/kong/kubernetes-ingress-controller/v2/pkg/apis/configuration/v1"

Calling

plugin, err := kongClientset.ConfigurationV1().KongPlugins("test-ns").Get(ctx, "test-plugin", metav1.GetOptions{})

returns an error that the plugin can not be found. This is because the group of the fake generated resources is wrong: https://github.com/Kong/kubernetes-ingress-controller/blob/main/pkg/clientset/typed/configuration/v1/fake/fake_kongplugin.go#L39. It should be configuration.konghq.com instead of configuration

It looks like client-gen uses the folder structure to determine the group and at the moment it's set to configuration: https://github.com/Kong/kubernetes-ingress-controller/tree/main/pkg/apis/configuration

Renaming the folder to configuration.konghq.com and reruning client-gen generates the correct groups. I am not sure if having the wrong name for the folder has other impacts I've only noticed this when trying to use it for testing.

Renaming that folder seems to break the public API though so I was not sure if it was an acceptable solution. I haven't seen any ways around it with the client-gen options

Expected Behavior

The fake simple client set can be used for testing.

Steps To Reproduce

1. Try to use the `NewSimpleClientSet` in tests as described in the current behaviour

Kong Ingress Controller version

v2.8.1

Kubernetes version

No response

Anything else?

No response

[pmalek]

Thanks for your report @robertmarsal!

This is actually interesting and it seems we have to be doing something not 100% correct. I've looked at other projects that generate clientsets e.g. Gateway API and Knative's serving and they both don't use the group name in their packages import path, e.g.

• https://github.com/kubernetes-sigs/gateway-api/tree/main/pkg/client/clientset/versioned/typed/apis/v1beta1
• https://github.com/knative/serving/tree/main/pkg/client/clientset/versioned/typed/autoscaling/v1alpha1

Yet they do get the full group name generated in the fake clients, e.g.

• https://github.com/kubernetes-sigs/gateway-api/blob/b78ceac4ebd177fef9946212eae25c2aecc73049/pkg/client/clientset/versioned/typed/apis/v1beta1/fake/fake_gateway.go#L39-L41
• https://github.com/knative/serving/blob/8c282baf66099c923dd6e23b4f19e33c64af40b4/pkg/client/clientset/versioned/typed/autoscaling/v1alpha1/fake/fake_podautoscaler.go#L39-L41

I've tried playing around with client-gen options and I cannot make client-gen generate the full group name in those fakes.

I've tried setting the --input-base to "" just like knative does it but still no luck.

These are the options I've used with not much of an effect:

	$(CLIENT_GEN) \
		--go-header-file ./hack/boilerplate.go.txt \
		--logtostderr \
		--clientset-name clientset \
		--input-base ""  \
		--input $(REPO_URL)/v2/pkg/apis/configuration/v1,$(REPO_URL)/v2/pkg/apis/configuration/v1beta1,$(REPO_URL)/v2/pkg/apis/configuration/v1alpha1 \
		--output-base pkg/ \
		--output-package $(REPO_URL)/v2/pkg/ \
		--trim-path-prefix pkg/$(REPO_URL)/v2/

What you're proposing would warrant a breaking changes release which we're not looking at right now (but we might at some point). So trying to figure this out just like the other projects did this would be they preferred solution.

[robertmarsal]

@pmalek thank you for the feedback! It pointed me in the right direction and I noticed that the gateway-api project used these doc.go files to defined the tags for the package. The tags were defined but in the wrong location. After creating those files the generation works as expected 🎉 .

I've created the PR #3621 with the fix.