OCPBUGS-44377: Add migration logic for wipe refactor

[suleymanakbas91]

This PR introduces migration logic for updates to the wipe feature in version 4.17. Previously, the LVM Operator used the LVMVolumeGroupNodeStatus resource to verify if a device was wiped—if the device appeared in a VG under LVMVGStatus, it was considered wiped. In 4.17, we refactored this approach to rely on the wiped.devices.lvms.openshift.io annotation within an LVMVolumeGroup, indicating whether all devices in the VG have been wiped. However, during upgrades from 4.16 to 4.17 or 4.18, the LVM Operator would re-wipe devices due to the missing annotation. This migration logic resolves that by checking existing LVMVolumeGroupNodeStatus resources in the operator namespace and applying the necessary annotations to LVMVolumeGroups.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci-robot]

@suleymanakbas91: This pull request references Jira Issue OCPBUGS-44377, 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 New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @mmakwana30

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.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: suleymanakbas91

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 [suleymanakbas91]

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

[suleymanakbas91]

/test all

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 77.77778% with 8 lines in your changes missing coverage. Please review.

Project coverage is 69.54%. Comparing base (9ea56e1) to head (6dc6355).

Files with missing lines	Patch %	Lines
internal/migration/wipe-refactor/annotate.go	77.77%	4 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #779      +/-   ##
==========================================
+ Coverage   69.45%   69.54%   +0.08%     
==========================================
  Files          49       50       +1     
  Lines        3415     3451      +36     
==========================================
+ Hits         2372     2400      +28     
- Misses        861      865       +4     
- Partials      182      186       +4     

Files with missing lines	Coverage Δ
internal/migration/wipe-refactor/annotate.go	77.77% <77.77%> (ø)

[openshift-ci-robot]

@suleymanakbas91: This pull request references Jira Issue OCPBUGS-44377, 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 @mmakwana30

In response to this:

This PR introduces migration logic for updates to the wipe feature in version 4.17. Previously, the LVM Operator used the LVMVolumeGroupNodeStatus resource to verify if a device was wiped—if the device appeared in a VG under LVMVGStatus, it was considered wiped. In 4.17, we refactored this approach to rely on the wiped.devices.lvms.openshift.io annotation within an LVMVolumeGroup, indicating whether all devices in the VG have been wiped. However, during upgrades from 4.16 to 4.17 or 4.18, the LVM Operator would re-wipe devices due to the missing annotation. This migration logic resolves that by checking existing LVMVolumeGroupNodeStatus resources in the operator namespace and applying the necessary annotations to LVMVolumeGroups.

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.

[suleymanakbas91]

/hold for further testing

[openshift-ci]

@suleymanakbas91: all tests passed!

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.

[qJkee]

/lgtm

[suleymanakbas91]

/unhold

[openshift-ci-robot]

@suleymanakbas91: Jira Issue OCPBUGS-44377: All pull requests linked via external trackers have merged:

• openshift/lvm-operator#779

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

In response to this:

This PR introduces migration logic for updates to the wipe feature in version 4.17. Previously, the LVM Operator used the LVMVolumeGroupNodeStatus resource to verify if a device was wiped—if the device appeared in a VG under LVMVGStatus, it was considered wiped. In 4.17, we refactored this approach to rely on the wiped.devices.lvms.openshift.io annotation within an LVMVolumeGroup, indicating whether all devices in the VG have been wiped. However, during upgrades from 4.16 to 4.17 or 4.18, the LVM Operator would re-wipe devices due to the missing annotation. This migration logic resolves that by checking existing LVMVolumeGroupNodeStatus resources in the operator namespace and applying the necessary annotations to LVMVolumeGroups.

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.

[suleymanakbas91]

/cherry-pick release-4.17

[openshift-cherrypick-robot]

@suleymanakbas91: new pull request created: #781

In response to this:

/cherry-pick release-4.17

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.