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

Exec plug-in not found error needs to be more descriptive #5676

Open
kriswuollett opened this issue Apr 23, 2024 · 2 comments
Open

Exec plug-in not found error needs to be more descriptive #5676

kriswuollett opened this issue Apr 23, 2024 · 2 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@kriswuollett
Copy link

kriswuollett commented Apr 23, 2024

What happened?

I've written multiple alpha exec plugins using bash scripts. They work fine on Linux (debian-12) with kustomize v5.4.1. However running the same build command on macOS with either the homebrew v5.4.1 or the direct download binary version of v5.4.1 it fails with an error about not being able to find the plugin.

It's as if the command line parameter help for those options were compiled in, but the updated logic was not:

kris@MacBook-Air metallb % ./kustomize version                                     
v5.4.1
kris@MacBook-Air metallb % ./kustomize build --help | grep alpha                   
      --enable-alpha-plugins            enable kustomize plugins
kris@MacBook-Air metallb % ./kustomize build --help | grep exec 
      --as-current-user                 use the uid and gid of the command executor to run the function in the container
      --enable-exec                     enable support for exec functions (raw executables); do not use for untrusted configs! (Alpha)
      --helm-command string             helm command (path to executable) (default "helm")

Copying an example of one of my generators below that exhibits this problem.

What did you expect to happen?

The macOS build of kustomize runs identically to the Linux version under these options, so that I can test mini versions of my clusters locally on my mac... without looking into a workaround of running kustomize in a Linux docker container.

How can we reproduce it (as minimally and precisely as possible)?

kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: metallb-system

generators:
  - l2AddressPool.yaml

l2AddressPool.yaml

apiVersion: dockerL2AddressPool
kind: L2AddressPoolGenerator
metadata:
  name: local
  annotations:
    config.kubernetes.io/function: |
      exec: 
        path: ./plugins/docker-l2-address-pool.sh
spec:
  dockerNetwork: local

./plugins/docker-l2-address-pool.sh

#!/usr/bin/env bash

set -eou pipefail

resourceList=$(cat)

echo "$resourceList" >/tmp/resourceList.yaml

dockerNetwork=$(echo "$resourceList" | yq e '.functionConfig.spec.dockerNetwork' -)

dockerNetworkSpec=$(docker network inspect "$dockerNetwork" | jq '.[] | select(.Name == "'"$dockerNetwork"'")')

cidr_block=$(echo "$dockerNetworkSpec" | jq '.IPAM.Config[0].Subnet' | tr -d '"')
cidr_base_addr=${cidr_block%???}
ingress_first_addr=$(echo "$cidr_base_addr" | awk -F'.' '{print $1,$2,255,1}' OFS='.')
ingress_last_addr=$(echo "$cidr_base_addr" | awk -F'.' '{print $1,$2,255,254}' OFS='.')
ingress_range=$ingress_first_addr-$ingress_last_addr
cat <<EOF
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: $dockerNetwork
spec:
  addresses:
  - $ingress_range
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: $dockerNetwork
spec:
  ipAddressPools:
  - $dockerNetwork
EOF

Run in shell:

docker network create local
kustomize build --enable-alpha-plugins --enable-exec .

Expected output

---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: local
  namespace: metallb-system
spec:
  addresses:
  - 172.18.255.1-172.18.255.254
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: local
  namespace: metallb-system
spec:
  ipAddressPools:
  - local

Actual output

Error: loading generator plugins: failed to load generator: unable to find plugin root - tried: ('<no value>'; homed in $KUSTOMIZE_PLUGIN_HOME), ('<no value>'; homed in $XDG_CONFIG_HOME), ('/Users/kris/.config/kustomize/plugin'; homed in default value of $XDG_CONFIG_HOME), ('/Users/kris/kustomize/plugin'; homed in home directory)

Kustomize version

v5.4.1

Operating system

MacOS

@kriswuollett kriswuollett added the kind/bug Categorizes issue or PR as related to a bug. label Apr 23, 2024
@k8s-ci-robot
Copy link
Contributor

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.

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.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Apr 23, 2024
@kriswuollett
Copy link
Author

Seems to be a usage error on my part, but the error message was not informative. I noticed that another one of my modules worked and slowly morphed it into the example above. The incorrect config was either lack of a namespace, or I had included things in generators which should have been in resources accidentally while I as debugging.

Instead updating title to exec plugin errors need to be more descriptive, i.e., what exact namespace / name / path was expected to be present. The above error seems like it writes the old/deprecated error regarding Go plugins, if any method of plugin lookup did not work.

@kriswuollett kriswuollett changed the title macOS builds seem to not support the advertised --enable-alpha-plugins --enable-exec options Exec plug-in not found error needs to be more descriptive Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants