client/request warns about Kube objects, should be abstracted

[smarterclayton]

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/client/request.go#L277 specifically refers to Kube objects, but client is generic to any runtime.Object. We should abstract this code into scheme, and pull it out of pkg/client/request.go.

[smarterclayton]

@lavalamp

[lavalamp]

I think that will make sense when we offer versioned clients, which I hope to get together soon.

[smarterclayton]

As an example of where we already tolerate this one way:

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/client/pods.go#L77

I don't particularly like that.... but...

On Tue, Jul 14, 2015 at 5:22 PM, Daniel Smith notifications@github.com
wrote:

I think that will make sense when we offer versioned clients, which I hope
to get together soon.

—
Reply to this email directly or view it on GitHub
#11261 (comment)
.

Clayton Coleman | Lead Engineer, OpenShift

[smarterclayton]

How will versioned clients work when the server doesn't support your
version? Or do you have a plan for that as well?

On Tue, Jul 14, 2015 at 5:39 PM, Clayton Coleman ccoleman@redhat.com
wrote:

As an example of where we already tolerate this one way:

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/client/pods.go#L77

I don't particularly like that.... but...

On Tue, Jul 14, 2015 at 5:22 PM, Daniel Smith notifications@github.com
wrote:

I think that will make sense when we offer versioned clients, which I
hope to get together soon.

—
Reply to this email directly or view it on GitHub
#11261 (comment)
.

Clayton Coleman | Lead Engineer, OpenShift

Clayton Coleman | Lead Engineer, OpenShift

[lavalamp]

Well, I was thinking about just requiring the server to support the version you ask for. But now that I think about it, I guess we could allow the client library to up/down convert objects into the version corresponding to the client version. (see #4874 (comment))

[smarterclayton]

It may not be a huge issue, but I could imagine supporting both v1 and v2
servers at the same time - we typically in the past manage that by having
the client libraries work against both, and conversion helps to some
degree. There's always some divergence though, which implies custom
coding.

On Tue, Jul 14, 2015 at 6:20 PM, Daniel Smith notifications@github.com
wrote:

Well, I was thinking about just requiring the server to support the
version you ask for. But now that I think about it, I guess we could allow
the client library to up/down convert objects into the version
corresponding to the client version. (see #4874 (comment)
#4874 (comment)
)

—
Reply to this email directly or view it on GitHub
#11261 (comment)
.

Clayton Coleman | Lead Engineer, OpenShift

[lavalamp]

Yeah, I think that's doable. But servers will already have to support v1
until all clients have been configured to speak v2. So it's a nice-to-have.

On Tue, Jul 14, 2015 at 3:38 PM, Clayton Coleman notifications@github.com
wrote:

It may not be a huge issue, but I could imagine supporting both v1 and v2
servers at the same time - we typically in the past manage that by having
the client libraries work against both, and conversion helps to some
degree. There's always some divergence though, which implies custom
coding.

On Tue, Jul 14, 2015 at 6:20 PM, Daniel Smith notifications@github.com
wrote:

Well, I was thinking about just requiring the server to support the
version you ask for. But now that I think about it, I guess we could
allow
the client library to up/down convert objects into the version
corresponding to the client version. (see #4874 (comment)
<
#4874 (comment)

)

—
Reply to this email directly or view it on GitHub
<
#11261 (comment)

.

Clayton Coleman | Lead Engineer, OpenShift

—
Reply to this email directly or view it on GitHub
#11261 (comment)
.

[smarterclayton]

I think we finally fixed this.