Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Doc: Add note for rename behavior of IngressGroup #3283

Merged
merged 3 commits into from
Aug 7, 2023
Merged

Doc: Add note for rename behavior of IngressGroup #3283

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
66d49f1
Add warning for rename behavior of IngressGroup
yubingjiaocn Jul 17, 2023
c3eaa90
Change wording per suggestion from code review
yubingjiaocn Jul 19, 2023
85ea2b1
Apply grammar suggestions from code review
yubingjiaocn Jul 30, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions docs/guide/ingress/annotations.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,6 +79,13 @@ By default, Ingresses don't belong to any IngressGroup, and we treat it as a "im
other Kubernetes users may create/modify their Ingresses to belong to the same IngressGroup, and can thus add more rules or overwrite existing rules with higher priority to the ALB for your Ingress.

We'll add more fine-grained access-control in future versions.

!!!note "Rename behavior"
The ALB for an IngressGroup is found by searching for an AWS tag `ingress.k8s.aws/stack` tag with the name of the IngressGroup as its value. For an implicit IngressGroup, the value is `namespace/ingressname`.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. i think we can remove this "There is no way to rename an existing IngressGroup while keeping ALB", since
    • the following text already clarified the recreation behavior.
    • technically there is a way, e.g. by manually change the AWS Tags on the existing provisioned ALB. But i don't want to call this hacky solution out in this document.
  2. When the groupName of IngressGroup for Ingress is changed, the Ingress will be moved to new IngressGroup and supported by ALB for the new IngressGroup. If ALB for the new IngressGroup doesn't exist, a new ALB will be created. If the old IngressGroup no longer contain any Ingresses, ALB for old IngressGroup will be deleted, and deletion protection of ALB will be ignored.
  3. we can remove the "If an IngressGroup has only one Ingress (or IngressGroup is not explicit specified), changing name of IngressGroup will cause recreation of Load Balancer. If an IngressGroup has no Ingress, the corrsponding ALB will be removed. In both cases, deletion protection of ALB will be ignored." given the Refactor josh #2 clarified it.

When the groupName of an IngressGroup for an Ingress is changed, the Ingress will be moved to a new IngressGroup and be supported by the ALB for the new IngressGroup. If the ALB for the new IngressGroup doesn't exist, a new ALB will be created.

If an IngressGroup no longer contains any Ingresses, the ALB for that IngressGroup will be deleted and any deletion protection of that ALB will be ignored.

!!!example
```
Expand Down