Fix helm chart admissionReviewVersions regression

[aledbf]

What this PR does / why we need it:

We need to release 0.36.0 before the switch to v1

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Which issue/s this PR fixes

fixes #6179

How Has This Been Tested?

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added tests to cover my changes.
• All new and existing tests passed.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aledbf

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• charts/ingress-nginx/OWNERS [aledbf]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jaalle]

Hello @aledbf,

Has latest been updated? We just pulled latest hoping to confirm this fixes the problem we began observing yesterday and it is still at 0.35.0. We pull from this URL:
https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/deploy.yaml

[aledbf]

@jaalle this is a change in the helm chart, not the ingress controller image

Edit: I just push a PR to keep the static manifests in sync

[aledbf]

We pull from this URL:
https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/baremetal/deploy.yaml

You should not pull from master ;) and use a tag.

[jaalle]

Hello @aledbf,

Are you referring to a specific version, as documented here:
https://kubernetes.github.io/ingress-nginx/deploy/#bare-metal

e.g.:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.35.0/deploy/static/provider/baremetal/deploy.yaml

If so, we can do that but we can't monitor all projects for upgrades so our strategy has been to basically package a known good in an ansible role, then pull latest from master, diff the two, and deploy latest if there is a diff. This way we retain the ability to manually delete and apply known good when there is a problem, but by default deploy latest when building a cluster.

[aledbf]

If so, we can do that but we can't monitor all projects for upgrades so our strategy has been to basically package a known good in an ansible role, then pull latest from master, diff the two, and deploy latest if there is a diff.

Keep in mind master could point to a staging image and not a release.

[jaalle]

Keep in mind master could point to a staging image and not a release.

Do you have a static manifest for the latest release? If not, consider this a vote for one.