Upgrade to ingress-nginx v1.2.1

[samkulkarni20]

Based off of upstream tag controller-v1.2.1

Disclaimer: This PR is based off of the self exploration/learning & some documentation resources shared by @snasovich. A detailed review is advised.

Steps followed:

1. Fork rancher/ingress-nginx repo to personal github account
2. Clone the fork & checkout branch nginx-1.2.x-fix
3. Add rancher fork & upstream kubernetes/ingress-nginx remotes. Also fetch updates from these remote locations

git remote add upstream https://github.com/kubernetes/ingress-nginx
git remote add rancher https://github.com/rancher/ingress-nginx.git
git fetch --all

4. Rebase onto upstream tag controller-v1.2.1

git rebase --onto controller-v1.2.1 upstream/main

5. Resolve conflicts & push

git rebase --continue
git push --force-with-lease

Why rebase & not merge?

Since this branch is based off of upstream repo, rebase is always a better strategy instead of merging. This way we always have all the customizations handy & they become very easily manageable. With continued merging the git history gets clunky over a period of time. This makes managing customizations during merge conflicts very tedious.

[snasovich]

@samkulkarni20 , build is failing, could you please look into this?

[samkulkarni20]

@snasovich I've resolved the build issue, but I'm not sure if the root cause of the build failure will have have any implications while using the ingress.
CC: @kinarashah @superseb

[superseb]

@samkulkarni20 I expect to see only upstream commits that need to be added because we already made a 1.2.0 and released it. So I don't expect all of our commits to show in the list of commits as they are already in.

Regarding the build failure, if something changed upstream that causes the build to fail, we need to know why its broken and the root cause should be in this PR as we probably need to cherry-pick this commit for the next version (or if possible, see if there is a better solution if the root cause is known)

[samkulkarni20]

Hi @superseb, You see our commits because I rebased this branch with upstream tag. You can see more details & reason I chose to rebase in the issue description.

Regarding the build failure, I'm looking into getting more information. It did happen due to an upstream update.

[superseb]

@samkulkarni20 I used the current nginx-1.2.x-fix branch and cleanly cherry-picked everything starting from v1.2.0 from upstream, what conflicts did you run into?

[samkulkarni20]

I meant that as a general experience, rather than an occurrence in this case.
JFYI, I'm mostly unaware of the process to follow for updating this repo, like I mentioned in the disclaimer in the description. I'm just trying to get this going, while Kinara is away, to the best of my understanding from a confluence page that @snasovich had shared. If you're aware of the complete procedure & details around updating this repo, I would love to learn it from you.

For the build failure, looks like the upstream change was only to fix the tests run using github actions. Upstream PRs: kubernetes#8566
kubernetes#8569

[kinarashah]

@superseb I could be wrong but thought we wanted rancher changes cherry-picked on top, so we start with upstream tag and then cherry-pick rancher commits so even if the branch already existed, we have them separated right away on a git log.
We don't need to look at anything below the tag v1.2.1 in this case but if we just rebased then we'd have v1.2.0 followed by rancher changes and then upstream stuff for v1.2.1. Did something similar for v1.1.1 as well, #82. Would like to know your thoughts on if it makes sense or we should do this only for the first time we have a branch and then rebase? The net change remains the same, it's just how commits history show up for us.

@samkulkarni20 I looked at upstream changes, since they add install gingko in build/run-in-docker.sh, the change you made looks good to me. Wondering why they didn't run into the same issue but our build process is very different than upstream so I'd say this should suffice.

[superseb]

I'm fine either way, cherry picking the commits between 1.2.0 and 1.2.1 works as well but you can also get latest and then cherry pick ours on top, I don't see a difference in either. I don't like the rebase approach where everything gets a new commit.

[kinarashah]

@samkulkarni20 Could we start with controller-v1.2.1 upstream and cherry-pick rancher changes on top? That way everything won't get a new commit. Example PR: nginx-1.2.x-fix...kinarashah:v121, the commit hashes are same as when we first committed them.

[samkulkarni20]

I'll close this PR & create a new one, with a new branch.

[kinarashah]

@superseb Looks like even if we cherry-pick changes,