Including CRD client into client-go repo

[hongchaodeng]

Currently CRD client and api all sits in https://github.com/kubernetes/apiextensions-apiserver.

Eventually, CRD client would be better to live in client-go as well. It would be easier for users if client-go can manage dependencies, manage backward compatibility, and testing all in one place.

[ericchiang]

Some background here: kubernetes/kubernetes#46702

@sttts still plan to create a "create an authoritative client in client-go"? Something we can help out with?

[lavalamp]

Plan of record is https://github.com/kubernetes/community/blob/master/contributors/design-proposals/csi-client-structure-proposal.md

…

On Mon, Jul 17, 2017 at 11:58 AM, Eric Chiang ***@***.***> wrote: Some background here: kubernetes/kubernetes#46702 <kubernetes/kubernetes#46702> @sttts <https://github.com/sttts> still plan to create a "create an authoritative client in client-go"? Something we can help out with? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#247 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAngltfGaUj_q7p99hOLDKtsEsN-QWjTks5sO67KgaJpZM4OaXMX> .

[sttts]

if client-go can manage dependencies, manage backward compatibility, and testing all in one place.

Right now both apiextensions-apiserver and client-go are maintained, tested and exported from the same repo (k8s.io/kube). So for the moment the integration argument does't exist.

Now with the upcoming 1.8 we could move the types into k8s.io/api and the client into client-go, if we want to centralize everything there. /cc @deads2k @caesarxuchao

@lavalamp the document is outdated because it doesn't mention the role of k8s.io/api, isn't it?

[deads2k]

Now with the upcoming 1.8 we could move the types into k8s.io/api and the client into client-go, if we want to centralize everything there. /cc @deads2k @caesarxuchao

I don't think we want to do that. The plan has been to have a core library that all clients share and then various clients can use it to have a common set of machinery for interoperability while maintaining logical separation. The technique appears to be working (the clients play together in e2e tests). I think we should maintain the logical separation.

[hongchaodeng]

@deads2k

The plan has been to have a core library

Where is the plan? Any docs?

[hongchaodeng]

@lavalamp

Thanks for sharing.
From https://github.com/kubernetes/community/blob/master/contributors/design-proposals/csi-client-structure-proposal.md, is CRD client gonna sit in github.com/kubernetes-client/core-go ?

[caesarxuchao]

People usually use CRD together with other core API. I think it makes sense to let people access both API from one clientset.

We still plan to split client-go to core-go and base-go, but CRD doesn't have to live outside of core-go.

[nstott]

People usually use CRD together with other core API. I think it makes sense to let people access both API from one clientset

the hoop jumping that's involved in managing tpr clients is awkward, any simplification here is great

[sigxcpu76]

I was bit by this today. I think the README needs to be adjusted because Exactly the same features / API objects in both client-go and the Kubernetes version. is misleading, isn't it?

[sigxcpu76]

client-go 5.0.0 does not include them either. Maybe it can be fixed before the release, as I've read that the current is the release candidate.

[caesarxuchao]

@deads2k do you still feel strongly that the CRD type definition should remain in k8s.io/apiextension-apiserver, rather than in k8s.io/api? If so, we need to spend some time making the example clearer, or even adapting the clientset interface for easier integration.

[sttts]

or even adapting the clientset interface

I don't think this is the right solution. But I agree that we have to improve the experience.

We cannot import k8s.io/apiextension-apiserver here because it creates an import cycle. We could place a very simple _crd example here though. Underscore packages are allowed. And we have to improve the README.md, being explicit that k8s.io/apiextension-apiserver must be vendored.

[timothysc]

It's a really bad UX, whose design is befuddling to most outside observers. I honestly don't know if someone new to the community would make any sense of what is there and why.

+1 for move into client-go

/cc @jbeda

[deads2k]

It's a really bad UX, whose design is befuddling to most outside observers. I honestly don't know if someone new to the community would make any sense of what is there and why.

As new API servers (like service catalog) are added, this will be normal operating procedure. You need the shared client library and the different clients you want to use layered on top. We should devote our effort to making that as easy an obvious as possible, because client-go will not grow to contain everything.

As @sttts noted, we can help with clear examples and documentation, but patching in a fix in here doesn't serve the community in the mid to long term. client-go was designed for this composition and it is the only viable long term option. Let's try to make it hum.

[krmayankk]

@deads2k are you against moving CRD creation client in client-go ? Why or am i misunderstanding this ?

[deads2k]

@deads2k are you against moving CRD creation client in client-go ? Why or am i misunderstanding this ?

I am against it. As our type ecosystem grows, we'll have more and more clients that must build on top of client-go. As it stands now, we have a clean logical separation of this type and its related server. Rather than take the "easy" path that combines unrelated API groups together (this isn't related to storage.k8s.io at all) and is only available to kubernetes members, we should make the intended client-go extension mechanisms easier to manage.

For instance, consider service-catalog or openshift/client-go. Their types will never be included in k8s.io/api, but many people would like to use both clients. The broader community needs to have an easy way to use multiple discrete client libraries and we need to be eating our own dog food or the story may never improve.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close