-
Notifications
You must be signed in to change notification settings - Fork 1.8k
feat: add --catalog-only flag to run bundle command #6952
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
Closed
kaovilai
wants to merge
1
commit into
operator-framework:master
from
kaovilai:feature/catalog-only-flag
Closed
Changes from all commits
Commits
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
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.
Thank you for taking the time to look into this and contribute to the project!
A few questions to better understand the need for this flag:
Also, if we move forward with adding this flag, we’ll need to make sure tests properly cover it.
Could you please take a look at that as well?
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.
I also don't understand the need for this, there are n number of other ways to create a catalog/subscription.
oc apply -f - <<'EOF'with the file contentUh oh!
There was an error while loading. Please reload this page.
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.
Of course there is always a more manual way.. this is just a way to reuse your (operator-sdk) existing logic around creating catalogsource from an already existing bundle image.
See here
The subscription created by operator-sdk run bundle does not have the right env etc and requries deletion. It's just inconvenient that we have do maintain another target for creating a bundle image, push, catalogsource, push.. when that already exists here except it also creates subscription without all the required environments.
Uh oh!
There was an error while loading. Please reload this page.
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.
By this logic,
operator-sdk run bundledoesn't need to exists at all.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.
For what it's worth, I think this feature request makes a lot of sense. There's a bunch of special sauce in
run bundleto get a working catalogsource in place without having to build/push a catalog image that would be impractical to duplicate elsewhere. And as far as I know, therun bundlecode has required very little maintenance.To me this seems like a simple change that can solve a real problem.
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.
Fair, but I think the thinking at the time was that
operator-sdkwas a natural place becauserun bundlewas geared toward operator authors and they were likely usingoperator-sdkto generate their bundle.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.
RFE created. Thanks all.
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 repo suggestions would be cool as well. If OPM is the most appropriate I can PR there.
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.
Thank you so much for the RFE — it’s amazing! 🙌
Just to clarify: OPM is the tool used to create catalogs, so we don’t need to open a PR there.
That said, I totally understand the frustration around the number of tools and the lack of abstraction — you're not alone on that!
For now, I think a good approach would be:
Reference
Check out this guide: https://olm.operatorframework.io/docs/tasks/creating-a-catalog/
The pipeline uses OPM and render to produce a final FBC format.
Feel free to reach out us in the Slack channel if you find issues with OPM to do your scenario and need a help.