-
Notifications
You must be signed in to change notification settings - Fork 91
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.
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
[release-4.5] Bug 1881957: updating EO to adopt an existing cluster if cr nodes uuid is nil #495
[release-4.5] Bug 1881957: updating EO to adopt an existing cluster if cr nodes uuid is nil #495
Conversation
@ewolinetz: This pull request references Bugzilla bug 1881957, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 6 validation(s) were run on this bug
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 kubernetes/test-infra repository. |
based on PVC names if PVCs currently exist or deployment|statefulset names if PVCs do not exist. if there are no matched UUIDs ones are auto generated. Attempt to best match UUID to a node based on how naming would match up based on role and node count. Also match based on resources, node selectors, and tolerations.
e76e234
to
896a559
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me in general, however I might be wrong but the merge for persistentvolumeclaims
blurred some inconsistencies in.
if retryErr != nil { | ||
return retryErr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to simplify the return statement here to retrun retryErr
to enhance readbility
if !errors.IsAlreadyExists(err) { | ||
return fmt.Errorf("Unable to create PVC: %v", err) | ||
} | ||
claim := createPersistentVolumeClaim(newName, namespace, clusterName, pvc) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the method is using the wrong prefix create
instead of new
. Former indicates normally a POST call to the apiserver while latter only a factory method for the resource we would like to persist later.
return fmt.Errorf("unable to create PVC: %w", err) | ||
} | ||
|
||
return updatePersistentVolumeClaim(claim, client) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why updating the same PVC resource after initial creation? Looks like duplicate work here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to ensure its in its correct state as we leave this function
if !reflect.DeepEqual(current.ObjectMeta.Labels, claim.ObjectMeta.Labels) { | ||
current.ObjectMeta.Labels = claim.ObjectMeta.Labels |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this function only update if the labels are not equal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if nothing is different (that we can change) there isn't a point to making an update call
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ewolinetz, periklis 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 |
(patch manager) affecting real-world users |
/retest Please review the full test history for this PR and help us cut down flakes. |
@ewolinetz: All pull requests linked via external trackers have merged: Bugzilla bug 1881957 has been moved to the MODIFIED state. 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 kubernetes/test-infra repository. |
/cherry-pick release-4.4 |
@ewolinetz: #495 failed to apply on top of branch "release-4.4":
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 kubernetes/test-infra repository. |
To address https://bugzilla.redhat.com/show_bug.cgi?id=1881957
Manual cherry-pick of #471
This addresses cases where there is or was an existing cluster created (deployments, pods, pvcs, etc) who's cluster name is the same as the CR name, however the new elasticsearch CR is missing UUIDs.
As part of the recovery/adoption process, it will be required that the PVCs to be picked back up have the label logging-cluster: . It will also be validated against the name of the cluster that the PVC name is based on.
Recovery/adoption will be triggered upon the processing of a CR that is missing UUIDs. It will only try to recover UUIDs for nodes that do not already have UUIDs defined.
Further documentation will need to be developed and publish as part of how to recover data that from another PVC. This PR does not seek to resolve that but rather address cases where an elasticsearch CR may have been removed on accident and then recreated (without UUIDs).
Please note: as part of this change EO will be creating PVCs with the required labels now, so to ensure keeping previously used PVCs they should be labeled per above.