Change kubectl create to use dynamic client#30250
Conversation
| versionMapper.Add(gv.WithKind(resource.Kind+"List"), scope) | ||
| } | ||
| // TODO why is this type not in discovery (at least for "v1") | ||
| versionMapper.Add(gv.WithKind("List"), meta.RESTScopeRoot) |
There was a problem hiding this comment.
It's not a server resource? It's just a local object. Version mapper shouldn't be blocking this - the server should never have to know about Lists
There was a problem hiding this comment.
Yea, I felt really wrong typing this in, but without it, kubectl create -f hack/testdata/list.yaml fails. I am certainly open to other suggestions.
|
@smarterclayton @krousey - currently dynamic client is not using protobufs at all, so this may result in performance degradation. We should probably try to support protobufs in dynamic client too (based on some discovery?) WDYT? |
| return nil, err | ||
| } | ||
|
|
||
| newRC := *c |
There was a problem hiding this comment.
This shallow copy worries me. We're still sharing the URL pointer, the client, BackoffManager func.
There was a problem hiding this comment.
You're right, I'll change this to call back into NewRESTClient
|
I think we can - part of my comments above would be correcting this code so that resource.Builder doesn't have to know about the details of all of that (it's hidden under Codec) which means that we can in the future use proto for those things. However priority for client is not to use protobuf for the near term. |
|
Regarding proto encoding for dynamic types, I don't see how you could do that without having proto definitions available, at which point... why use dynamic client? |
|
I can imagine interactions where you want to do reads using protobuf and then update an object via the dynamic client. I just don't want to let the interfaces get mixed up - Codec hides those details from RESTClient, not the other way around. |
| return nil, fmt.Errorf("unable to decode %q: %v [%v]", source, err, gvk) | ||
| } | ||
|
|
||
| obj, versioned := versions.Last(), versions.First() |
There was a problem hiding this comment.
Yes, a million times.
|
@smarterclayton I've reworked this a good bit, and I think it's in a good spot for another pass. |
|
I think test-cmd is sufficient. Sure - makes it easier to review. |
This will allow people to override the default parameter codec and still pass the resulting client with something that accepts *dynamic.Client.
|
Fun fact: all of our objects should be |
|
Definitely internal objects should fail / be horribly incompatible if On Mon, Aug 15, 2016 at 6:27 PM, krousey [email protected] wrote:
|
|
@smarterclayton I don't think so. My change is only using a single I'm just adding marshal handlers to the |
And also remove some duplicate code while I'm at it.
|
@smarterclayton I think I addressed the remaining issues you had (the moves in to meta and discovery). I added some json marshaling to unstructured types (runtime/types.go) for proper annotations. I also migrated the replace command. Please take a look when you can. Also... is this release note worthy? |
|
@smarterclayton one last pass? |
|
@krousey |
1 similar comment
|
@krousey |
|
I think this is release note worthy, since it changes user facing behavior of create. |
|
Everything LGTM. Any other items you felt were worthy of an additional look? |
|
@smarterclayton Nope, I think this is done. Thanks! |
|
GCE e2e build/test passed for commit b5235bc. |
|
Automatic merge from submit-queue |
#16764 #3955
This is a series of changes to allow kubectl create to use discovery-based REST mapping and dynamic clients.
cc @kubernetes/sig-api-machinery
Release note:
This change is