Client-go: Including CRD client into client-go repo
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.
hongchaodeng
All 19 comments
Some background here: https://github.com/kubernetes/kubernetes/issues/46702
@sttts still plan to create a "create an authoritative client in client-go"? Something we can help out with?
ericchiang
on 17 Jul 2017
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 notifications@github.com
wrote:
Some background here: kubernetes/kubernetes#46702
https://github.com/kubernetes/kubernetes/issues/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
https://github.com/kubernetes/client-go/issues/247#issuecomment-315848902,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngltfGaUj_q7p99hOLDKtsEsN-QWjTks5sO67KgaJpZM4OaXMX
.
lavalamp
on 17 Jul 2017
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?
sttts
on 18 Jul 2017
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.
deads2k
on 18 Jul 2017
@deads2k
The plan has been to have a core library
Where is the plan? Any docs?
hongchaodeng
on 19 Jul 2017
@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 ?
hongchaodeng
on 19 Jul 2017
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.
caesarxuchao
on 19 Jul 2017
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
nstott
on 29 Sep 2017
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
on 8 Oct 2017
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.
sigxcpu76
on 9 Oct 2017
@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.
caesarxuchao
on 9 Oct 2017
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.
sttts
on 10 Oct 2017
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
timothysc
on 11 Oct 2017
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.
deads2k
on 11 Oct 2017
@deads2k are you against moving CRD creation client in client-go ? Why or am i misunderstanding this ?
krmayankk
on 29 Nov 2017
@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.
deads2k
on 29 Nov 2017
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
on 27 Feb 2018
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
on 29 Mar 2018
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
fejta-bot
on 28 Apr 2018
Related issues
aaron276h
·
4Comments
jgrobbel
·
3Comments
mheese
·
5Comments
yashbhutwala
·
4Comments
tamalsaha
·
3Comments
Most helpful comment
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