Feature Request: Improve ownership of ingress resources in multi-ingress-controller clusters

[nicksardo]

Currently, users may accidentally cause ingress controller sync-loops (fighting) simply by adding a controller to a cluster and not having the ingress.class annotation set on an ingress. While it's documented that in clusters with multiple controllers all ingress resources must have the ingress.class annotation set to something specific, this isn't a great user experience.

One option is to have controllers claim ownership of ingress objects - either by setting the ingress.class annotation with the controller's type or use a new annotation. If the user wants to move an ingress from one controller to another, they would need to manually change this flag. Of course, this requires implementation changes in all ingress controllers.

Other ideas or missing anything?

@aledbf @thockin @nikhiljindal @csbell

[thockin]

The larger design would be more like StorageClass. We have to figure out the future of Ingress wrt lowest-common API vs annotations vs specific Kinds before we invest in that design, I think.

Setting the class or an ownership tag is a possible first-step, but we need to think through the race between controllers both trying to set that..

[aledbf]

@nicksardo ingress claim was one of the ideas of @bprashanth to fix this kubernetes/kubernetes#30151

[nicksardo]

The larger design would be more like StorageClass. We have to figure out the future of Ingress wrt lowest-common API vs annotations vs specific Kinds before we invest in that design, I think.

Indeed, this is just a smallest-fix-possible for the current situation.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close