Clients and SDKs

53 views
Skip to first unread message

Matt Farina

unread,
Oct 25, 2017, 3:29:25 PM10/25/17
to kubernete...@googlegroups.com, kubernetes-sig-apps
In SIG API Machinery, after the conversation in SIG CLI today about clients and SDKs, I added the topic to SDKs and Clients to the agenda and we had a good discussion. A few things came up I wanted to shared with SIG CLI:
  1. A working group on clients and SDKs was suggested. Similar to what Joe said with a SIG SDK. A working group was suggested here because it crosses multiple SIGs
  2. Generating clients from OpenAPI specs was discussed. There's already multi-client work going on at https://github.com/kubernetes-client
  3. Clients that increment the minor version while adding API support for a new version of Kubernetes because the code structure doesn't change enough to cause a major/breaking change
  4. People interesting in working on clients and SDKs are needed
I'll be bringing this up at SIG Apps on Monday as well.

--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

Stefan Schimanski

unread,
Oct 26, 2017, 4:12:53 AM10/26/17
to Matt Farina, kubernetes-sig-cli, kubernetes-sig-apps
On Wed, Oct 25, 2017 at 9:29 PM, Matt Farina <matt....@gmail.com> wrote:
In SIG API Machinery, after the conversation in SIG CLI today about clients and SDKs, I added the topic to SDKs and Clients to the agenda and we had a good discussion. A few things came up I wanted to shared with SIG CLI:
  1. A working group on clients and SDKs was suggested. Similar to what Joe said with a SIG SDK. A working group was suggested here because it crosses multiple SIGs
I like the idea of a SIG SDK and would love to contribute. I would also be happy to drive this by co-leading this group representing SIG api-machinery. I say explicitly "co-leading" because we need broader participation and commitment than SIG api-machinery alone. I would like to see people from SIG Apps actively taking part in this making this a true joint-effort.
  1. Generating clients from OpenAPI specs was discussed. There's already multi-client work going on at https://github.com/kubernetes-client 
I am skeptical that this solves the actual problem. Note that a generated client from OpenAPI will have completely separate API objects (no k8s.io/api), no helpers like informers and all the other infrastructure for building controller. I.e. we open up a new type & tool universe with that.

Also there is already Eric Chiang's https://github.com/ericchiang/k8s which uses native (k8s.io/api) types, but is much smaller and simpler than client-go. Did that solve the problems that people had with client-go? Do people use that? If yes, why. If not (anymore), why not?

