kubernetes: API Export Parameter Ignored for List

/kind bug

What happened:

When running kubectl get secrets --export -o yaml, no metadata is stripped and no export logic is applied. The same is true for all API types.

What you expected to happen:

Behavior should match getting individual secrets, (kubectl get secret foo --export -o yaml) and export logic should be applied even when listing resources.

How to reproduce it (as minimally and precisely as possible):

Using a hack/local-up-cluster.sh cluster:

echo -n "admin" > ./username.txt
echo -n "1f2d1e2e67df" > ./password.txt
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
kubectl get secrets -o yaml

You will see various fields in the output such as creationTimestamp, namespace, UID, all of which should be filtered out when exporting an object. (which they are when doing an individual GET)

Anything else we need to know?:

Via @deads2k the export option may have been missed on ListOptions, or we should be passing ExportOptions everywhere we’re passing ListOptions.

Working on a PR to fix this issue.

Environment:

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.2.709+6fdf0e4157c76e-dirty", GitCommit:"6fdf0e4157c76eeaf7619e8411ee7231305f7d87", GitTreeState:"dirty", BuildDate:"2017-07-24T13:51:15Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.0-alpha.2.709+6fdf0e4157c76e-dirty", GitCommit:"6fdf0e4157c76eeaf7619e8411ee7231305f7d87", GitTreeState:"dirty", BuildDate:"2017-07-24T13:51:15Z", GoVersion:"go1.8.1", Compiler:"gc", Platform:"linux/amd64"}

Cloud provider or hardware configuration**: N/A
OS (e.g. from /etc/os-release): Fedora 26
Kernel (e.g. uname -a): Linux wrx 4.11.9-300.fc26.x86_64 #1 SMP Wed Jul 5 16:21:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 19 (18 by maintainers)

Most upvoted comments

Export is already represented in the content type negotiation options in MediaTypeOptions. Right now that is done late - but fortunately, the structure for the handling is already there in transformResponseObject in response.go. Export is a post transformation, so it belongs with that method (some generalization of this method will be useful in the future, but for now is kept deliberately simple and stupid)

On Mon, Aug 14, 2017 at 7:32 AM, Dr. Stefan Schimanski < notifications@github.com> wrote:

We’ll try to see if we can use the content-type negotiation from @smarterclayton https://github.com/smarterclayton first

To see whether we are on the same page:

Content-type negotiation means to introduce something like Accept: application/json;export=true or Accept: application/json;format=export. A client then can request just the export version passing Accept: application/json;export=true or Accept: application/json;export=true, application/json if it has a fallback for endpoints without the export implementation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/kubernetes/issues/49497#issuecomment-322167293, or mute the thread https://github.com/notifications/unsubscribe-auth/ABG_p1lgbbMTvHbkMObRIkNjlipXX5Vnks5sYDBrgaJpZM4OhOvv .

smarterclayton on Aug 14, 2017