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

✨ logically group fields in the spec #1200

Merged
merged 1 commit into from
Sep 4, 2024

Conversation

yashoza19
Copy link
Contributor

Description

Fixes: #1148

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests (and E2E Tests, if appropriate)
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

@yashoza19 yashoza19 requested a review from a team as a code owner August 30, 2024 16:03
Copy link

netlify bot commented Aug 30, 2024

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit 55d91d0
🔍 Latest deploy log https://app.netlify.com/sites/olmv1/deploys/66d8be77d946f900084a8acc
😎 Deploy Preview https://deploy-preview-1200--olmv1.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@yashoza19 yashoza19 force-pushed the issue1148 branch 2 times, most recently from ba4c86b to 2019ab1 Compare August 30, 2024 17:00
Comment on lines 187 to 188
ext.Status.Resolution.Bundle = nil
ext.Status.Install.Bundle = nil
Copy link
Contributor

Choose a reason for hiding this comment

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

Anywhere this change has been made runs a risk of accessing a nil pointer for the ext.Status.Resolution and ext.Status.Install fields. It looks like this is why some of the tests are failing (although maybe not caused by this line explicitly).

All areas where we update to this should perform some kind of nil check, and if the parent field is nil, set it. Something like:

Suggested change
ext.Status.Resolution.Bundle = nil
ext.Status.Install.Bundle = nil
if ext.Status.Resolution == nil {
ext.Status.Resolution = &ocv1alpha1.ResolutionStatus{}
}
ext.Status.Resolution.Bundle = nil
if ext.Status.Install == nil {
ext.Status.Install = &ocv1alpha1.InstallStatus{}
}
ext.Status.Install.Bundle = nil

Since you'd have to likely do this nil check on every place we set this, it might be helpful to extract it into a helper function for each status that looks something like:

func setResolutionStatus(ext *ocv1alpha1.ClusterExtension, resStatus *ocv1alpha1.ResolutionStatus) { ... }

func setInstallStatus(ext *ocv1alpha1.ClusterExtension, installStatus *ocv1alpha1.InstallStatus) { ... }

@yashoza19 yashoza19 force-pushed the issue1148 branch 2 times, most recently from d3a7526 to 384ee03 Compare September 3, 2024 13:57
Comment on lines 142 to 143
namespace: default
serviceAccount:
Copy link
Contributor

Choose a reason for hiding this comment

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

Indentation required?

Comment on lines 236 to 241
resolvedBundleMetadata := bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion)
resStatus := &ocv1alpha1.ResolutionStatus{
Bundle: &ocv1alpha1.BundleMetadata{
Name: resolvedBundleMetadata.Name,
Version: resolvedBundleMetadata.Version,
},
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
resolvedBundleMetadata := bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion)
resStatus := &ocv1alpha1.ResolutionStatus{
Bundle: &ocv1alpha1.BundleMetadata{
Name: resolvedBundleMetadata.Name,
Version: resolvedBundleMetadata.Version,
},
}
resStatus := &ocv1alpha1.ResolutionStatus{
Bundle: bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion),
}

Comment on lines 308 to 309
installedBundleMetadata := bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion)
installStatus := &ocv1alpha1.InstallStatus{
Bundle: &ocv1alpha1.BundleMetadata{
Name: installedBundleMetadata.Name,
Version: installedBundleMetadata.Version,
},
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
installedBundleMetadata := bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion)
installStatus := &ocv1alpha1.InstallStatus{
Bundle: &ocv1alpha1.BundleMetadata{
Name: installedBundleMetadata.Name,
Version: installedBundleMetadata.Version,
},
}
installStatus := &ocv1alpha1.InstallStatus{
Bundle: bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion),
}

Comment on lines 92 to 95
if ext.Status.Resolution == nil {
ext.Status.Resolution = &ocv1alpha1.ResolutionStatus{}
}
ext.Status.Resolution.Bundle = resStatus.Bundle
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if ext.Status.Resolution == nil {
ext.Status.Resolution = &ocv1alpha1.ResolutionStatus{}
}
ext.Status.Resolution.Bundle = resStatus.Bundle
ext.Status.Resolution = resStatus

Comment on lines 99 to 102
if ext.Status.Install == nil {
ext.Status.Install = &ocv1alpha1.InstallStatus{}
}
ext.Status.Install.Bundle = installStatus.Bundle
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
if ext.Status.Install == nil {
ext.Status.Install = &ocv1alpha1.InstallStatus{}
}
ext.Status.Install.Bundle = installStatus.Bundle
ext.Status.Install = installStatus