I am not convinced that stopping dogfooding the official client 3rdparties use (that's what it would mean if we had another OpenAPI generated client) is the right way to go forward.
  1. Clients that increment the minor version while adding API support for a new version of Kubernetes because the code structure doesn't change enough to cause a major/breaking change
  2. People interesting in working on clients and SDKs are needed
I'll be bringing this up at SIG Apps on Monday as well.

--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2q38UF%2BOak658wBxV%2BAtzW9yJZEBSXa3QmXLOzeT_nbhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Matt Farina

unread,
Oct 31, 2017, 10:40:54 AM10/31/17
to kubernetes-sig-apps
Stefan,

Sorry for the slow reply but here goes...

I like the idea of a SIG SDK and would love to contribute. I would also be happy to drive this by co-leading this group representing SIG api-machinery.

Should this be a SIG or WG? In the next SIG Apps we'll have a discussion on this. I'll see if anyone else is interested in being looped in and in what way. If this is going to cross api-machinery and SIG Apps it might be good to do as a join effort (a WG if needing formalization, right?)

I am skeptical that this solves the actual problem. Note that a generated client from OpenAPI will have completely separate API objects (no k8s.io/api), no helpers like informers and all the other infrastructure for building controller. I.e. we open up a new type & tool universe with that.

This sounds like it's focused on Go. What's the path for other languages as well? Is there a way to have a sane strategy for multiple languages?

https://github.com/ericchiang/k8s

We've not talked about this. Kinda hard to discover things in the k8s community. We'll add it to the agenda for sig apps.

I am not convinced that stopping dogfooding the official client 3rdparties use (that's what it would mean if we had another OpenAPI generated client) is the right way to go forward.

My 2 cents on the right path forward is the one that products a client (or SDK) that's easily consumable by the masses and that they are pleased with.

Cheers,
Matt 

Ihor Dvoretskyi

unread,
Oct 31, 2017, 12:06:53 PM10/31/17
to Matt Farina, kubernetes-sig-apps
> Should this be a SIG or WG? In the next SIG Apps we'll have a discussion on this. I'll see if anyone else is interested in being looped in and in what way. If this is going to cross api-machinery and SIG Apps it might be good to do as a join effort (a WG if needing formalization, right?)

WG should be a better option for this initiative.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/11b31427-169f-465a-8bba-630fe6111ef9%40googlegroups.com.

Stefan Schimanski

unread,
Nov 1, 2017, 3:52:38 AM11/1/17
to Ihor Dvoretskyi, Matt Farina, kubernetes-sig-apps
On Tue, Oct 31, 2017 at 5:06 PM, Ihor Dvoretskyi <ihor.dv...@gmail.com> wrote:
> Should this be a SIG or WG? In the next SIG Apps we'll have a discussion on this. I'll see if anyone else is interested in being looped in and in what way. If this is going to cross api-machinery and SIG Apps it might be good to do as a join effort (a WG if needing formalization, right?)

WG should be a better option for this initiative.

+1

Brian Grant

unread,
Nov 1, 2017, 9:54:50 AM11/1/17
to Stefan Schimanski, Ihor Dvoretskyi, Matt Farina, kubernetes-sig-apps
Client libraries are within the scope of API Machinery. A work group would be fine, but please involve API machinery.

Matt Farina

unread,
Nov 1, 2017, 4:28:53 PM11/1/17
to Brian Grant, Stefan Schimanski, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
Client libraries are within the scope of API Machinery.

Reading the details on the community repo for SIG API Machinery I can clearly see that it owns the clients.

I'm a fan of not creating more organizational units within Kubernetes. It would be worth seeing what it takes to get it going there.

Stefan Schimanski

unread,
Nov 1, 2017, 4:59:51 PM11/1/17
to Matt Farina, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
On Wed, Nov 1, 2017 at 9:28 PM, Matt Farina <matt....@gmail.com> wrote:
Client libraries are within the scope of API Machinery.

Reading the details on the community repo for SIG API Machinery I can clearly see that it owns the clients.

I'm a fan of not creating more organizational units within Kubernetes. It would be worth seeing what it takes to get it going there.

The clients and the code-generators are owned by sig API machinery. I don't think we have a lack of ownership here.

Instead, where we can improve is a stronger focus on the use-cases of external consumers. With the many low-level topics that the sig API machinery owns and discusses in its 2-weekly meening, there is hardly room for this. What I would like to see in a WG SDK is

- that we identify a list of the most critical pain points of using our libraries as a 3rdparty
- that the WG is a platform to discuss solutions
- that the WG systematically works on the issues and tracks the results (e.g. via kubernetes/features).

Sig apps members can certainly contribute to the first easily. 

Many of the solutions will be in the code that is formally owned by sig API machinery. But, at the same time most solutions won't be deep in the core, so onboarding people with an interest to contribute should be straight forward. 

Last but not least, having a mandate from sig API machinery is important to work towards easier consumption by 3rdparties because all this will lead to changes in the clients and how we publish them, and of course in all related code like code-generators.


On Wed, Nov 1, 2017 at 9:54 AM, Brian Grant <brian...@google.com> wrote:
On Wed, Nov 1, 2017 at 12:52 AM, Stefan Schimanski <st...@redhat.com> wrote:
On Tue, Oct 31, 2017 at 5:06 PM, Ihor Dvoretskyi <ihor.dv...@gmail.com> wrote:
> Should this be a SIG or WG? In the next SIG Apps we'll have a discussion on this. I'll see if anyone else is interested in being looped in and in what way. If this is going to cross api-machinery and SIG Apps it might be good to do as a join effort (a WG if needing formalization, right?)

WG should be a better option for this initiative.

+1

Client libraries are within the scope of API Machinery. A work group would be fine, but please involve API machinery.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2rrhU392eKqWUFOepHm0hY6%3DyinZz-Za%2BaY9d%3DhvRSm0A%40mail.gmail.com.

Matt Farina

unread,
Nov 1, 2017, 5:26:17 PM11/1/17
to Stefan Schimanski, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
With the many low-level topics that the sig API machinery owns and discusses in its 2-weekly meening, there is hardly room for this.

If SIG API Machinery owns this how do we bump it up in priority or meet every week to have the room?

What I would like to see in a WG SDK is
- that we identify a list of the most critical pain points of using our libraries as a 3rdparty
- that the WG is a platform to discuss solutions
- that the WG systematically works on the issues and tracks the results (e.g. via kubernetes/features).

Why wouldn't these happen in SIG API Machinery? It feels like a separation is being created between low level mechanics and listening to users and coming up with solutions for them. Not sure I like that separation because the low level should be based on the end users needs being met.

Clients are important for ecosystem enablement. How can we have SIG API Machinery be more active when it comes to them? Is it a lack of people showing up with an interest in that?
 

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.

To post to this group, send email to kubernetes-sig-apps@googlegroups.com.

Phillip Wittrock

unread,
Nov 1, 2017, 5:33:00 PM11/1/17
to Matt Farina, Stefan Schimanski, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
If you are interested in this, please checkout this document that performs an analysis of what popular web app frameworks do to make development simple.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAMPAG2r64psMK-E9NHr077A8St0Hp9o_6V497KQrd%3DfDXHdorw%40mail.gmail.com.

Matt Farina

unread,
Nov 1, 2017, 5:39:47 PM11/1/17
to Phillip Wittrock, Stefan Schimanski, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
That document looks to be about building APIs rather than clients to consume them. What about the app developer/API consumer user experience?

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAMPAG2r64psMK-E9NHr077A8St0Hp9o_6V497KQrd%3DfDXHdorw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Smith

unread,
Nov 1, 2017, 5:50:57 PM11/1/17
to Matt Farina, Stefan Schimanski, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
On Wed, Nov 1, 2017 at 2:26 PM, Matt Farina <matt....@gmail.com> wrote:
With the many low-level topics that the sig API machinery owns and discusses in its 2-weekly meening, there is hardly room for this.

If SIG API Machinery owns this how do we bump it up in priority or meet every week to have the room?

What I would like to see in a WG SDK is
- that we identify a list of the most critical pain points of using our libraries as a 3rdparty
- that the WG is a platform to discuss solutions
- that the WG systematically works on the issues and tracks the results (e.g. via kubernetes/features).

Why wouldn't these happen in SIG API Machinery? It feels like a separation is being created between low level mechanics and listening to users and coming up with solutions for them. Not sure I like that separation because the low level should be based on the end users needs being met.

API machinery owns a ton of stuff. I think that forming a working group of people who have time to actually improve this particular thing makes sense; it is big enough to deserve its own semi-regular meetings. I think a few people who intend to focus most of their time on it will be a lot more effective than having a lot of people who care but don't have much time to spend.
 
Clients are important for ecosystem enablement. How can we have SIG API Machinery be more active when it comes to them? Is it a lack of people showing up with an interest in that?

API Machinery is focused on extensibility right now. Clients are a part of that but are not currently the biggest fire (this should tell you something about the size of the other fires). We own ~25% of the codebase last I checked and have vastly fewer than 25% of the people working on Kubernetes in the SIG.

It is actually basically amazing that Chao and Stefan have been able to extract the client into a separately consumable, composable repo at all, given the difficulty and the fact that the go dependency management system goes to great lengths to make this impossible.

Re: regenerating the go client from open api instead of using the current system: that solves some problems, but leaves others (you'd lose reflectors, informers, etc). 

Anyway, my main point: it's not that we don't care, it's that we have prioritized other things (this quarter, dynamic admission/webhooks), and there is (always has been) a skeleton crew paying attention to the client.

You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAMPAG2r64psMK-E9NHr077A8St0Hp9o_6V497KQrd%3DfDXHdorw%40mail.gmail.com.

Phillip Wittrock

unread,
Nov 1, 2017, 6:04:57 PM11/1/17
to Matt Farina, Stefan Schimanski, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG
That document looks to be about building APIs rather than clients to consume them. What about the app developer/API consumer user experience?

There is some overlap depending on the consumers.  e.g. controllers are both consumers and implementers of APIs.  both implementers and consumers of APIs probably want instances of the APIs to test against (for the implementer to test the implementation, for consumers to test the integration)

- Phil
 
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.

Mehdy Bohlool

unread,
Nov 1, 2017, 7:26:00 PM11/1/17
to Phillip Wittrock, Matt Farina, Stefan Schimanski, Brian Grant, Ihor Dvoretskyi, kubernetes-sig-apps, K8s API Machinery SIG, Brendan Burns
+Brendan Burns

We've discussed forming sig-client to focus on OpenAPI generated client libraries but decided that we don't want the overhead of a sig yet. Maybe it is the time to start that process again. Our main focus were all non-go clients in `kubernetes-client` org but if we include go-client (in current form or OpenAPI generated form or both), I think this may reach the critical mass of a SIG.

We currently have a slack channel here: https://kubernetes.slack.com/messages/C76GB48RK



Mehdy Bohlool | Software Engineer | me...@google.com | mbohlool@github 


To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.



--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAPzFYDvuufsHoJNsbKtwNVX0GG1OV8CxHv_QHb7BWdFVgRKLxg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages