Skip to content
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

RDR: ODF info CM logic #2440

Merged
merged 2 commits into from
May 19, 2024
Merged

Conversation

raaizik
Copy link
Contributor

@raaizik raaizik commented Feb 4, 2024

Changes

  • Introduces a new CM that replaces ClusterClaim's functionalities that expose relevant data to ACM, as well as populates its data upon each onboarded consumer's status refresh triggered by heartbeat signal.
  • *️⃣ Removes isDROptimized feature that used to be part of the now deprecated ClusterClaims.

TODOs

  • Adjust unit tests
    • *️⃣ Bug detected in the initialization function due to a yet-to-be-filled-in status of CephClusterwhich is being used by the isDROptimized function. It's been suggested to consider this feature's removal for upcoming version (4.17).
  • Deprecate ClusterClaims.go
  • Add unit tests for OdfInfoConfig

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 4, 2024
Copy link
Contributor

openshift-ci bot commented Feb 4, 2024

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

@raaizik raaizik force-pushed the rdr-odfinfo branch 5 times, most recently from fc09552 to 588dc5a Compare February 11, 2024 15:59
@raaizik raaizik force-pushed the rdr-odfinfo branch 5 times, most recently from bd9a4fe to 5e189d6 Compare February 12, 2024 18:28
@raaizik raaizik force-pushed the rdr-odfinfo branch 4 times, most recently from 16106fd to 0cbbe5a Compare February 20, 2024 14:10
@raaizik raaizik force-pushed the rdr-odfinfo branch 7 times, most recently from ded7a1f to 97e2bed Compare March 3, 2024 19:21
@raaizik
Copy link
Contributor Author

raaizik commented Mar 4, 2024

/cc @umangachapagain

@openshift-ci openshift-ci bot requested a review from umangachapagain March 4, 2024 09:32
Copy link
Contributor

@nb-ohad nb-ohad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raaizik This PR is trying to achieve two separate and distinct goals:

  1. Implement a reconciler for the ODF info config map
  2. Extend the provider onboarding request to handle additional data

Please separate each concern into its own PR

controllers/storagecluster/clusterclaims.go Outdated Show resolved Hide resolved
controllers/storagecluster/clusterclaims.go Outdated Show resolved Hide resolved
controllers/storagecluster/clusterclaims.go Outdated Show resolved Hide resolved
controllers/storagecluster/odfinfoconfig.go Show resolved Hide resolved
controllers/storagecluster/odfinfoconfig.go Show resolved Hide resolved
controllers/storagecluster/odfinfoconfig.go Outdated Show resolved Hide resolved
controllers/storagecluster/odfinfoconfig.go Outdated Show resolved Hide resolved
services/provider/proto/provider.proto Outdated Show resolved Hide resolved
services/provider/server/server.go Outdated Show resolved Hide resolved
services/provider/server/server.go Outdated Show resolved Hide resolved
@raaizik raaizik force-pushed the rdr-odfinfo branch 2 times, most recently from c5226c1 to f7c208e Compare March 10, 2024 11:21
@raaizik raaizik changed the title RDR: odf-info map logic RDR: ODF info CM logic Mar 11, 2024
@raaizik
Copy link
Contributor Author

raaizik commented May 8, 2024

/retest

@raaizik raaizik force-pushed the rdr-odfinfo branch 7 times, most recently from a667762 to 4040225 Compare May 15, 2024 12:16
@raaizik raaizik force-pushed the rdr-odfinfo branch 5 times, most recently from d5c5636 to c808435 Compare May 15, 2024 13:23
Introduces new CM that replaces ClusterClaims + tests
Signed-off-by: raaizik <[email protected]>
@raaizik raaizik changed the title [WIP] RDR: ODF info CM logic RDR: ODF info CM logic May 15, 2024
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 15, 2024
@nb-ohad
Copy link
Contributor

nb-ohad commented May 19, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 19, 2024
Copy link
Contributor

openshift-ci bot commented May 19, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nb-ohad, raaizik

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 19, 2024
@openshift-merge-bot openshift-merge-bot bot merged commit ec44394 into red-hat-storage:main May 19, 2024
11 checks passed
Kind: "StorageSystem",
APIVersion: "v1",
},
ocsVersion: "3.16.0",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raaizik shouldn't this be 4.16.0?
And, with the CSV version changed to 4.17 now, it would be 4.17.0, isn't it?

Copy link
Member

@Nikhil-Ladha Nikhil-Ladha May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have opened a PR to fix the failing test case, because of CSV version change. But, if this change is unintentional I can revert it in my open PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I don't think we should have a dependency of version check like this in the tests, this would mean that we would need to update the version in the test after each release, which is an added task.

Copy link
Contributor Author

@raaizik raaizik May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test case isn't failing, @Nikhil-Ladha. Plus it's just a dummy for unit test purposes, not sure why you think it must store an up-to-date value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ocsversion is fetched from the storagecluster CR and compared to the one hardcoded in the test case.
And, the storagecluster version is updated in each release.
Also, the test is failing on master branch now, because the CSV is updated to 4.17.0 so, the assertion is failing at 3.17.0 != 3.16.0.
Ex: https://github.com/red-hat-storage/ocs-operator/actions/runs/9147599372/job/25149216914

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right

Copy link
Contributor

@nb-ohad nb-ohad May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raaizik @Nikhil-Ladha In a unit test you should assume the desired value, not read it from program logic. If you do so you will get into a situation where the test does not test anything as a bug occurs in the underlying logic.

For example, assume a bug in version.Version, if both the Program code and the test read this value then even if we have a bug in the code that fills in this value we will still get the test passing.

A test must make assumptions. For this test case, I would overwrite the version.Version value with mock value (Let's say 9.9.9) and they will try to verify that the CM has the 9.9.9 by comparing to a hardcoded value

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, that is something that should be caught while reviewing the PR.
The current code creates a new dependency of updating the hardcoded value in the test for each release, which is not something we would want to do I assume?
cc @iamniting

Copy link
Contributor Author

@raaizik raaizik May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @nb-ohad's suggestion is to resolve that so called dependency by coupling the mock with some hard-coded value check in the test env. Meaning treat it as a mock in the first place as opposed to its actual real value.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not prefer to have hardcoded values which we will need to change every release. I agree with @Nikhil-Ladha here.


func getOcsVersion(r *StorageClusterReconciler, storageCluster *ocsv1.StorageCluster) (string, error) {
var csvs operatorsv1alpha1.ClusterServiceVersionList
err := r.Client.List(r.ctx, &csvs, client.InNamespace(storageCluster.Namespace))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@raaizik shouldn't this be operatorNamespace instead of storageCluster.Namespace ??
In case of multiple StorageSystems/StorageClusters, each system/cluster will be in different namespace, but CSV will always be in operator installation namespace. Am I missing something ??

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right. I guess I didn't take multi SCs into account here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants