You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Getting: Failed deploy model due to ValidationError: Condition value 'very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long-name-ingress.foo.bar' contains a character that is not valid status code: 400, request id: 6414deaf-fede-45ad-9328-f6c5ebbcb9ed
Expected outcome
I would expect only the faulty ingress from not being reconsiled.
Environment
AWS Load Balancer controller version - v2.8.1
Kubernetes version - 1.29
Using EKS (yes/no), if so version? yes. eks.13
Additional Context:
We utilize the controller in dynamically provisioned environments where the domain name varies, making it difficult to predict if we’ll exceed the 63-character hostname limit. A faulty ingress not only fails to function but also prevents other environments from being provisioned.
Additionally, hitting the unique target group quota also prevents the controller from taking further actions.
Given that ingresses are not interconnected and are materialized as separate target groups and rules, I see no reason to block valid ingresses from being reconciled due to the presence of invalid ones. Allowing valid ingresses to proceed would mitigate the impact of these issues.
There is significant community demand for this functionality. Would it be possible to introduce this behavior as an opt-in feature, perhaps behind a toggle?
The text was updated successfully, but these errors were encountered:
Describe the bug
Faulty ingress prevents subsequent ingresses from reconsiling.
Steps to reproduce
Deploy
after that, deploy
Getting:
Failed deploy model due to ValidationError: Condition value 'very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long-name-ingress.foo.bar' contains a character that is not valid status code: 400, request id: 6414deaf-fede-45ad-9328-f6c5ebbcb9ed
Expected outcome
I would expect only the faulty ingress from not being reconsiled.
Environment
Additional Context:
We utilize the controller in dynamically provisioned environments where the domain name varies, making it difficult to predict if we’ll exceed the 63-character hostname limit. A faulty ingress not only fails to function but also prevents other environments from being provisioned.
Additionally, hitting the unique target group quota also prevents the controller from taking further actions.
Given that ingresses are not interconnected and are materialized as separate target groups and rules, I see no reason to block valid ingresses from being reconciled due to the presence of invalid ones. Allowing valid ingresses to proceed would mitigate the impact of these issues.
The problem can manifest in various forms, as evidenced by the following:
Issue #2669
Issue #2042
Issue #3870
There is significant community demand for this functionality. Would it be possible to introduce this behavior as an opt-in feature, perhaps behind a toggle?
The text was updated successfully, but these errors were encountered: