OCPBUGS-44507: Check public zone for stray record set #9365
Conversation
openshift-ci-robot
added
jira/valid-reference
|
@rna-afk: This pull request references Jira Issue OCPBUGS-44507, 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. |
|
/jira refresh |
|
@rna-afk: This pull request references Jira Issue OCPBUGS-44507, which is invalid:
Comment 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. |
|
/jira refresh |
openshift-ci-robot
added
jira/valid-bug
|
@rna-afk: This pull request references Jira Issue OCPBUGS-44507, which is valid. The bug has been moved to the POST state. 3 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. |
rna-afk
force-pushed
the
destroy_basedomain_records
branch
from
003e406 to
97fa94a
Compare
|
If I understand this approach correctly, I think there is a non-zero chance to delete a record set that belongs to a different cluster. I'm not 100% certain that could happen, but if the crtieria for deletion does not include the infra id that risk really increases. Azure is unique among cloud providers in allowing metadata to be attached to record sets. We can use that as a surefire method to determine that a record set is the correct one to delete. i.e. make sure record sets are labeled at creation and check the label at deletion. |
rna-afk
force-pushed
the
destroy_basedomain_records
branch
from
97fa94a to
6555096
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
rna-afk
force-pushed
the
destroy_basedomain_records
branch
from
6555096 to
055ab58
Compare
rna-afk
force-pushed
the
destroy_basedomain_records
branch
from
055ab58 to
d8ac8a4
Compare
rna-afk
force-pushed
the
destroy_basedomain_records
branch
from
d8ac8a4 to
3d549df
Compare
The azure destroyer checks for all the record sets present in the resource group and deletes them. But in the case where the resource group is destroyed before the destroy cluster is called, there will be stray record sets that don't get cleaned up. This frequently occurs in the azure test environment where the reaper deletes the resource group after sometime but fails to clean up these stray record sets. Adding the fix in the off chance this scenario happens in the customer world.
rna-afk
force-pushed
the
destroy_basedomain_records
branch
from
3d549df to
5b91b6b
Compare
|
@rna-afk: 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. |
The azure destroyer checks for all the record sets present in the resource group and deletes them. But in the case where the resource group is destroyed before the destroy cluster is called, there will be stray record sets that don't get cleaned up. This frequently occurs in the azure test environment where the reaper deletes the resource group after sometime but fails to clean up these stray record sets.
Adding the fix in the off chance this scenario happens in the customer world.