-
Notifications
You must be signed in to change notification settings - Fork 184
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
RDR: ODF info CM logic #2440
Conversation
Skipping CI for Draft Pull Request. |
fc09552
to
588dc5a
Compare
bd9a4fe
to
5e189d6
Compare
16106fd
to
0cbbe5a
Compare
ded7a1f
to
97e2bed
Compare
/cc @umangachapagain |
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.
@raaizik This PR is trying to achieve two separate and distinct goals:
- Implement a reconciler for the ODF info config map
- Extend the provider onboarding request to handle additional data
Please separate each concern into its own PR
c5226c1
to
f7c208e
Compare
/retest |
a667762
to
4040225
Compare
Signed-off-by: raaizik <[email protected]>
d5c5636
to
c808435
Compare
Introduces new CM that replaces ClusterClaims + tests Signed-off-by: raaizik <[email protected]>
/lgtm |
[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 |
ec44394
into
red-hat-storage:main
Kind: "StorageSystem", | ||
APIVersion: "v1", | ||
}, | ||
ocsVersion: "3.16.0", |
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.
@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?
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 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.
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.
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.
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.
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.
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.
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
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.
Right
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.
@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
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.
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
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 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.
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 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)) |
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.
@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 ??
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 think you're right. I guess I didn't take multi SCs into account here.
Changes
ClusterClaim
's functionalities that expose relevant data to ACM, as well as populates its data upon eachonboardedconsumer's status refresh triggered by heartbeat signal.isDROptimized
feature that used to be part of the now deprecatedClusterClaims
.TODOs
CephCluster
which is being used by theisDROptimized
function. It's been suggested to consider this feature's removal for upcoming version (4.17).ClusterClaims.go
OdfInfoConfig