OCPBUGS-32776: Fix IBM Public Cloud DNS Provider Update Logic #1133

gcs278 · 2024-08-22T22:46:16Z

The IBM Public Cloud DNS provider (cis_provider.go) had a bug in createOrUpdateDNSRecord where it checked for the existence of a DNS record by filtering both DNS name and target. If the target was updated (e.g., due to a load balancer recreation), the logic would not match the existing DNS record. As a result, the function would attempt to create a new record, but fail because a record with that name already existed, as multiple DNS records with the same
name are not allowed in IBM Cloud DNS providers.

The fix is to remove the filtering by target and rely solely on filtering by name, as the name is the only attribute that needs to be unique.

This fix also includes a subtle fix in createOrUpdateDNSRecord of cis_provider.go to fall through to the create logic in the case of a not-found (404) error.

Additionally, the IBM DNS logic doesn't work for multiple targets and this creates unexpected and problematic results. The logic has been refactored to only create using the first target and it warns the user when multiple targets are set. This change is low risk since the Ingress Operator will never create a DNSRecord with multiple targets in desiredDNSRecord.

Additionally, modify TestScopeChange to check for Available=True after deleting the service to add test coverage for this issue.

This PR also includes some unit test fix up and missing unit test coverage for the IBM CIS Provider.

This resolves the same DNS issues for public PowerVS cloud as it uses the same logic.

openshift-ci-robot · 2024-08-22T22:46:21Z

@gcs278: This pull request references Jira Issue OCPBUGS-32776, which is invalid:

expected the bug to target the "4.18.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

The IBM Public Cloud DNS provider (cis_provider.go) had a bug in createOrUpdateDNSRecord where it checked for the existence of a DNS record by filtering both DNS name and target. If the target was updated (e.g., due to a load balancer recreation), the logic would not match the existing DNS record. As a result, the function would attempt to create a new record, but fail because a record with that name already existed, as multiple DNS records with the same name are not allowed.

The fix is to remove the filtering by target and rely solely on filtering by name, as the name is the only attribute that needs to be unique.

This PR also includes some unit test fix up and missing coverage for the IBM CIS Provider.

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.

gcs278 · 2024-08-22T22:57:45Z

/jira refresh

openshift-ci-robot · 2024-08-22T22:57:51Z

@gcs278: This pull request references Jira Issue OCPBUGS-32776, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.18.0) matches configured target version for branch (4.18.0)
bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @lihongan

In response to this:

/jira refresh

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-robot · 2024-08-22T22:58:26Z

@gcs278: This pull request references Jira Issue OCPBUGS-32776, which is valid.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.18.0) matches configured target version for branch (4.18.0)
bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @lihongan

In response to this:

The IBM Public Cloud DNS provider (cis_provider.go) had a bug in createOrUpdateDNSRecord where it checked for the existence of a DNS record by filtering both DNS name and target. If the target was updated (e.g., due to a load balancer recreation), the logic would not match the existing DNS record. As a result, the function would attempt to create a new record, but fail because a record with that name already existed, as multiple DNS records with the same name are not allowed.

The fix is to remove the filtering by target and rely solely on filtering by name, as the name is the only attribute that needs to be unique.

This PR also includes some unit test fix up and missing coverage for the IBM CIS Provider.

This also resolves the same DNS issues for public PowerVS cloud as it uses the same logic.

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.

gcs278 · 2024-08-26T16:10:14Z

I missed one detail of the bug, missing instructions in the Progressing status condition for PowerVS when you change scope. Looking into it.
/hold

gcs278 · 2024-08-26T19:30:02Z

@lihongan Added the missing scope change instructions for the PowerVS type.

/unhold

gcs278 · 2024-08-27T00:21:55Z

infra failures
/retest

gcs278 · 2024-08-28T00:28:35Z

Infra issues
/retest

lihongan · 2024-08-28T05:32:39Z

pre-merge tested on OpenStack and looks good now

$ oc -n openshift-ingress-operator patch ingresscontroller/intlb --type=merge --patch='{"spec":{"endpointPublishingStrategy": {"type":"LoadBalancerService", "loadBalancer": {"scope":"External"}}}}'
ingresscontroller.operator.openshift.io/intlb patched

