-
Notifications
You must be signed in to change notification settings - Fork 65
✨ add progressing condition #1302
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
✨ add progressing condition #1302
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1302 +/- ##
==========================================
+ Coverage 76.44% 76.58% +0.14%
==========================================
Files 40 40
Lines 2390 2413 +23
==========================================
+ Hits 1827 1848 +21
- Misses 395 397 +2
Partials 168 168
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
require.NoError(t, cl.DeleteAllOf(ctx, &ocv1alpha1.ClusterExtension{})) | ||
} | ||
|
||
func TestClusterExtensionResolutionSucceeds(t *testing.T) { |
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.
Removed this test function because I don't think we should be using a state we never expect to be returned as part of our standard code paths in a mock to end reconciliation without an error but still have successful resolution. Removing the unused, outside of testing, unpack states resulted in making the mock unpacker return an error. We already had a test (immediately after this one I think) that did this same logic so I renamed it and removed this test.
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.
Note: the github diff view makes this look a tad wonky
require.NoError(t, cl.DeleteAllOf(ctx, &ocv1alpha1.ClusterExtension{})) | ||
} | ||
|
||
func TestClusterExtensionUnpackSucceeds(t *testing.T) { |
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.
Removed this particular test function because it tests when unpack succeeds but the applier returns an error. We already have a test immediately after this one that tests the same functionality. I updated the name of the remaining test function to capture that it tests both unpack succeeding and applier failing.
res, err := reconciler.Reconcile(ctx, ctrl.Request{NamespacedName: extKey}) | ||
require.Equal(t, ctrl.Result{}, res) | ||
require.Error(t, err) | ||
|
||
t.Log("By fetching updated cluster extension after reconcile") | ||
require.NoError(t, cl.Get(ctx, extKey, clusterExtension)) | ||
|
||
t.Log("By checking the status fields") | ||
require.Equal(t, ocv1alpha1.BundleMetadata{Name: "prometheus.v1.0.0", Version: "1.0.0"}, clusterExtension.Status.Resolution.Bundle) | ||
require.Empty(t, clusterExtension.Status.Install) | ||
|
||
t.Log("By checking the expected conditions") | ||
resolvedCond := apimeta.FindStatusCondition(clusterExtension.Status.Conditions, ocv1alpha1.TypeResolved) | ||
require.NotNil(t, resolvedCond) | ||
require.Equal(t, metav1.ConditionTrue, resolvedCond.Status) | ||
require.Equal(t, ocv1alpha1.ReasonSuccess, resolvedCond.Reason) | ||
require.Equal(t, "resolved to \"quay.io/operatorhubio/[email protected]\"", resolvedCond.Message) | ||
|
||
t.Log("By checking the expected unpacked conditions") | ||
unpackedCond := apimeta.FindStatusCondition(clusterExtension.Status.Conditions, ocv1alpha1.TypeUnpacked) | ||
require.NotNil(t, unpackedCond) | ||
require.Equal(t, metav1.ConditionFalse, unpackedCond.Status) | ||
require.Equal(t, ocv1alpha1.ReasonFailed, unpackedCond.Reason) | ||
|
||
require.NoError(t, cl.DeleteAllOf(ctx, &ocv1alpha1.ClusterExtension{})) | ||
} |
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.
Note: this github diff view is showing weird due to the code that was removed vs added. Since this is related to testing for an unexpected unpack state, which is a programmer error, this test now checks that Reconcile()
panics.
// StatePending conveys that a request for unpacking a bundle has been | ||
// acknowledged, but not yet started. | ||
StatePending State = "Pending" | ||
|
||
// StateUnpacking conveys that the source is currently unpacking a bundle. | ||
// This state should be used when the bundle contents are being downloaded | ||
// and processed. | ||
StateUnpacking State = "Unpacking" | ||
|
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 somewhat outside of the scope of the intent of this PR, but while I was identifying where to set the Progressing
condition I noted that we don't ever expect these unpack states from being returned. I figured it is a small enough change that it made sense to include it as part of this PR.
b2a83b4
to
e669088
Compare
case rukpaksource.StatePending: | ||
setStatusUnpackFailed(ext, unpackResult.Message) | ||
ensureAllConditionsWithReason(ext, ocv1alpha1.ReasonFailed, "unpack pending") | ||
return ctrl.Result{}, nil | ||
case rukpaksource.StateUnpacked: | ||
setStatusUnpacked(ext, unpackResult.Message) |
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.
Should we setStatusProgressing here ? or just remove this completely (probably in the removed unpacked status 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.
I would anticipate that we remove it completely in the unpacked status PR. There isn't really any value to setting it here since if there are no errors throughout reconciliation we set it to False, Succeeded
require.NotNil(t, progressingCond) | ||
require.Equal(t, metav1.ConditionTrue, progressingCond.Status) | ||
require.Equal(t, ocv1alpha1.ReasonRetrying, progressingCond.Reason) | ||
|
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.
Since we expect the Progressing
condition message to be the place that contains details of the resolution (if we progress that far), and there will eventually be no other place with that information, I think we should have some test assertions that look for <name>, <version>, and maybe <resolvedImageRef> in the message.
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 this 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.
should be updated in the latest push
This has conflicts with removing the "Healthy" condition in #1304... |
e669088
to
63b56c0
Compare
Signed-off-by: everettraven <[email protected]>
63b56c0
to
53f3d9e
Compare
Signed-off-by: everettraven <[email protected]>
679e4ab
Description
Progressing
status conditionProgressing
status condition #1292Reviewer Checklist