cmd/get: -o=custom-columns causes -L/--label-columns to be silently ignored

[ahmetb]

What happened:

Specifying both -o=custom-columns and -L causes to kubectl causes the -L/--label-columns flag to be silently ignored (and there's no warning/error printed).

What you expected to happen: If the user is providing a flag, it should be used; otherwise, it should be failing.

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

kubectl get ns -L kubernetes.io/metadata.name -o=custom-columns=NAME:.metadata.name
NAME
default
kube-node-lease
...

kubectl get ns  -L kubernetes.io/metadata.name
NAME                 STATUS   AGE   METADATA.NAME
default              Active   73d   default
kube-node-lease      Active   73d   kube-node-lease
kube-public          Active   73d   kube-public

Anything else we need to know?: N/A

Environment:

• Kubernetes client and server versions (use kubectl version): v1.35.0
• Cloud provider or hardware configuration: irrelevant
• OS (e.g: cat /etc/os-release): macOS

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[brianpursley]

Interesting.

I think this would provide the output you are trying to achieve...

kubectl get ns -o=custom-columns=NAME:.metadata.name,METADATA.NAME:.metadata.labels."kubernetes\.io/metadata\.name"

But I agree it should not silently ignore a flag you specified.

Probably the simplest thing to do would be to fail with a message saying you can't use --label-columns with this printer. It would be similar to what --show-labels does today:

% kubectl get ns -o=custom-columns=NAME:.metadata.name --show-labels
error: --show-labels option cannot be used with custom-columns=NAME:.metadata.name printer

Whether these flags should work with custom columns, I guess that is up for discussion.

[CarterMoment]

I reproduced the bug in my env:

kubectl v1.32.x, macOS Apple Silicon
kind cluster v0.27.0

The divergence happens in PrintFlags.ToPrinter() in pkg/cmd/get/get_flags.go

When -o=custom-columns is specified, HumanPrintFlags rejects it and CustomColumnsPrinter wins. Since ColumnLabels only ever flow into HumanPrintFlags, they never reach CustomColumnsPrinter and are silently dropped.

Erroring out would be easiest, but open to a fix that merges the columns.

I would like to put up a PR with the decided solution.

[CarterMoment]

cc @mpuckett159 @ardaguclu I would like to take this

[ahmadmaha02]

I have a fix in progress that wires --label-columns into the custom-columns printer and appends label columns to -o custom-columns output (including label keys with dots). Added a unit test.

PR: kubernetes/kubernetes#138094

Test: go test ./staging/src/k8s.io/kubectl/pkg/cmd/get -run TestCustomColumnsPrinterAppendsLabelColumns

[ahmadmaha02]

Update: per SIG CLI review, the PR now errors when is used with (instead of appending label columns). PR: kubernetes/kubernetes#138094

[ahmadmaha02]

Update: per SIG CLI review, the PR now errors when --label-columns is used with -o custom-columns* (instead of appending label columns). PR: kubernetes/kubernetes#138094