Specifying group order smaller than the default (i.e. 0)

[hazim1093]

Problem

I have an ingress with a rule that needs to be evaluated first in the ALB.
In order to ensure that, I would have to assign group orders to all other ingresses, so that this particular ingress has the smallest order which is "0".
It would be convenient if we could set the order such that one ingress has the smallest order instead of specifying the order for all other present and future ingresses.

I faced this issue while creating a common ingress for redirecting HTTP to HTTPS for all routes, and some common annotations instead of adding boilerplate config to each ingress. ( This request/issue is already tracked in #1768 )

Proposed Solution

If a new order is introduced which is smaller than the default, it would solve the problem.
e.g. order -1, the default would still be 0 so all rules will be added after that.

Current Solution / Workaround

By default the rules are ordered based on the lexical order of Ingress’s namespace/name.
I created a dummy namespace (e.g. 1-ns) such that this ingress rule is always evaluated first and created this ingress in that namespace.

Example Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dev-loadbalancer-default
  namespace: 1-ns
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/group.name: "dev"
    alb.ingress.kubernetes.io/tags: Environment=dev,Name=dev
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'
spec:
  rules:
    - http:
        paths:
          - path: /*
            pathType: Prefix
            backend:
              service:
                name: ssl-redirect
                port:
                  name: use-annotation

[M00nF1sh]

@hazim1093
we are introducing a new way to configure HTTP->HTTPS redirection: #1837, so you only need to add a single annotation alb.ingress.kubernetes.io/ssl-redirect: '443' to one of the Ingresses within IngressGroup for the task. This feature will be release in v2.2.0

with above feature, would you still have this feature request?
If it's still needed, what's your preference of allow negative order(the proposed solution here) vs a controller level flag to set the default order (e.g. you can set it to 500). i feel allow negative order seems more flexible for per ingressGroup, but a negative order seems a little weird..

[hazim1093]

@M00nF1sh
That would make solving this particular case easier, but even then I believe the common configurations should be moved to a common place rather than being able to specify them on one of the ingresses.

In a scenario where you have multiple ingresses, having such annotations on of them would make other ingresses not be "self-sufficient". Looking at such an ingress without the common annotations, it would be difficult to see all the aspects that affect the ingress. Similarly if it is moved to another AWS LB controller or another environment, it would be hard to make sure all the common annotations (which could be spread across a number of ingresses) are present.

On the other hand, having such annotations on all ingresses would create duplication and maybe even conflicts if different ingresses specify the same annotation and its value is changed in one of the ingresses over time.

I agree tinkering with the order seems a bit weird whether negative one or defining a custom starting order. Instead, we could introduce an IngressGroup custom resource would be responsible for provisioning the LB and have all common configuration. Or it might be even better if we can use the IngressClass resource for this, i.e. specifying common annotations or config in the IngressClass instead of the Ingress.
What are your thoughts on that ?

[hazim1093]

I guess I diverted more towards #1768 in the discussion.

Setting the default order for the controller seems to be a good idea as well, if there is a certain case where one ingress should be processed before all the others with the default order.
Wondering if that would confuse people if the default order is different for different deployments of the controller.

[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.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kishorj]

/reopen

[k8s-ci-robot]

@kishorj: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[MadhavJivrajani]

/remove-kind design
/kind feature
kind/design is migrated to kind/feature, see kubernetes/community#6144 for more details

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.