Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change kubectl create to use dynamic client #30250

Merged
merged 10 commits into from
Aug 17, 2016

Conversation

krousey
Copy link
Contributor

@krousey krousey commented Aug 8, 2016

#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:

kubectl will no longer do client-side defaulting on create and replace.

This change is Reviewable

@krousey krousey added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Aug 8, 2016
@krousey krousey added this to the v1.4 milestone Aug 8, 2016
@k8s-github-robot k8s-github-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. release-note-label-needed labels Aug 8, 2016
@@ -80,6 +80,8 @@ func NewRESTMapper(groupResources []*APIGroupResources, versionInterfaces meta.V
// TODO only do this if it supports listing
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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@k8s-github-robot k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 9, 2016
@wojtek-t
Copy link
Member

wojtek-t commented Aug 9, 2016

@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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shallow copy worries me. We're still sharing the URL pointer, the client, BackoffManager func.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I'll change this to call back into NewRESTClient

@smarterclayton
Copy link
Contributor

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.

@deads2k deads2k assigned smarterclayton and unassigned deads2k Aug 10, 2016
@krousey
Copy link
Contributor Author

krousey commented Aug 10, 2016

@smarterclayton @wojtek-t

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?

@smarterclayton
Copy link
Contributor

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.

@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Aug 11, 2016
return nil, fmt.Errorf("unable to decode %q: %v [%v]", source, err, gvk)
}

obj, versioned := versions.Last(), versions.First()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@smarterclayton does this look better?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, a million times.

@krousey
Copy link
Contributor Author

krousey commented Aug 11, 2016

@smarterclayton I've reworked this a good bit, and I think it's in a good spot for another pass.

@smarterclayton
Copy link
Contributor

I think test-cmd is sufficient. Sure - makes it easier to review.

Kris added 3 commits August 15, 2016 14:18
This will allow people to override the default parameter codec and still
pass the resulting client with something that accepts *dynamic.Client.
@krousey
Copy link
Contributor Author

krousey commented Aug 15, 2016

Fun fact: all of our objects should be json.Marshal-able. Otherwise kubectl's annotation config saving is wrong. So you're going to see that in the next update to this PR.

@smarterclayton
Copy link
Contributor

Definitely internal objects should fail / be horribly incompatible if
someone tries to marshal them. Did you find the apply internal version bug?

On Mon, Aug 15, 2016 at 6:27 PM, krousey notifications@github.com wrote:

Fun fact: all of our objects should be json.Marshal-able. Otherwise
kubectl's annotation config saving is wrong. So you're going to see that
in the next update to this PR.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30250 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p1exBpx7bE7SHD3IxtRGw-3IPLFvks5qgOfMgaJpZM4Jfj_0
.

@krousey
Copy link
Contributor Author

krousey commented Aug 15, 2016

@smarterclayton I don't think so. My change is only using a single runtime.Unstructured object. So info.Object == info.VersionedObject. And the unstructured types do not marshal to the appropriate JSON by default. There's also a bunch of comments in the apply code warning of the assumption.

I'm just adding marshal handlers to the Unstructured and UnstructuredList.

@krousey
Copy link
Contributor Author

krousey commented Aug 16, 2016

@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?

@krousey krousey added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-label-needed labels Aug 16, 2016
@krousey
Copy link
Contributor Author

krousey commented Aug 16, 2016

@smarterclayton one last pass?

@k8s-github-robot
Copy link

@krousey
You must link to the test flake issue which caused you to request this manual re-test.
Re-test requests should be in the form of: k8s-bot test this issue: #<number>
Here is the list of open test flakes.

1 similar comment
@k8s-github-robot
Copy link

@krousey
You must link to the test flake issue which caused you to request this manual re-test.
Re-test requests should be in the form of: k8s-bot test this issue: #<number>
Here is the list of open test flakes.

@smarterclayton
Copy link
Contributor

I think this is release note worthy, since it changes user facing behavior of create.

@smarterclayton
Copy link
Contributor

Everything LGTM. Any other items you felt were worthy of an additional look?

@krousey
Copy link
Contributor Author

krousey commented Aug 16, 2016

@smarterclayton Nope, I think this is done. Thanks!

@smarterclayton smarterclayton added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 16, 2016
@k8s-bot
Copy link

k8s-bot commented Aug 17, 2016

GCE e2e build/test passed for commit b5235bc.

@k8s-github-robot
Copy link

Automatic merge from submit-queue

@k8s-github-robot k8s-github-robot merged commit 4b5fd43 into kubernetes:master Aug 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants