drop some ingress-nginx documentation

[danwinship]

kind of spinoff of #52937

This removes the "ingress-nginx with minikube" example (and doesn't replace it, since we don't want people using Ingress anyway), and one well-known annotation (which really had no reason to be in that file anyway)

@robscott @aojea @lmktfy

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	2308870
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-io-main-staging/deploys/690e12efe077450008b392aa
😎 Deploy Preview	https://deploy-preview-53110--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[robscott]

Thanks for handling this, I'd been meaning to get back to my PR, but this is a much clearer starting point.

[lmktfy]

I can't see good grounds for removing nginx.ingress.kubernetes.io/configuration-snippet from the list.

If we want to change our conventions, let's get SIG Docs to confirm it (and I recommend seeing if SIG Architecture have a concern, too).

/hold
pending an exception or policy change

[lmktfy]

nit: for this specific removal, I recommend back porting it

[danwinship]

Ingress-nginx defines around 150 annotations. Clearly it doesn't make sense to document exactly 1 of them here. (Especially if it's not even the 1 that is used in the other Ingress documentation.)

What conventions are you referring to? Is there a rule that says we're supposed to document every known annotation with a "*.k8s.io" name in this list?

[danwinship]

removed the annotation change; now this just removes the minikube example

[rikatz]

I will add a single comment here because I do think the nginx annotation should be removed.

The PR that added this annotation was on #43950 and if we take the "ownership model" I can't see any ingress-nginx maintainer (and I was one on that time) or anyone from sig-network (who are the effective people who know about specific network annotations and labels) to be tagged on this PR before merging it.

Speaking about risks: configuration-snippet was INTENTIONALLY removed and marked as risky because we wanted to keep people away from it, yet there was a decision to add it to the main Kubernetes docs.

I would very much request that this is reconsidered and this annotation is removed from the documentation, it doesn't make any sense at all on why it was added first.

[aojea]

I can't see good grounds for removing nginx.ingress.kubernetes.io/configuration-snippet from the list.

that is a legacy annotation that with current rules should have not be done, but we need to live with that.
The goal is precisely to avoid the misunderstanding you are having @lmktfy and that most people have, that is not an official API and not approved by SIG Network ... it should not be in the official docs

[aojea]

/lgtm
/approve

@lmktfy please let us know how to move forward with this, we are willing to follow the best practices and conventions, but we need to remove this false sensation of officiality on ingress-nginx

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aojea, robscott
Once this PR has been reviewed and has the lgtm label, please assign reylejano for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• content/en/docs/OWNERS

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

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: fcd3cf792aeb73944afbe8f554c6ebdea8935744

[rikatz]

/hold
@danwinship if possible can you remove (again) the annotation? then LGTM as well

[lmktfy]

Folks, especially SIG Network folks: I really don't want to see an unhelpful precedent set here.

Dropping the annotation explanation and marking it deprecated? Sure. Uncontroversial.

Taking a registered thing and removing it as if it never existed? It's a new thing, we have never done it. Please pick the easy route and just deprecate it for now.

In fact, if this weren't held, I would merge it, and then the argument about removing an existing annotation – that is actually used - could happen elsewhere.

Anyway, I am making this point because I think it doesn't serve our end users to delete registered annotations. We should keep a record, in more than Git history, that this was once something that our code recognised.

---

This is the only page with that special property, of being both documentation and our registration point. For any other page, I wouldn't object.

Timing is unfortunate. It is the weekend. I will be back online next week.

[danwinship]

/hold cancel
the annotation can be removed separately if we reach agreement on it. it doesn't need to block this PR