@yashoza19 yashoza19 force-pushed the issue1148 branch 2 times, most recently from 7b6a04b to 8e5835a Compare September 4, 2024 13:57
@@ -319,7 +326,7 @@ func TestClusterExtensionInstallRegistryMultipleBundles(t *testing.T) {
assert.Equal(ct, metav1.ConditionFalse, cond.Status)
assert.Equal(ct, ocv1alpha1.ReasonResolutionFailed, cond.Reason)
assert.Contains(ct, cond.Message, "matching packages found in multiple catalogs")
assert.Nil(ct, clusterExtension.Status.ResolvedBundle)
assert.Nil(ct, clusterExtension.Status.Resolution.Bundle)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is probably where the e2e panic is

Suggested change
assert.Nil(ct, clusterExtension.Status.Resolution.Bundle)
assert.Nil(ct, clusterExtension.Status.Resolution)

Copy link
Contributor

@everettraven everettraven left a comment

Choose a reason for hiding this comment

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

Overall it looks really good! Fix the e2e panic and I'll be happy to merge!

// namespace: example-namespace
// serviceAccount:
// name: example-sa
Install InstallationConfig `json:"install"`
Copy link
Member

Choose a reason for hiding this comment

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

Let's try to be consistent with word forms between field names and type names:

Suggested change
Install InstallationConfig `json:"install"`
Install InstallConfig `json:"install"`

Copy link
Member

Choose a reason for hiding this comment

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

Also, should we be prefixing these type names with ClusterExtension?

This package will contain structs for any future root API types and their sub-structs.

A hypothetical Extension API might have its own InstallConfig struct, but it will be different because it would not have a namespace field.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean it should be ClusterExtensionInstallConfig?

Copy link
Contributor

Choose a reason for hiding this comment

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

I think ClusterExtensionInstallConfig is reasonable

Copy link
Contributor

Choose a reason for hiding this comment

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

But I think @joelanford is referring to all the new types here. So something like:

  • ClusterExtensionInstallConfig
  • ClusterExtensionInstallStatus
  • ClusterExtensionResolutionStatus
  • ...

@yashoza19 yashoza19 force-pushed the issue1148 branch 2 times, most recently from 164da28 to cc8c5f2 Compare September 4, 2024 18:28
Copy link

codecov bot commented Sep 4, 2024

Codecov Report

Attention: Patch coverage is 60.27397% with 29 lines in your changes missing coverage. Please review.

Project coverage is 77.07%. Comparing base (f797d50) to head (55d91d0).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
api/v1alpha1/zz_generated.deepcopy.go 52.17% 21 Missing and 1 partial ⚠️
internal/applier/helm.go 42.85% 3 Missing and 1 partial ⚠️
...nternal/controllers/clusterextension_controller.go 75.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1200      +/-   ##
==========================================
- Coverage   77.56%   77.07%   -0.49%     
==========================================
  Files          36       36              
  Lines        1979     2020      +41     
==========================================
+ Hits         1535     1557      +22     
- Misses        309      328      +19     
  Partials      135      135              
Flag Coverage Δ
e2e 57.62% <57.53%> (-0.04%) ⬇️
unit 55.34% <19.17%> (-0.80%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment on lines +723 to +724
Name: "prometheus-operator.1.2.0",
Version: "1.2.0",
Copy link
Member

Choose a reason for hiding this comment

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

This is not a change I expect to see in a PR that is rearranging types. What's the background here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In order to compare the BundleMetadata to the new Resolution.Bundle spec, I had to make these changes.

Copy link
Contributor

Choose a reason for hiding this comment

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

To clarify, since these are in an Eventually block, the e2e tests were panicking due to accessing the nil clusterExtension.Status.Resolution object to get the Bundle field. Doing this compares the entire clusterExtension.Status.Resolution object and avoids a potential panic. Alternatively an explicit nil check could be done before attempting to access the Bundle field.

Copy link
Member

Choose a reason for hiding this comment

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

I should have been more specific in this comment (and it's no big deal since @tmshort fixed it in #1222), but what I was trying to ask is why this changed from 2.0.0 to 1.2.0.

I'm guessing that the Eventually aspect of this test is what tripped us up here. It is likely the case that the value is 1.2.0 when this check executes the first time, which explains why this would pass. However the purpose of this test is to see if a new catalog showing up under the same tag will trigger a re-reconcile and resolve a new version.

By setting this to 1.2.0, we were not actually testing what this test intended. Again, no big deal and the actual code was still behaving as expected, which is how Todd caught it.

However, I wonder: can we design our tests to be more robust against this kind of thing? Use of Eventually is likely the primary source of this problem because it implies both of:

  • the current state of the field is not what we expect (otherwise, we would just directly check it)
  • the value of the field we are asserting against will change over time.

And that means that the test can pass using any assertion that passes on any initial or transitory state of that field.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 4, 2024
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 4, 2024
Copy link
Contributor

@everettraven everettraven left a 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! Thanks @yashoza19 !

@everettraven everettraven added this pull request to the merge queue Sep 4, 2024
Merged via the queue into operator-framework:main with commit 557e28f Sep 4, 2024
15 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Logically group fields in the spec
4 participants