I don't really understand REST client machinery well enough, so I may very well be wrong on this, but won't this cause the following call to fail for an adapter that actually implements v1beta2?

We initially put the result into v1beta1.MetricValueList{} and only later apply the conversion. But I don't expect v1beta2 result to be able to deserialize into a v1beta1 value list as MetricValue type is not compatible between versions. Am I missing something here?

Adapters will have to implement both APIs for the time being, and then we'll have to do the switch over in a later release.

So adapters should start implementing v1beta2 now, then when we switch over next release (or the one after) here, they'll have support for it, and a given adapter will work with both versions of kube. Then, the release after that, we'll be able to finally remove v1beta1.

(that's the only way I can see this working, without fallback logic, and I don't think there's a precedence for fallback logic since we stopped using unversioned clients).

I see your point. I wonder if we could address this by having a separate client for each version, discover which version is available and use the appropriate client in HPA?

I don't like the approach of switching the version at some point, mainly because I'm skeptical about every adapter implementing v1beta2 while it's not actually supported by k8s. I think we're effectively just pushing the problem to next release.

Also our deprecation policy is to support deprecated beta for 3 versions, so it will take a while to switch over. In the meantime every new adapter would have to implement a deprecated API.

I see your point. I wonder if we could address this by having a separate client for each version, discover which version is available and use the appropriate client in HPA?

I considered that, but it's way more complicated, and doesn't really seem to have a precendent in the rest of the codebase, IIRC (ever since we removed the unversioned clients).

In the meantime every new adapter would have to implement a deprecated API.

Nobody needs to implement anything new except for the developers of kubernetes-incubator/custom-metrics-apiserver -- all adapters should get the APIs for free when they update.

Perhaps we should have @kubernetes/sig-api-machinery-pr-reviews weigh in?

if we really want to reintroduce hubbed clients, I'm very hesitant to do so during code slush -- I'd really prefer to go with this solution, which should produce a working cluster, and then deal with potentially adding hubbed clients next release.

@lavalamp another concrete example of the utility of a hub an a hubbed client.

@DirectXMan12 if it were my code, I would generate two different clients. Then given an apiserver, I would use discovery to choose from the available APIs to new up the "best" client. Then, if necessary, I would provide adapter clients that could skin one version as another one. It's pretty painful, but with only two versions, it isn't so bad.

@deads2k ack, that seems reasonable to me eventually. do we want to try to do it less than a week before code freeze while the tests are broken, though?

@damemi your mission, should you choose to accept it ^

@deads2k ack, that seems reasonable to me eventually. do we want to try to do it less than a week before code freeze while the tests are broken, though?

This is a regression fix, right? If this regressed, then we'll certainly take a fix after freeze. Things like this are rarely re-visited after they "work".