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

galley validatingwebhook not deployed when namespace isn't istio-system #13625

mattmi88 opened this issue Apr 25, 2019 · 3 comments


2 participants
Copy link

commented Apr 25, 2019

Bug description

The helm chart for galley fails to deploy the validatingwebhookconfiguration object when galley is deployed to a namespace other than istio-system.

This problem was fixed in PR #7477 in July, 2018 but the commit has never been merged into a release since then. It is a simple one-line fix. The update is not in master and is currently not in 1.1.4.

Although galley doesn't crash, the feature is essentially disabled.

Expected behavior

The helm chart should configure galley with arg: --deployment-namespace={{ .Release.Namespace }}

Steps to reproduce the bug

  1. Deploy istio to a namespace other than istio-system.
  2. Use kubectl get validatingwebhookconfiguration and see that the istio-galley object does not exist.
  3. Inspect the galley pod logs and see that the default value istio-system is used to locate the service to test the webhook api. Also note that galley does not deploy the validatingwebhookconfiguration object.

Version (include the output of istioctl version --remote and kubectl version)

  • Istio: 1.1.1
  • Kubectl: 1.13.3

How was Istio installed?

Via helm using canonical values.yaml file.

Environment where bug was observed (cloud vendor, OS, etc)

  • Amazon EKS with Kubernetes 1.12.7.
  • Local Kubernetes DinD cluster with Kubernetes 1.13.3.

Additionally, please consider attaching a cluster state archive by attaching
the dump file to this issue.


This comment has been minimized.

Copy link

commented Apr 25, 2019

It looks like the mentioned PR was merged into release-1.0, but never got back into master or reflected from there to release-1.1. Seems this needs to be cherry-picked to those two branches. I can create those PRs.


This comment has been minimized.

Copy link

commented Apr 25, 2019

Hey @ericvn - Thanks for following up on this so quickly.

I wonder if anyone has gone through the other commits in that branch to find any that didn't make it into master and should have.

@ericvn ericvn added this to the 1.2 milestone May 6, 2019


This comment has been minimized.

Copy link

commented May 7, 2019

Cherry picks are completed to master (in istio/installer) and in 1.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.