-
Notifications
You must be signed in to change notification settings - Fork 64
✨ 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
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 #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
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
0601479
to
170974b
Compare
// 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 | ||
} |
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 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?
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.
These checks should be able to be removed once we do a release, as they're only necessary for the upgrade.
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.
We didn't previously check for for empty, but we still might want to consider doing it.
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.
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.
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.
After v1, it seems there are three possibilities for missing labels on the release:
- We make a new release that adds a new label (say in
1.2
), but we just upgraded from1.1
, so any releases that exist prior to1.2
would not have all of1.2
's expected labels. - Something deleted our labels.
- We introduced a bug somehow where we didn't set the labels.
// If both conditions occur, this is a failed Apply when a bundle was already installed | ||
if err != nil { | ||
setInstalledStatusConditionFailed(ext, err.Error()) |
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.
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.
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 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.
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.
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...
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.
There's additional discussion here: #1379 (comment)
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 note, that this change (no longer preserving Installed
after the Apply()
) is a separate fixup commit, so it can be looked at in isolation.
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 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.
7d8a1ae
to
1b55cde
Compare
// 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 | ||
} |
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 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.
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 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.
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 plan to clean this up after a release and a clean upgrade-e2e.
// Now that we're actually trying to install, use the error | ||
setInstalledStatusFromBundle(ext, installedBundle, err) |
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.
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:
// 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) |
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.
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))
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 err
is nil in here, then the result will be a message of "No install bundle found", rather than the installation error from err
.
8e97ae0
to
1b74d9f
Compare
Signed-off-by: Todd Short <[email protected]>
Latest fixes for #1296
Description
Reviewer Checklist