-
Notifications
You must be signed in to change notification settings - Fork 62
✨ Add support for installing bundles with webhooks #1914
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
Open
perdasilva
wants to merge
7
commits into
operator-framework:main
Choose a base branch
from
perdasilva:add-wh-support
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
749e24e
add webhook bundle validators
fe2a208
Add webhook support
7f8d3b6
Update webhook configuration naming
f982c45
Harden ToUnstructured and add unit tests
9427d28
Move cert provider option to render
05f4d6b
Add resource name validation
1da5dd5
Add name validation for strategy deployment and webhook configurations
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
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.
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 we want to add support for new providers later, how do you envision that looking from a feature gate standpoint?
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.
From what I understand, downstream will use a different provider, but the implementation remains the same.
I don’t see a strong need to support multiple providers upstream for now — downstream will likely stick with one as well. Since this is under an alpha flag, we have flexibility to adjust later.
So I think this is fine as-is and no need to optimize prematurely. We can revisit if we decide to support more providers in the future.
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 think you are missing my point (which I should have explained a bit better 😅 ). Let's say we implement webhook support now with cert-manager, but then later decide we want to add a separate implementation (e.g.
BuiltInor OPA's cert-controller)?My point is, I think there is a difference between "we support webhooks" and "we support a certain certificate provider".
I would suggest calling this
WebhookProviderCertManagerso that if/when we introduce other cert providers upstream, we don't have a strange naming convention whereWebhookSupportactually means cert-manager webhook support andWebhookSupportFooBarmeans "webhook support with the foobar provider".And then once at least one provider's feature gate graduates to GA, then we can say that we support bundles with webhooks.
I also think we should explore implementing OCP's Service CA provider in our upstream.
That would benefit Red Hat: if Red Hat implements it only downstream, they (we) would have to carry patches in the downstream codebase that could invite conflicts when syncing. There is no precedent yet for carrying a patch in the downstream Go source code, and I'm not convinced it makes sense to change that for this feature.
It would also benefit other users of OCP. For example, if an OCP user wants to disable OCP's OLM and use upstream OLM instead, they would still be able to use the service-ca provider. We've talked about this possibility with SRE organizations that provide managed OpenShift and that want a consistent OLM surface across a fleet of OCP clusters with varying OCP versions.
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 general benefit: If we use a naming convention like
WebhookProvider<ProviderName>for the feature gates, we can directly translate the set of enabled webhook providers to a--webhook-providerflag's presence and the set of allowed values (i.e. the set of<ProviderName>suffixes).Then, distro maintainers retain the choice of:
All this driven by the feature gate naming convention.