$ oc get co/ingress
NAME      VERSION                                                   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
ingress   4.17.0-0.ci.test-2024-08-28-040831-ci-ln-13rxbgt-latest   True        True          False      23m     ingresscontroller "intlb" is progressing: IngressControllerProgressing: One or more status conditions indicate progressing: LoadBalancerProgressing=True (OperandsProgressing: One or more managed resources are progressing: The IngressController scope was changed from "Internal" to "External".  To effectuate this change, you must delete the service: `oc -n openshift-ingress delete svc/router-intlb`; the service load-balancer will then be deprovisioned and a new one created.  This will most likely cause the new load-balancer to have a different host name and IP address from the old one's.  Alternatively, you can revert the change to the IngressController: `oc -n openshift-ingress-operator patch ingresscontrollers/intlb --type=merge --patch='{"spec":{"endpointPublishingStrategy":{"loadBalancer":{"scope":"Internal"}}}}'`).

$ oc -n openshift-ingress delete svc/router-intlb
service "router-intlb" deleted

$ oc -n openshift-ingress get svc/router-intlb
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
router-intlb   LoadBalancer   172.30.110.89   38.102.83.53   80:32114/TCP,443:30834/TCP   4m23s

will test on IBMCloud later

lihongan · 2024-08-28T09:53:50Z

pre-merge tested on IBMCloud and also looks good

$ oc -n openshift-ingress get svc/router-intlb
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP                         PORT(S)                      AGE
router-intlb   LoadBalancer   172.30.111.21   53084b0d-eu-de.lb.appdomain.cloud   80:31026/TCP,443:32398/TCP   78s

$ oc -n openshift-ingress-operator patch ingresscontroller/intlb --type=merge --patch='{"spec":{"endpointPublishingStrategy": {"type":"LoadBalancerService", "loadBalancer": {"scope":"External"}}}}'
ingresscontroller.operator.openshift.io/intlb patched

$ oc -n openshift-ingress delete svc/router-intlb
service "router-intlb" deleted

$ oc -n openshift-ingress get svc/router-intlb
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP                         PORT(S)                      AGE
router-intlb   LoadBalancer   172.30.242.68   72736508-eu-de.lb.appdomain.cloud   80:32041/TCP,443:30579/TCP   65s

$ oc -n openshift-ingress-operator get ingresscontroller/intlb -oyaml
<......>
  - lastTransitionTime: "2024-08-28T09:24:02Z"
    message: The record is provisioned in all reported zones.
    reason: NoFailedZones
    status: "True"
    type: DNSReady

pkg/operator/controller/ingress/load_balancer_service.go

Miciah · 2024-08-28T15:17:17Z

/assign

Miciah · 2024-08-28T15:17:54Z

@SzucsAti, this is a follow-up to #796. Are you available to review the changes to the IBM DNS provider?

SzucsAti

Looks good to me, thank you for the fix!

candita · 2025-01-24T22:18:12Z

/lgtm
/approve
Holding for @Miciah, who would like to look too.
/hold

openshift-ci · 2025-01-24T22:18:33Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: candita

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:

~~OWNERS~~ [candita]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

gcs278 · 2025-01-30T20:53:27Z

Releasing the hold due to no new reviews/comments.

/hold cancel

gcs278 · 2025-01-30T20:58:01Z

While maybe not absolutely critical, I consider this fix a major fix as users are prevented from recreating IngressController's service IBMCloud platforms (something we explicitly tell them to do when they change scope). I also have other commitments that prevent me from waiting another month to merge this.

/label acknowledge-critical-fixes-only

openshift-ci-robot · 2025-01-31T01:33:36Z

/retest-required

Remaining retests: 0 against base HEAD 3ad38c6 and 2 for PR HEAD b0b91bb in total

Miciah · 2025-01-31T01:49:08Z

pkg/dns/ibm/private/dnssvcs_provider_test.go

@@ -108,6 +108,23 @@ func Test_Delete(t *testing.T) {
 			},
 			expectErrorContains: "error in ListAllDnsRecords",
 		},
