Re: Clients and SDKs

30 views
Skip to first unread message

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.

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.

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.

For more options, visit https://groups.google.com/d/optout.

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:32:59 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:56 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:25:59 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