Ability to generate contour clients

[shashwathi]

Feature

Ability to generate clients for contour API.

In net-contour knative project we are maintaining a github patch to overcome this problem as a workaround.

cc @andrew-su

[stevesloka]

We might be able to create a contour-api project and have it auto-gen this client in automatically. This would give folks a full client to use in projects.

[bgagnon]

We're using the Contour API via kubernetes-sigs/controller-runtime and have been mostly fine:

	ingressroutev1b1.AddKnownTypes(mgr.GetScheme())
	projectcontour.AddKnownTypes(mgr.GetScheme())

...

	ctrl.NewControllerManagedBy(mgr).
		For(&projectcontour.HTTPProxy{}).
		Owns(&v1.Secret{}).
		Complete(...)

But the idea of an official Contour API package is appealing. In the last upgrade we had to switch to AddKnownTypes() which was an unexpected "breakage".

[stevesloka]

Yeah, we did a poor job of polling the community on that change, so I'm sorry for that. 😞

[jpeach]

@stevesloka Any reason we can't take the knative patch? Or perhaps we should double-check what kubebuilder would generate and ensure we have the expected API there ...

[youngnick]

We removed the generated Informer types earlier because we weren't using them, and we didn't realise anyone else was. I don't see any issue with putting the generation back if people are using them, as long as we call out that the types should be consumed by version tag (which go modules does anyway).

[youngnick]

Splitting the objects out to a new repo is doable but requires a bit of coordination.

[jpeach]

We removed the generated Informer types earlier because we weren't using them, and we didn't realise anyone else was. I don't see any issue with putting the generation back if people are using them, as long as we call out that the types should be consumed by version tag (which go modules does anyway).

It's not clear to me that we need to generate the client (anyone who needs it can generate it from the API package). Rather, it should be easy to use the api package with unstructured types. The Knative patch looks to be targeted at the latter case.

[youngnick]

Yes, I didn't look at the patch, my mistake. @shashwathi is your request just about bringing that patch upstream? I don't see any issues with that at all, although I think there may be a couple of corresponding small changes in the main part of Contour (because of the AddToScheme signature changes).

[shashwathi]

Yeah it would be great if the patch is in upstream.

[jpeach]

@stevesloka @youngnick I checked what kubebuilder does, and it generates a groupversion_info.go like this:

import (
        "k8s.io/apimachinery/pkg/runtime/schema"
        "sigs.k8s.io/controller-runtime/pkg/scheme"
)

var (
        // GroupVersion is group version used to register these objects
        GroupVersion = schema.GroupVersion{Group: "projectcontour.io", Version: "v1"}

        // SchemeBuilder is used to add go types to the GroupVersionKind scheme
        SchemeBuilder = &scheme.Builder{GroupVersion: GroupVersion}

        // AddToScheme adds the types in this group-version to the given scheme.
        AddToScheme = SchemeBuilder.AddToScheme
)

func init() {
        SchemeBuilder.Register(&HTTPProxy{}, &HTTPProxyList{})
}

So IIUC if we add these exports, Contour could be consumed by other controllers more easily, and it would meet the expectations of people familiar with the current ways of kubebuilder.

We should be careful about existing exports though :)

[thalesfsp]

Any update/wiki/guide/tutorial/instructions on how to do generate the client?

[jpeach]

You could use either genclient to generate a typed client, or just use the client-go dynamic client with the Contour types registered with your scheme.

[thalesfsp]

Thank you @jpeach! I tried to follow that tutorial, but I'm getting errors :( This is the first I'm working with K8/codegen/etc. Could you provide some sort of guide/tutorial/instructions? Cheers!

[dossett]

Hello - as a user I agree that a provided client would be nice. I'm working on a project that uses contour and another library that does provide a client and that is a terrific experience. I understand there other options and that I'm by no means blocked, I'm just sharing my experience.

Also, contour is a wonderful tool thank you for creating it!

[thalesfsp]

Update: we moved to Istio.

[youngnick]

I'd really recommend using the dynamic client with controller-runtime, as mentioned above by @bgagnon in https://github.com/projectcontour/contour/issues/2487#issuecomment-622074626. We are moving Contour in the direction of using the controller-runtime pieces more, for reasons like how the pull-through client cache can really help cut down the number of apiserver calls (which can be a problem in big or busy Contour installs).

But, if people would really like the informer-style generated clients, then we can add them back and have them protected with the same generated CI check that we do for the rest of the code.

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack