OCPBUGS-17805: Do not error during capacity check if annotation does not exist on the node

[suleymanakbas91]

If the capacity annotation (capacity.topolvm.io/deviceClass) does not exist on a node, that means the node is not used by LVMS. So, do not error, but just do not include it in the calculations during the capacity check.

Change the implementation to use the corresponding annotation for the device class instead of using the default annotation.

[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

[codecov-commenter]

Codecov Report

Merging #385 (406b75d) into main (a962b90) will increase coverage by 39.03%.
Report is 22 commits behind head on main.
The diff coverage is 70.19%.

Additional details and impacted files

@@             Coverage Diff             @@
##             main     #385       +/-   ##
===========================================
+ Coverage   16.59%   55.62%   +39.03%     
===========================================
  Files          24       26        +2     
  Lines        2061     2231      +170     
===========================================
+ Hits          342     1241      +899     
+ Misses       1693      899      -794     
- Partials       26       91       +65     

Files Changed	Coverage Δ
controllers/lvmcluster_controller_watches.go	90.32% <ø> (+90.32%)	⬆️
controllers/persistent-volume-claim/controller.go	41.79% <0.00%> (+1.21%)	⬆️
pkg/vgmanager/vgmanager_controller.go	6.59% <0.00%> (+6.59%)	⬆️
controllers/topolvm_snapshotclass.go	61.22% <14.28%> (+61.22%)	⬆️
controllers/lvmcluster_controller.go	58.63% <50.00%> (+58.63%)	⬆️
pkg/cluster/leaderelection.go	66.66% <66.66%> (ø)
pkg/cluster/sno.go	72.72% <72.72%> (ø)
pkg/vgmanager/devices.go	73.77% <81.25%> (-0.43%)	⬇️
controllers/topolvm_controller.go	94.14% <100.00%> (+94.14%)	⬆️

... and 9 files with indirect coverage changes

[suleymanakbas91]

/hold

[openshift-ci-robot]

@suleymanakbas91: This pull request references Jira Issue OCPBUGS-17805, which is invalid:

• expected the bug to target the "4.14.0" version, but it targets "4.14" instead

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:

If the capacity annotation (capacity.topolvm.io/deviceClass) does not exist on a node, that means the node is not used by LVMS. So, do not error, but just do not include it in the calculations during the capacity check.

Change the implementation to use the corresponding annotation for the device class instead of using the default annotation.

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.

[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/test-infra repository. I understand the commands that are listed here.

[jakobmoellerdev]

/lgtm

Good stuff :)

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jakobmoellerdev, 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]

/unhold

[openshift-ci-robot]

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

• openshift/lvm-operator#385

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

In response to this:

If the capacity annotation (capacity.topolvm.io/deviceClass) does not exist on a node, that means the node is not used by LVMS. So, do not error, but just do not include it in the calculations during the capacity check.

Change the implementation to use the corresponding annotation for the device class instead of using the default annotation.

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.

[suleymanakbas91]

/cherry-pick release-4.14

[openshift-cherrypick-robot]

@suleymanakbas91: #385 failed to apply on top of branch "release-4.14":

Applying: fix: do not error during capacity check if annotation does not exist on the node
Using index info to reconstruct a base tree...
M	controllers/persistent-volume-claim/controller.go
A	controllers/persistent-volume-claim/controller_test.go
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): controllers/persistent-volume-claim/controller_test.go deleted in HEAD and modified in fix: do not error during capacity check if annotation does not exist on the node. Version fix: do not error during capacity check if annotation does not exist on the node of controllers/persistent-volume-claim/controller_test.go left in tree.
Auto-merging controllers/persistent-volume-claim/controller.go
CONFLICT (content): Merge conflict in controllers/persistent-volume-claim/controller.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 fix: do not error during capacity check if annotation does not exist on the node
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

/cherry-pick release-4.14

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.