[release-4.16] OCPBUGS-54165: aws: fix NLB creation in secret regions #9595
Conversation
This is leftover from before CAPA had support for a public LB as the secondary controlPlane load balancer. We had to configure the AWSCluster in such a way the primary load balancer would either be `InternetFacing` if publish was set to "External" or `Internal` otherwise. Now the primary LB is always `Internal` and the secondary LB only exists when publish is "External".
This function was doing way more than its name says: it was creating records in both private and public zones. The argument names were also not very descriptive and very hard to decipher at a glance. This change moves the logic out of the function and into the aws `InfraReady` hook. This not only makes the logic more readable, but it also paves the way for the use of Classic Load Balancer types.
Tagging the resource as "owned" should be part of the creation.
This should remove any ambiguity/misunderstanding when the field names are not clear enough.
|
@openshift-cherrypick-robot: Jira Issue OCPBUGS-53459 has been cloned as Jira Issue OCPBUGS-54165. Will retitle bug to link to clone. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
changed the title
openshift-ci-robot
added
jira/severity-critical
|
@openshift-cherrypick-robot: This pull request references Jira Issue OCPBUGS-54165, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
There was a problem hiding this comment.
I think the revision of CAPA pinned on 4.16 branch does not have the security group fix. We would need upstream CAPA to backport the fix to v2.6 (due to go version requirement) and bump CAPA version here too?
|
@openshift-cherrypick-robot: The following tests failed, say
Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
|
/retest-required |
|
/jira refresh |
openshift-ci-robot
added
jira/valid-bug
|
@barbacbd: This pull request references Jira Issue OCPBUGS-54165, which is valid. The bug has been moved to the POST state. 7 validation(s) were run on this bug
Requesting review from QA contact: In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: barbacbd The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/label cherry-pick-approved |
openshift-ci
bot
added
the
cherry-pick-approved
question 🤔: just following up, I see the vendored provider code on branch Is that fix now not necessary (as in security group is now supported in secret region) or am I saying non-sense haha 😅? |
This is a good catch and it looks like you are correct: we did not backport that CAPA bump. I took a look through the bugs and there are no linked customer cases. I would say, at this stage, I wouldn't worry about that backport unless it is asked for. |
|
/lgtm |
|
/label backport-risk-assessed |
openshift-ci
bot
added
the
backport-risk-assessed
This is an automated cherry-pick of #9071
/assign patrickdillon