+		{
+			desc:    "list success but missing ID",


Seems like this should be "list failure (fake timeout) and missing ID". However, it really doesn't matter what the status is if the id is missing ~~or mismatched~~, so maybe the description should be "list failure (missing ID)"?

Good catch, a bit of a copypasta. The response code doesn't get checked if the error is nil, but I meant to just have it be a success to be a less confusing test.

Ah, I see, the HTTP error is ignored because ListResourceRecords returns a nil error value. I guess "list success" refers to the error value, not the HTTP code. It's kind of confusing to have a test case where the HTTP code indicates an error but ListResourceRecords reports no error. I wouldn't have said anything if you had http.StatusOK instead of http.StatusRequestTimeout. I guess it doesn't really matter, and the conspicuous test input did prompt me to look more closely at the logic, which is a good thing. ¯\_(ツ)_/¯

Miciah · 2025-01-31T02:00:14Z

pkg/dns/ibm/private/dnssvcs_provider_test.go

+		{
+			desc:    "list success but nil dns record list",
+			DNSName: "testDelete",
+			listAllDnsRecordsInputOutput: dnsclient.ListAllDnsRecordsInputOutput{
+				OutputError:    nil,
+				OutputResponse: &core.DetailedResponse{StatusCode: http.StatusOK},
+				OutputResult:   &dnssvcsv1.ListResourceRecords{},
+			},
+		},


The looks the same as "create happy path":

cluster-ingress-operator/pkg/dns/ibm/private/dnssvcs_provider_test.go

Lines 385 to 400 in c5d48ec

{

desc: "create happy path",

DNSName: "testCreate",

target: "11.22.33.44",

recordedCall: "CREATE",

listAllDnsRecordsInputOutput: dnsclient.ListAllDnsRecordsInputOutput{

OutputError: nil,

OutputResponse: &core.DetailedResponse{StatusCode: http.StatusOK},

OutputResult: &dnssvcsv1.ListResourceRecords{},

},

createDnsRecordInputOutput: dnsclient.CreateDnsRecordInputOutput{

InputId: "testCreate",

OutputError: nil,

OutputResponse: &core.DetailedResponse{StatusCode: http.StatusOK},

},

},

Ah, but "list success but nil dns record list" is missing target. Should it rather be called "list success but no matching entry in dns record list"?

Well, I guess the "create happy path" is the same as "no matching entry in dns record list". In both cases, the list happens to be empty, but in this case, the target is an empty string.

It's weird that specifying an empty target doesn't cause an error, and it isn't clear that this test case was intended to test that scenario. Given that that's the current behavior, I don't mind having a test case for it. However, the test case should be named clearly (something like "create with an empty target"), and we might follow up with a fix to reject records with empty target and update the test case accordingly to expect an error.

I think you misplaced your comment on the delete unit test, but I think you meant to comment on the one for create (same named test cases).

Yea I actually think your first thought is correct, it feels redundant. The target does not impact anything in this test. Right, I was going to say, maybe it provides value by encoding/protecting a specific behavior, but that wasn't the intention.

I'll at least update the name.

gcs278 · 2025-01-31T02:37:54Z

Working through some comments
/hold

Miciah · 2025-01-31T03:50:02Z

pkg/dns/ibm/public/cis_provider.go

-			if response != nil && response.StatusCode != http.StatusNotFound {
-				return fmt.Errorf("createOrUpdateDNSRecord: failed to list the dns record: %w", err)
-			}
-			continue


This change is really subtle, and it isn't clear to me how it relates to the description of the changes in the commit message. (Indeed, it would be easy not to notice this change at all, but for the change to the unit tests!)

Of course, you cannot keep the literal continue statement since this logic is no longer inside a for loop. However, you could have replaced continue with return. Presumably, the reason you instead simply drop the continue is that the old logic was wrong: It was skipping the create/update in the case of a not-found error, but the correct behavior is to create in the case of a not-found error. Am I correctly understanding the old behavior and the intent of your change?

The commit message mentions two changes to this logic:

"remove the filtering by target and rely solely on filtering by name" and

"only create using the first target".

I think it makes sense to mention "fall through to the create logic in the case of a not-found error" as a distinct change as well.

Presumably, the reason you instead simply drop the continue is that the old logic was wrong: It was skipping the create/update in the case of a not-found error, but the correct behavior is to create in the case of a not-found error. Am I correctly understanding the old behavior and the intent of your change?

Exactly, that was my thought. One other point:

It was inconsistent with the createOrUpdateDNSRecord in dnsvcs_provider.go for no obvious reason. Based on the reason you explained, I dropped the continue/return, reference:

cluster-ingress-operator/pkg/dns/ibm/private/dnssvcs_provider.go

Lines 201 to 209 in b0b91bb

listResult, response, err := p.dnsService.ListResourceRecords(listOpt)

if err != nil {

// Avoid continuing with an invalid list response, as we can't determine

// whether to create or update the DNS record, which may lead to further issues.

if response == nil || response.StatusCode != http.StatusNotFound {

return fmt.Errorf("createOrUpdateDNSRecord: failed to list the dns record: %w", err)

}

}

if listResult == nil {

I'll update the commit message.

Miciah · 2025-01-31T03:51:35Z

I've finished reviewing. Sorry for the last-minute comments! There's nothing absolutely critical, so
/lgtm
but I can re-/lgtm if you do have time to push changes for my minor suggestions.

The IBM Public Cloud DNS provider (`cis_provider.go`) had a bug in `createOrUpdateDNSRecord` where it checked for the existence of a DNS record by filtering both DNS name and target. If the target was updated (e.g., due to a load balancer recreation), the logic would not match the existing DNS record. As a result, the function would attempt to create a new record, but fail because a record with that name already existed, as multiple DNS records with the same name are not allowed in IBM Cloud DNS providers. The fix is to remove the filtering by target and rely solely on filtering by name, as the name is the only attribute that needs to be unique. This fix also includes a subtle fix in `createOrUpdateDNSRecord` of cis_provider.go to fall through to the create logic in the case of a not-found (404) error. Additionally, the IBM DNS logic doesn't work for multiple targets and this creates unexpected and problematic results. The logic has been refactored to only create using the first target and it warns the user when multiple targets are set. This change is low risk since the Ingress Operator will never create a DNSRecord with multiple targets in `desiredDNSRecord`. Lastly, modify TestScopeChange to check for `Available=True` after deleting the service to add test coverage for this issue.

openshift-ci-robot · 2025-01-31T17:16:52Z

@gcs278: This pull request references Jira Issue OCPBUGS-32776, which is valid.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.19.0) matches configured target version for branch (4.19.0)
bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @lihongan

In response to this:

The IBM Public Cloud DNS provider (cis_provider.go) had a bug in createOrUpdateDNSRecord where it checked for the existence of a DNS record by filtering both DNS name and target. If the target was updated (e.g., due to a load balancer recreation), the logic would not match the existing DNS record. As a result, the function would attempt to create a new record, but fail because a record with that name already existed, as multiple DNS records with the same
name are not allowed in IBM Cloud DNS providers.

The fix is to remove the filtering by target and rely solely on filtering by name, as the name is the only attribute that needs to be unique.

This fix also includes a subtle fix in createOrUpdateDNSRecord of cis_provider.go to fall through to the create logic in the case of a not-found (404) error.

Additionally, the IBM DNS logic doesn't work for multiple targets and this creates unexpected and problematic results. The logic has been refactored to only create using the first target and it warns the user when multiple targets are set. This change is low risk since the Ingress Operator will never create a DNSRecord with multiple targets in desiredDNSRecord.

Additionally, modify TestScopeChange to check for Available=True after deleting the service to add test coverage for this issue.

This PR also includes some unit test fix up and missing unit test coverage for the IBM CIS Provider.

This resolves the same DNS issues for public PowerVS cloud as it uses the same logic.

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.

gcs278 · 2025-01-31T17:17:14Z

@Miciah ready for review/lgtm.

Miciah · 2025-01-31T17:38:37Z

Thanks!
/lgtm

candita · 2025-01-31T21:55:36Z

Another case where acquiring an AWS lease took 30 minutes and the test timed out after 4 hours.
/test e2e-aws-ovn-serial

gcs278 · 2025-02-01T14:36:57Z

I forgot to remove the hold

/hold cancel

Installation failures and unrelated failures (nothing related to ibmcloud)
/retest

openshift-ci-robot · 2025-02-01T16:47:19Z

@gcs278: Jira Issue OCPBUGS-32776: All pull requests linked via external trackers have merged:

openshift/cluster-ingress-operator#1133

Jira Issue OCPBUGS-32776 has been moved to the MODIFIED state.

In response to this:

The IBM Public Cloud DNS provider (cis_provider.go) had a bug in createOrUpdateDNSRecord where it checked for the existence of a DNS record by filtering both DNS name and target. If the target was updated (e.g., due to a load balancer recreation), the logic would not match the existing DNS record. As a result, the function would attempt to create a new record, but fail because a record with that name already existed, as multiple DNS records with the same
name are not allowed in IBM Cloud DNS providers.

The fix is to remove the filtering by target and rely solely on filtering by name, as the name is the only attribute that needs to be unique.

This fix also includes a subtle fix in createOrUpdateDNSRecord of cis_provider.go to fall through to the create logic in the case of a not-found (404) error.

Additionally, the IBM DNS logic doesn't work for multiple targets and this creates unexpected and problematic results. The logic has been refactored to only create using the first target and it warns the user when multiple targets are set. This change is low risk since the Ingress Operator will never create a DNSRecord with multiple targets in desiredDNSRecord.

Additionally, modify TestScopeChange to check for Available=True after deleting the service to add test coverage for this issue.

This PR also includes some unit test fix up and missing unit test coverage for the IBM CIS Provider.

This resolves the same DNS issues for public PowerVS cloud as it uses the same logic.

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 · 2025-02-01T16:47:31Z

@gcs278: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-ibmcloud-operator	`2223383`	link	false	`/test e2e-ibmcloud-operator`
ci/prow/e2e-aws-ovn-single-node	`d2160e6`	link	false	`/test e2e-aws-ovn-single-node`

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.

openshift-bot · 2025-02-01T19:07:23Z

[ART PR BUILD NOTIFIER]

Distgit: ose-cluster-ingress-operator
This PR has been included in build ose-cluster-ingress-operator-container-v4.19.0-202502011838.p0.gedf5e71.assembly.stream.el9.
All builds following this will include this PR.

openshift-ci-robot added jira/severity-important Referenced Jira bug's severity is important for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. labels Aug 22, 2024

openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Aug 22, 2024

openshift-ci bot requested review from alebedev87 and frobware August 22, 2024 22:46

gcs278 force-pushed the ibm-dns-createOrUpdateDNSRecord-bug branch from b387d07 to b07d602 Compare August 22, 2024 22:50

openshift-ci-robot added the jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. label Aug 22, 2024

openshift-ci-robot removed the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Aug 22, 2024

openshift-ci bot requested a review from lihongan August 22, 2024 22:57

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 26, 2024

gcs278 force-pushed the ibm-dns-createOrUpdateDNSRecord-bug branch from a057f1a to 0716651 Compare August 26, 2024 19:28

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 26, 2024

gcs278 force-pushed the ibm-dns-createOrUpdateDNSRecord-bug branch from 0716651 to f51b1d3 Compare August 27, 2024 14:31

Miciah reviewed Aug 28, 2024

View reviewed changes

pkg/operator/controller/ingress/load_balancer_service.go Outdated Show resolved Hide resolved

openshift-ci bot assigned Miciah Aug 28, 2024

gcs278 changed the title ~~OCPBUGS-32776: Fix IBM Public Cloud DNS Provider Update Logic~~ OCPBUGS-32776: Fix IBM Public Cloud DNS Provider Update Logic and Add Missing Instructions to the Progressing Condition Aug 28, 2024

gcs278 force-pushed the ibm-dns-createOrUpdateDNSRecord-bug branch from f51b1d3 to 7a97b9a Compare August 28, 2024 15:29

SzucsAti approved these changes Aug 28, 2024

View reviewed changes

openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. labels Jan 24, 2025

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 24, 2025

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 30, 2025

openshift-ci bot added the acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. label Jan 30, 2025

Miciah reviewed Jan 31, 2025

View reviewed changes

openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 31, 2025

Miciah reviewed Jan 31, 2025

View reviewed changes

gcs278 force-pushed the ibm-dns-createOrUpdateDNSRecord-bug branch from b0b91bb to d2160e6 Compare January 31, 2025 17:15

openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 31, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 31, 2025

openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Feb 1, 2025

openshift-merge-bot bot merged commit edf5e71 into openshift:master Feb 1, 2025
17 of 19 checks passed

	{
	desc: "create happy path",
	DNSName: "testCreate",
	target: "11.22.33.44",
	recordedCall: "CREATE",
	listAllDnsRecordsInputOutput: dnsclient.ListAllDnsRecordsInputOutput{
	OutputError: nil,
	OutputResponse: &core.DetailedResponse{StatusCode: http.StatusOK},
	OutputResult: &dnssvcsv1.ListResourceRecords{},
	},
	createDnsRecordInputOutput: dnsclient.CreateDnsRecordInputOutput{
	InputId: "testCreate",
	OutputError: nil,
	OutputResponse: &core.DetailedResponse{StatusCode: http.StatusOK},
	},
	},

	listResult, response, err := p.dnsService.ListResourceRecords(listOpt)
	if err != nil {
	// Avoid continuing with an invalid list response, as we can't determine
	// whether to create or update the DNS record, which may lead to further issues.
	if response == nil \|\| response.StatusCode != http.StatusNotFound {
	return fmt.Errorf("createOrUpdateDNSRecord: failed to list the dns record: %w", err)
	}
	}
	if listResult == nil {

OCPBUGS-32776: Fix IBM Public Cloud DNS Provider Update Logic #1133

OCPBUGS-32776: Fix IBM Public Cloud DNS Provider Update Logic #1133

Conversation

gcs278 commented Aug 22, 2024 • edited Loading

openshift-ci-robot commented Aug 22, 2024

gcs278 commented Aug 22, 2024

openshift-ci-robot commented Aug 22, 2024

openshift-ci-robot commented Aug 22, 2024

gcs278 commented Aug 26, 2024

gcs278 commented Aug 26, 2024

gcs278 commented Aug 27, 2024

gcs278 commented Aug 28, 2024

lihongan commented Aug 28, 2024

lihongan commented Aug 28, 2024

Miciah commented Aug 28, 2024

Miciah commented Aug 28, 2024

SzucsAti left a comment

Choose a reason for hiding this comment

candita commented Jan 24, 2025

openshift-ci bot commented Jan 24, 2025

gcs278 commented Jan 30, 2025

gcs278 commented Jan 30, 2025

openshift-ci-robot commented Jan 31, 2025

Miciah Jan 31, 2025 • edited Loading

Choose a reason for hiding this comment

gcs278 Jan 31, 2025

Choose a reason for hiding this comment

Miciah Jan 31, 2025

Choose a reason for hiding this comment

Miciah Jan 31, 2025

Choose a reason for hiding this comment

Miciah Jan 31, 2025 • edited Loading

Choose a reason for hiding this comment

gcs278 Jan 31, 2025

Choose a reason for hiding this comment

gcs278 commented Jan 31, 2025

Miciah Jan 31, 2025

Choose a reason for hiding this comment

gcs278 Jan 31, 2025

Choose a reason for hiding this comment

Miciah commented Jan 31, 2025

openshift-ci-robot commented Jan 31, 2025

gcs278 commented Jan 31, 2025

Miciah commented Jan 31, 2025

candita commented Jan 31, 2025

gcs278 commented Feb 1, 2025

openshift-ci-robot commented Feb 1, 2025

openshift-ci bot commented Feb 1, 2025

openshift-bot commented Feb 1, 2025

gcs278 commented Aug 22, 2024 •

edited

Loading

Miciah Jan 31, 2025 •

edited

Loading

Miciah Jan 31, 2025 •

edited

Loading