-
Notifications
You must be signed in to change notification settings - Fork 60
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
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
ba4c86b
to
2019ab1
Compare
ext.Status.Resolution.Bundle = nil | ||
ext.Status.Install.Bundle = nil |
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.
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:
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) { ... }
d3a7526
to
384ee03
Compare
hack/test/pre-upgrade-setup.sh
Outdated
namespace: default | ||
serviceAccount: |
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.
Indentation required?
resolvedBundleMetadata := bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion) | ||
resStatus := &ocv1alpha1.ResolutionStatus{ | ||
Bundle: &ocv1alpha1.BundleMetadata{ | ||
Name: resolvedBundleMetadata.Name, | ||
Version: resolvedBundleMetadata.Version, | ||
}, | ||
} |
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.
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), | |
} |
installedBundleMetadata := bundleutil.MetadataFor(resolvedBundle.Name, *resolvedBundleVersion) | ||
installStatus := &ocv1alpha1.InstallStatus{ | ||
Bundle: &ocv1alpha1.BundleMetadata{ | ||
Name: installedBundleMetadata.Name, | ||
Version: installedBundleMetadata.Version, | ||
}, | ||
} |
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.
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), | |
} |
if ext.Status.Resolution == nil { | ||
ext.Status.Resolution = &ocv1alpha1.ResolutionStatus{} | ||
} | ||
ext.Status.Resolution.Bundle = resStatus.Bundle |
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.
if ext.Status.Resolution == nil { | |
ext.Status.Resolution = &ocv1alpha1.ResolutionStatus{} | |
} | |
ext.Status.Resolution.Bundle = resStatus.Bundle | |
ext.Status.Resolution = resStatus |
if ext.Status.Install == nil { | ||
ext.Status.Install = &ocv1alpha1.InstallStatus{} | ||
} | ||
ext.Status.Install.Bundle = installStatus.Bundle |
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.
if ext.Status.Install == nil { | |
ext.Status.Install = &ocv1alpha1.InstallStatus{} | |
} | |
ext.Status.Install.Bundle = installStatus.Bundle | |
ext.Status.Install = installStatus |
7b6a04b
to
8e5835a
Compare
@@ -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) |
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 is probably where the e2e panic is
assert.Nil(ct, clusterExtension.Status.Resolution.Bundle) | |
assert.Nil(ct, clusterExtension.Status.Resolution) |
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.
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"` |
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.
Let's try to be consistent with word forms between field names and type names:
Install InstallationConfig `json:"install"` | |
Install InstallConfig `json:"install"` |
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, 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.
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.
Do you mean it should be ClusterExtensionInstallConfig
?
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 ClusterExtensionInstallConfig
is reasonable
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.
But I think @joelanford is referring to all the new types here. So something like:
ClusterExtensionInstallConfig
ClusterExtensionInstallStatus
ClusterExtensionResolutionStatus
- ...
164da28
to
cc8c5f2
Compare
Codecov ReportAttention: Patch coverage is
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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Name: "prometheus-operator.1.2.0", | ||
Version: "1.2.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.
This is not a change I expect to see in a PR that is rearranging types. What's the background here?
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.
In order to compare the BundleMetadata
to the new Resolution.Bundle
spec, I had to make these changes.
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.
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.
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 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.
Signed-off-by: yashoza19 <[email protected]>
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.
Looks good to me! Thanks @yashoza19 !
557e28f
Description
Fixes: #1148
Reviewer Checklist