Closed alebedev87 closed 1 year ago
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is invalid:
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.
/jira refresh
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid. The bug has been moved to the POST state.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
/retest
GCP install failed: Cluster operator authentication Degraded is True with OAuthServerRouteEndpointAccessibleController_SyncError.
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
/label qe-approved
/label docs-approved
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
@alebedev87: This pull request references Jira Issue OCPBUGS-2793, which is valid.
Requesting review from QA contact: /cc @lihongan
The bug has been updated to refer to the pull request using the external bug tracker.
GCP installation failure.
/retest
Lovely jubbly! /approve /lgtm
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: alebedev87, Miciah
The full list of commands accepted by this bot can be found here.
The pull request process is described here
e2e-infoblox-operator failed because the cluster had no worker nodes. In the machine-api-controllers pod logs, I see the following being logged repeatedly:
E1208 21:51:02.230090 1 controller.go:297] ci-op-4zky13qb-74059-5q55r-worker-a-w6tkj: failed to check if machine exists: ci-op-4zky13qb-74059-5q55r-worker-a-w6tkj: failed to create scope for machine: error getting credentials secret "gcp-cloud-credentials" in namespace "openshift-machine-api": Secret "gcp-cloud-credentials" not found
In credentialsrequests.json
, I found the following:
"message": "failed to grant creds: error syncing creds in mint-mode: error creating custom role: rpc error: code = ResourceExhausted desc = Maximum number of roles reached. Maximum is: 300\nerror details: retry in 24h0m1s",
e2e-gcp-operator failed, evidently for the same reason—I see the same error in credentialsrequests.json
for e2e-gcp-operator as well.
/retest
/retest-required
Remaining retests: 0 against base HEAD fd1d055f84381bd12b431c071a3255c935fdbfe3 and 2 for PR HEAD 5f39ac435c26ddc2dc13ff27747ba2a8acb692a7 in total
/retest
@alebedev87: all tests passed!
Full PR test history. Your PR dashboard.
@alebedev87: All pull requests linked via external trackers have merged:
Jira Issue OCPBUGS-2793 has been moved to the MODIFIED state.
Previous PR for the same ticket introduced a new bug: unsolicited containers from the previous states of ExternalDNS CR are kept. The bug was caught by @lihongan and has this visible consequence when the zone ID (
ExternalDNS.spec.zones
) of an existing instance of ExternalDNS is changed.Bad case scenario:
x.y.z
external-dns-<hash-for-zone-x-y-z>
(note that for each zone ID specified the operator creates a dedicated container in the deployment)x.y.z
toy.y.y
external-dns-<hash-for-zone-y-y-y>
external-dns-<hash-for-zone-x-y-z>
from the current deployment is not removedImpact:
Solution: At first the idea was to discard the containers from the previous state judging by their name (
external-dns-<hash>
). However the idea of being stricter until a real use case comes up dominated. So all the unsolicited containers are now removed from the managed deployment.