kubectl
kubectl copied to clipboard
kubernetes
Cannot reference root object in jsonpath filter expression
What happened:
kubectl doesn't seem to understand the root object $ when used in jsonpath filters eg .something.items[?(@.name==$.something.value)]. I wanted to use a value from the input to filter on rather than a literal string value. This seems to be supported in other jsonpath implementations.
What you expected to happen:
My usecase was trying to get kubectl config view to output both the current context name and the current namespace in one command.
How to reproduce it (as minimally and precisely as possible):
The command I'm using is below along with the actual and expected output:
> kubectl config view --output=jsonpath=$'{.current-context}: {.contexts[?(@.name == $[\'current-context\'])].context.namespace}'
Actual: "minikube: "
Expected "minikube: default"
Anything else we need to know?:
I can solve this with jq, but was hoping to not add another dependency to my script since this (filters and root object) seems to be supported. The two parts work independently as well.
> kubectl config view --output=jsonpath='{.contexts[?(@.name == "minikube")].context.namespace}'
default
> kubectl config view --output=jsonpath=$'{$[\'current-context\']}'
minikube
Environment:
- Kubernetes client and server versions (use
kubectl version):
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.0", GitCommit:"ab69524f795c42094a6630298ff53f3c3ebab7f4", GitTreeState:"clean", BuildDate:"2021-12-07T18:16:20Z", GoVersion:"go1.17.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.2-gke.1900", GitCommit:"d95ef8792724f6b489a64fe5c7d8f1fb3f9422bb", GitTreeState:"clean", BuildDate:"2022-07-15T09:24:44Z", GoVersion:"go1.18.3b7", Compiler:"gc", Platform:"linux/amd64"}
- Cloud provider or hardware configuration:
minikube - OS (e.g:
cat /etc/os-release):
NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
/triage accepted /kind feature
I'm investigating further but what I suspect is happening is that presently the jsonpath implementation used by kubectl (it is maintained in tree and is fairly limited unfortunately) does not expand jsonpath variables within filters, and so what is essentially being done by kubectl here is that it is looking for the literal current-context here, at the root of the config object, then trying to find .current-context.context.namespace which doesn't exist. The config view command using jsonpath allows for missing keys and so because it's missing nothing is returned, which is why you're seeing what you're seeing.
I believe that for the time being you will need to use jq, but i'm going to look into the possibility of either enabling this so that kubectl's implementation of jsonpath is more feature complete, or at the very least updating the docs you linked to so that it is more clear what is going on.
Accepting as a feature request for now, I will need to discuss more with the sig-cli group to see if it is of interest to get closer to spec compliance for this.
A work around to avoid using jq is to do the kubectl config view command twice as follows:
testvar=$(kubectl config view --output=jsonpath=$'{.current-context}')
kubectl config view --output=jsonpath="{.current-context}: {.contexts[?(@.name == '$testvar')].context.namespace}"
Now I'm not gonna pretend this is a great solution or anything but it works.
/close
Hopefully this worked please feel free to reopen if not and I can try to help further.
@mpuckett159: Closing this issue.
In response to this:
/close
Hopefully this worked please feel free to reopen if not and I can try to help further.
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/test-infra repository.
It does work for us, thanks. I understand the want to maintain in tree, and this is a bit of a niche ask anyway.
I'm actually looking at importing an external jsonpath implementation to start using so Some Day:tm: hopefully.