Allow --api-version to properly override various default behaviors in CLI #2909
Conversation
|
Blocks #2878 |
When a CLI command `kubectl get rc --api-version=v1beta3` is called,
the API resource name should match v1beta3, not whatever the default
RESTMapper version is. This allows the correct resource name to be
returned ("replicationcontrollers", instead of "replicationControllers").
smarterclayton
force-pushed
the
passversiontorestmapper
branch
from
c8fb1eb to
203246b
Compare
|
Comments addressed - in light of #2861 where I'm having david break up clientcmd a bit a lot of this code will change, so I added a test case for override that exercised the paths (to demonstrate the concept) but didn't try to reduce the complexity of clientcmd. Long term vision for clientcmd is that config creation is the primary use case (give me a config object I can use to init a client), where config might be for multiple servers each exposing both the Kube API and potentially other APIs that follow the Kube pattern. When that happens the builder code becomes much simpler and there will be a default simple path "I want to get a client for this command with all the default flags", then more complex logic all the way up to "I want to read from a multilevel / contextual config set on disk, merge it with flags, then feed it to the cli" |
|
This is the last blocking issue for v1beta3 enablement. |
|
LGTM - rerunning travis. I think clientcmd.Builder is fundamentally confused-- it builds both configs and clients, it should only do one of those things, and then "Override" wouldn't be needed. But I won't ask you to fix that. |
Allow --api-version to properly override various default behaviors in CLI
keps/sig-instrumentation: Add metrics overhaul KEP
Part of #1519 - allows users to control what gets sent to the server