Skip to content

✨ 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

Merged

Conversation

everettraven
Copy link
Contributor

@everettraven everettraven commented Sep 23, 2024

Description

  • Adds a new Progressing status condition
  • Removes unpack states that we never expect to be returned from our implementation, makes reconciliation panic if we get an unexpected state since it is a programmer error
  • Consolidates some unit tests
  • fixes [v1 API Review] Add Progressing status condition #1292

Reviewer Checklist

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

@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 Sep 23, 2024
Copy link

netlify bot commented Sep 23, 2024

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit 04c1b85
🔍 Latest deploy log https://app.netlify.com/sites/olmv1/deploys/66f3174339b5ea00088c174e
😎 Deploy Preview https://deploy-preview-1302--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.

Copy link

codecov bot commented Sep 23, 2024

Codecov Report

Attention: Patch coverage is 93.75000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 76.58%. Comparing base (eea61cf) to head (04c1b85).
Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
...nternal/controllers/clusterextension_controller.go 85.71% 2 Missing ⚠️
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              
Flag Coverage Δ
e2e 58.72% <71.87%> (+0.27%) ⬆️
unit 53.08% <93.75%> (+0.28%) ⬆️

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.

require.NoError(t, cl.DeleteAllOf(ctx, &ocv1alpha1.ClusterExtension{}))
}

func TestClusterExtensionResolutionSucceeds(t *testing.T) {
Copy link
Contributor Author

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.

Copy link
Contributor Author

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) {
Copy link
Contributor Author

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.

Comment on lines -301 to -326
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{}))
}
Copy link
Contributor Author

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.

Comment on lines -62 to -70
// 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"

Copy link
Contributor Author

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.

@everettraven everettraven force-pushed the status/progressing-condition branch from b2a83b4 to e669088 Compare September 24, 2024 15:46
@everettraven everettraven changed the title WIP: add progressing condition ✨ add progressing condition Sep 24, 2024
@everettraven everettraven marked this pull request as ready for review September 24, 2024 15:48
@everettraven everettraven requested a review from a team as a code owner September 24, 2024 15:48
@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 Sep 24, 2024
case rukpaksource.StatePending:
setStatusUnpackFailed(ext, unpackResult.Message)
ensureAllConditionsWithReason(ext, ocv1alpha1.ReasonFailed, "unpack pending")
return ctrl.Result{}, nil
case rukpaksource.StateUnpacked:
setStatusUnpacked(ext, unpackResult.Message)
Copy link
Contributor

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) ?

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 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)

Copy link
Member

@joelanford joelanford Sep 24, 2024

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.

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 this is reasonable

Copy link
Contributor Author

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

@tmshort
Copy link
Contributor

tmshort commented Sep 24, 2024

This has conflicts with removing the "Healthy" condition in #1304...

@everettraven everettraven force-pushed the status/progressing-condition branch from e669088 to 63b56c0 Compare September 24, 2024 19:41
@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 24, 2024
Signed-off-by: everettraven <[email protected]>
@everettraven everettraven force-pushed the status/progressing-condition branch from 63b56c0 to 53f3d9e Compare September 24, 2024 19:44
@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 24, 2024
@joelanford joelanford added this pull request to the merge queue Sep 25, 2024
Merged via the queue into operator-framework:main with commit 679e4ab Sep 25, 2024
18 of 19 checks passed
@skattoju skattoju mentioned this pull request Sep 25, 2024
4 tasks
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.

[v1 API Review] Add Progressing status condition
5 participants