Some thoughts from a discussion with David today:

1. We want to have an external client library that contains the bare
   minimum shared code - pkg/client/restclient, etc and generated
   encoders/decoders (proto+json)
2. We want to have versioned client libraries built on snapshot external
   API types that uses the client library in 1
3. We want to have a common library for generating conversions, defaults,
   validations, and server side code around the concept of internal+external
   types
4. We want to have a set of APIs that consume the external types from 2 and
   the common code from 3 that are then used elsewhere inside the codebase
   (conversions, defaults, validations, encoders)
5. We want to have server side code that uses the things generated by 4 as
   consistently as possible (with some tweaks possible)
6. Internal types can evolve at a slightly different pace (deliberately)
   than external types, as long as we can roundtrip, so we don't need to jump
   through a lot of hoops to be precise about 2 + 4 (we could maintain our
   external API types externally if necessary)

1 and 3 are really external libraries - 3 can reference 1, but not the
other way around. 2 is definitely external, but could be generated from
internal. 2 should NEVER reference 4.

On Wed, Jul 6, 2016 at 6:57 PM, Chao Xu notifications@github.com wrote:

We plan to provide a light-weight go client library which people can
import. I created a very primitive one here:
https://github.com/caesarxuchao/k8s-go-client. It only contains the Go
clients and the dependencies. Going forward, we plan to:

• Only import the clients that operate on external API types, because
  we want to remove the dependency on API machinery.
• Finish API type structure #16062 API type structure #16062,
  which rearranges the API type structure. This will remove client dependency
  on the default function and probably other dependencies.

I'll expand the TODO list as I move forward.

@kubernetes/sig-api-machinery
https://github.com/orgs/kubernetes/teams/sig-api-machinery
@smarterclayton https://github.com/smarterclayton @lavalamp
https://github.com/lavalamp

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#28559, or mute the
thread
https://github.com/notifications/unsubscribe/ABG_p7W8gU7kQmf3tj_InfEC7oyo63k7ks5qTDLYgaJpZM4JGldN
.

@smarterclayton, I'll repeat to confirm we are on the same page:

1 and 2 are two client libraries. 1 doesn't know any API types. 2 only knows external API types. 2 uses 1. Neither of them contains any conversion/defaulting/validation code.

I intend to start with 1 and 2 in the same repo, and separate them if necessary.

For 4, you said "used elsewhere inside the codebase (conversions, defaults, validations, encoders)", I think this "elsewhere" should mostly just be the api server. conversions/defaults/validations should all be done in the apiserver. Other places should only use serializers.

See also #11606

And #5660, #7584

@lavalamp @caesarxuchao Could we dedupe this and some of the older issues?

And #12290

And #22405

@caesarxuchao yes, although there are non-apiserver bits of code that may need to do conversions / defaulting / validation, like admin config commands. So it's more about separating clients that should know about conversions (admin) from those that shouldn't (most others, including web uis and kubectl).

Would love to test out this client on some "real" projects - any chance of getting the external repo sorted for easier vendoring?

@jimmidyson, we'll publish the repo in this week :)

Awesome! Especially as it's Friday tomorrow :-b

@jimmidyson check this out: https://github.com/kubernetes/client-go

One problem is that go get k8s.io/client-go/1.4 doesn't work. I'll try to figure out why.

Except from an e2e test, I haven't tried to use client-go for real, so I expect it to still have some problems. Please let me know.

Nice! I can live with problems & will raise issues/fixes if I hit some. Out of interest, why the 1.4 subpackage? Shouldn't the client be versioned against the API version rather than the kubernetes version?

why 1.4: https://github.com/kubernetes/client-go#releases

For clients versioned against API version: https://github.com/kubernetes/client-go/tree/master/1.4/kubernetes/typed

@caesarxuchao you need to set up a redirector for it

> curl -D - "https://k8s.io/client-go/?go-get=1" 
HTTP/1.1 404 Not Found
Server: nginx/1.10.1
Date: Thu, 25 Aug 2016 20:48:14 GMT
Content-Type: text/html
Content-Length: 169
Connection: keep-alive

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.10.1</center>
</body>
</html>

versus

> curl -D - "https://k8s.io/kubernetes/?go-get=1" 
HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Thu, 25 Aug 2016 20:48:43 GMT
Content-Type: text/html
Content-Length: 359
Last-Modified: Tue, 23 Aug 2016 22:05:33 GMT
Connection: keep-alive
ETag: "57bcc8ad-167"
Accept-Ranges: bytes

<html><head>
  <meta name="go-import" content="k8s.io/kubernetes git https://github.com/kubernetes/kubernetes">
  <meta name="go-source" content="k8s.io/kubernetes     https://github.com/kubernetes/kubernetes https://github.com/kubernetes/kubernetes/tree/master{/dir} https://github.com/kubernetes/kubernetes/blob/master{/dir}/{file}#L{line}">
</head></html>

go get k8s.io/client-go/1.4/... works now.

I'll close this issue. Feel free to open new issues to report bugs.