-
Notifications
You must be signed in to change notification settings - Fork 54
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
✨ (feat): add graph deprecation logic #574
✨ (feat): add graph deprecation logic #574
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #574 +/- ##
==========================================
+ Coverage 83.60% 84.35% +0.75%
==========================================
Files 20 20
Lines 811 933 +122
==========================================
+ Hits 678 787 +109
- Misses 92 102 +10
- Partials 41 44 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@@ -140,6 +145,10 @@ func (b *Bundle) propertiesByType(propType string) []*property.Property { | |||
return b.propertiesMap[propType] | |||
} | |||
|
|||
func (b *Bundle) HasDeprecation() bool { |
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.
Nit-picky but maybe:
func (b *Bundle) HasDeprecation() bool { | |
func (b *Bundle) IsDeprecated() bool { |
reads a little better to me.
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 can see that. Reason I went with HasDeprecation
is more so because of the potentially confusing classification of "Deprecated" in this case. If a channel is deprecated, that doesn't necessarily mean every bundle in that channel is deprecated. The ClusterExtension
would be marked deprecated if it specifically asks for that channel but otherwise that deprecation notice wouldn't show up. Due to this I felt HasDeprecation
was more like asking "Are there any deprecations that are associated with this bundle?" rather than "Is this bundle deprecated?"
That being said, I'm not opposed to changing this. I do feel that IsDeprecated()
could be a bit misleading without having a deeper understanding of how the deprecation concept works.
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.
Ah good point, and as you noted I myself also misunderstood the concept here by thinking that all bundles under a deprecated channel were also considered deprecated. If that's not the case then I agree with HasDeprecation()
.
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.
Sounds like a good place to add GoDoc :)
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.
One thing to point out with this that I thought about while writing the GoDoc is that during resolution if the bundle is associated with any deprecations it will be less preferred over other bundles even if it is an olm.channel deprecation that isn't being considered due to the specification of using a different channel.
For example, given the following set of bundles in a desired channel stable
:
foo.v1.0.0
foo.v1.1.0
foo.v2.0.0
foo.v2.1.0
foo.v3.0.0 <-- associated with a deprecated channel named stable-v3 due to $reasons
The resulting resolution list in order of most preferred -> least preferred would be:
foo.v2.1.0
foo.v2.0.0
foo.v1.1.0
foo.v1.0.0
foo.v3.0.0
This feels like a scenario we may want to avoid by having a distinction between a bundle having explicit deprecation due to the package or itself being deprecated and the looser deprecation associated with the bundle being an entry within a deprecated channel
Do other folks feel this scenario should be avoided as well? I could also see an argument for preferring any bundle with associated deprecations than ones with none, and if that is the functionality we want then no changes would be needed here.
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.
cc @joelanford @grokspawn ^
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've updated the implementation in 9186d16 to avoid the scenario I mentioned above
f91c589
to
33de0a6
Compare
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.
You've taken care of my concerns here and also handled the channel deprecation case well in my opinion, thanks!
I'll hold off on explicit approval for now just to make sure that some of the other reviewers get a chance to look at things :)
to signal when an installed bundle has deprecations associated with it and prefer bundles with deprecations less than non-deprecated bundles Signed-off-by: everettraven <[email protected]>
201244b
to
678c58e
Compare
Description
ClusterExtension
has deprecations associated with itcatalogmetadata.Bundle
type to have fields to hold the deprecation information for a bundleClusterExtension
reconciler logic to add the deprecation statuses if there are any associated with the installed bundleMotivation
Operator
#526ForceSemverUpgradeConstraints=false
prefer deprecated bundles less during install/upgrade #527Reviewer Checklist