Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Prevent OLM from creating
InstallPlan
s when bundle unpack fails #2942Prevent OLM from creating
InstallPlan
s when bundle unpack fails #2942Changes from all commits
698e4d6
c96f4d8
41d17f6
9ed3d83
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 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.
Apologies if I'm not understanding the order of operations correctly here, but does this condition not become true before calling
ensureInstallPlan
? Or in other words shouldn't these status updates come on line 1110?Or else, are we saying that a bundle unpack isn't successful until an
InstallPlan
is successfully created with the unpacked bundles?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.
Your understanding is correct. Order is as follows:
o.unpackBundles(...)
SubscriptionBundleUnpackFailed
(in case of errors) orSubscriptionBundleUnpacking
(in case when we still waiting on the unpack job) toTrue
. I believeSubscriptionBundleUnpacking
will be the most common on the first run when syncing with a new bundle.InstallPlan
ino.ensureInstallPlan(...)
InstallPlan
here, but syncing of theInstallPlan
is a separate process - (seeo.syncInstallPlans
)SubscriptionBundleUnpackFailed
on subs (if any exist) and we setSubscriptionBundleUnpacking
toFalse
.Technically unpack can be successfull without successfull
InstallPlan
creation. But in terms of current implementation in this PR - you are right.I considered removing
SubscriptionBundleUnpackFailed
and settingSubscriptionBundleUnpacking
toFalse
beforeo.ensureInstallPlan(...)
, but it makes syncing a bit more complex becaues we would have to do two updates to the subs. We would have to implement something like this:SubscriptionBundleUnpackFailed
and settingSubscriptionBundleUnpacking
toFalse
o.updateSubscriptionStatuses(subs)
<--- First updateo.ensureInstallPlan(...)
ando.setIPReference(...)
o.updateSubscriptionStatuses(subs)
<--- Second updateInstead we just do:
o.ensureInstallPlan(...)
ando.setIPReference(...)
SubscriptionBundleUnpackFailed
and settingSubscriptionBundleUnpacking
toFalse
o.updateSubscriptionStatuses(subs)
<--- The only update to subs at the endSo it is a bit of optimisation, but I'm happy to reconsider. Let me know if you see an issue with this.
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.
Thanks for answering, I appreciate the level of detail!
I'm fine with what you have here to keep API calls to a minimum. We probably don't need such a fine-grained level of tracing for the process anyway - I mostly wanted to make sure there was intention behind it. We can keep it the way you have it :)