When an application is installed from a Helm chart, Helm creates a list of manifests from the chart and simply sends the manifests into the cluster - leaving it to Kubernetes to handle. The following scenario doesn't currently allow the chart to successfully deploy because of the Nginx admission webhook:

1. Manifest A is a `Job` that creates a `Secret` in the cluster.
2. Manifest B is an `Ingress` with annotation `nginx.ingress.kubernetes.io/auth-tls-secret: secret-created-by-job`.
3. The `Job` manifest and the `Ingress` manifest go into the cluster at essentially the same time.
4. The Nginx ingress admission webhook sees that the `nginx.ingress.kubernmetes.io/auth-tls-secret` annotation refs a secret that does not exist yet. And so the webhook rejects the ingress.
5. The Helm chart then does not fully deploy (no ingresses) and so the app is unusable.
6. A second later the Job completes and the secret is present.

I can think of a couple ways to address this:

1. Introduce configurable (via cmdline) exponential backoff to the admission webhook to retry all ingresses
2. Introduce an annotation to the ingress that causes the admission webhook to retry that specific ingress
3. Introduce an annotation to the ingress that causes the admission webhook to **not** validate that specific ingress

If you think any of these approaches are valid I would be happy to look into submitting a PR. Thanks.

Better support for Helm installs
This is a GitHub Issue
repo:ingress-nginx
owner:kubernetes
Title : Better support for Helm installs
Issue date:

--- start body ---
When an application is installed from a Helm chart, Helm creates a list of manifests from the chart and simply sends the manifests into the cluster - leaving it to Kubernetes to handle. The following scenario doesn't currently allow the chart to successfully deploy because of the Nginx admission webhook:

1. Manifest A is a `Job` that creates a `Secret` in the cluster.
2. Manifest B is an `Ingress` with annotation `nginx.ingress.kubernetes.io/auth-tls-secret: secret-created-by-job`.
3. The `Job` manifest and the `Ingress` manifest go into the cluster at essentially the same time.
4. The Nginx ingress admission webhook sees that the `nginx.ingress.kubernmetes.io/auth-tls-secret` annotation refs a secret that does not exist yet. And so the webhook rejects the ingress.
5. The Helm chart then does not fully deploy (no ingresses) and so the app is unusable.
6. A second later the Job completes and the secret is present.

I can think of a couple ways to address this:

1. Introduce configurable (via cmdline) exponential backoff to the admission webhook to retry all ingresses
2. Introduce an annotation to the ingress that causes the admission webhook to retry that specific ingress
3. Introduce an annotation to the ingress that causes the admission webhook to **not** validate that specific ingress

If you think any of these approaches are valid I would be happy to look into submitting a PR. Thanks.

--- end body ---
