Skip to content

✨ Use Helm List operator to determine Deployed status #1379

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
merged 1 commit into from
Oct 23, 2024

Conversation

tmshort
Copy link
Contributor

@tmshort tmshort commented Oct 15, 2024

Latest fixes for #1296

Description

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 Oct 15, 2024
Copy link

netlify bot commented Oct 15, 2024

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit b557ff6
🔍 Latest deploy log https://app.netlify.com/sites/olmv1/deploys/6719438237399b00083293e7
😎 Deploy Preview https://deploy-preview-1379--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 Oct 15, 2024

Codecov Report

Attention: Patch coverage is 73.43750% with 17 lines in your changes missing coverage. Please review.

Project coverage is 73.40%. Comparing base (6f42274) to head (b557ff6).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...nternal/controllers/clusterextension_controller.go 77.50% 7 Missing and 2 partials ⚠️
internal/controllers/common_controller.go 60.00% 8 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1379      +/-   ##
==========================================
+ Coverage   73.31%   73.40%   +0.09%     
==========================================
  Files          42       42              
  Lines        3166     3200      +34     
==========================================
+ Hits         2321     2349      +28     
- Misses        659      664       +5     
- Partials      186      187       +1     
Flag Coverage Δ
e2e 55.03% <71.87%> (+0.19%) ⬆️
unit 53.25% <73.43%> (+0.69%) ⬆️

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.

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 17, 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 Oct 17, 2024
@tmshort tmshort marked this pull request as ready for review October 17, 2024 21:26
@tmshort tmshort requested a review from a team as a code owner October 17, 2024 21:26
@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 Oct 17, 2024
@tmshort tmshort force-pushed the helm-status branch 2 times, most recently from 0601479 to 170974b Compare October 18, 2024 16:18
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 19, 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 Oct 21, 2024
Comment on lines +500 to +502
// If there are blank values, we should consider this as not installed
if n, ok := rel.Labels[labels.BundleNameKey]; !ok || n == "" {
return nil, nil
}
if v, ok := rel.Labels[labels.BundleVersionKey]; !ok || v == "" {
return nil, nil
}
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 return early in these cases or continue looking for the next successfully deployed release that contains these labels?

Is there any case where we wouldn't have set the labels on a release or is the absence of these labels indicative of a much bigger issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These checks should be able to be removed once we do a release, as they're only necessary for the upgrade.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We didn't previously check for for empty, but we still might want to consider doing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is there any case where we wouldn't have set the labels on a release or is the absence of these labels indicative of a much bigger issue?

I was a bit concerned about this possibility. If the labels are empty, we don't know the bundle or version, so something is wrong.

Copy link
Member

Choose a reason for hiding this comment

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

After v1, it seems there are three possibilities for missing labels on the release:

  1. We make a new release that adds a new label (say in 1.2), but we just upgraded from 1.1, so any releases that exist prior to 1.2 would not have all of 1.2's expected labels.
  2. Something deleted our labels.
  3. We introduced a bug somehow where we didn't set the labels.

Comment on lines 38 to 40
// If both conditions occur, this is a failed Apply when a bundle was already installed
if err != nil {
setInstalledStatusConditionFailed(ext, err.Error())
Copy link
Contributor

Choose a reason for hiding this comment

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

Wouldn't we want to preserve the historical installation information on a failed "upgrade" attempt, which is what I interpret a "failed Apply when a bundle was already installed" to mean.

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 was concerned about this, but the problem is that we lose the fact that we failed an upgrade. I'm not sure which is better. But this is what @joelanford suggested.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Another way to look at it: if we tried an install, we store the bundle information. Should we not have the same information on an upgrade?
I almost think we need to have an upgrade 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.

There's additional discussion here: #1379 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also note, that this change (no longer preserving Installed after the Apply()) is a separate fixup commit, so it can be looked at in isolation.

Copy link
Contributor

Choose a reason for hiding this comment

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

If a ClusterExtension has been installed successfully in the past, we should keep the installed condition as is and include the upgrade failure information in the progressing condition. The resolution information can be included in the error message so that a user can better connect the dots that an upgrade failed and what bundles were involved.

Comment on lines +500 to +502
// If there are blank values, we should consider this as not installed
if n, ok := rel.Labels[labels.BundleNameKey]; !ok || n == "" {
return nil, nil
}
if v, ok := rel.Labels[labels.BundleVersionKey]; !ok || v == "" {
return nil, nil
}
Copy link
Member

Choose a reason for hiding this comment

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

I personally think we should return an error if the expected labels are missing. Or the resolver should return an error if the installedBundle is non-nil, but then expected struct fields are unset.

I don't think it makes sense to assume "not installed" because clearly something is installed.

Copy link
Contributor Author

@tmshort tmshort Oct 22, 2024

Choose a reason for hiding this comment

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

This occurs in the e2e-upgrade; seemingly. But we can't tell if it's a temporary property of the lack of a helm-operater-plugin update, or something else.

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 plan to clean this up after a release and a clean upgrade-e2e.

Comment on lines 294 to 295
// Now that we're actually trying to install, use the error
setInstalledStatusFromBundle(ext, installedBundle, err)
Copy link
Member

@joelanford joelanford Oct 23, 2024

Choose a reason for hiding this comment

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

Yesterday we said:

  • Failed install
    • status.conditions[Installed] = false
  • Failed upgrade
    • status.conditions[Installed] = true, message indicates successfully installed bundle ref

So should this be:

Suggested change
// Now that we're actually trying to install, use the error
setInstalledStatusFromBundle(ext, installedBundle, err)
// Now that we're actually trying to install, use the error
setInstalledStatusFromBundle(ext, installedBundle, nil)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, we want the err in there, the code is correct.

A failed (initial) install means that installedBundle is nil, and err is not nil, so the following happens:

setInstallStatus(ext, nil)
setInstalledStatusConditionFailed(ext, err.Error())

A failed upgrade means that installedBundle is not nil, and err is not nil, so the following happens:

setInstallStatus(ext, installStatus)
setInstalledStatusConditionSuccess(ext, fmt.Sprintf("Installed bundle %s successfully", installedBundle.Image))

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If err is nil in here, then the result will be a message of "No install bundle found", rather than the installation error from err.

@tmshort tmshort force-pushed the helm-status branch 2 times, most recently from 8e97ae0 to 1b74d9f Compare October 23, 2024 18:03
joelanford
joelanford previously approved these changes Oct 23, 2024
@tmshort tmshort added this pull request to the merge queue Oct 23, 2024
Merged via the queue into operator-framework:main with commit 1cb254c Oct 23, 2024
19 checks passed
@tmshort tmshort deleted the helm-status branch October 23, 2024 20:23
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.

5 participants