feat: add --catalog-only flag to run bundle command#6952
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
kaovilai
force-pushed
the
feature/catalog-only-flag
branch
from
e488aef to
0e7f3d4
Compare
Add a new --catalog-only flag to the 'operator-sdk run bundle' command that creates only the catalog source without creating a subscription. This allows users to deploy the catalog source for manual subscription management or for use with other tools. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
kaovilai
force-pushed
the
feature/catalog-only-flag
branch
from
0e7f3d4 to
271fcdf
Compare
| "the registry pod to decompress the compressed catalog contents. cat and gzip binaries are expected to exist "+ | ||
| "in the PATH") | ||
| fs.Var(&i.InstallMode, "install-mode", "install mode") | ||
| fs.BoolVar(&i.CatalogOnly, "catalog-only", false, "create only the catalog source without creating a subscription") |
There was a problem hiding this comment.
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:
- How do you plan to use it?
- Why do you believe this flag should be added?
- What is the use case or scenario it addresses?
- Can you describe the expected flow and how this change would help?
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.
Currently, the operator-sdk run bundle command creates both a catalog source and a subscription. However, there are use cases where users need only the catalog source:
Testing tokenized auth install flows: For testing the OpenShift Console's operator install frontend with tokenized authentication (see operator-hub-subscribe.tsx#L502-L555), automatic subscription creation is not desirable. The frontend needs to handle the subscription creation flow itself to properly manage authentication tokens.
Manual subscription management: Users may want to create the catalog source first and then manually create subscriptions with specific configurations
Integration with other tools: Other automation tools or operators may need to create subscriptions programmatically after the catalog source is available
Testing: Developers may want to test catalog source creation independently from operator installation
Multi-tenant scenarios: In environments where different teams manage catalog sources and subscriptions separately
There was a problem hiding this comment.
I also don't understand the need for this, there are n number of other ways to create a catalog/subscription.
- call
oc apply -f - <<'EOF'with the file content - call the api in code via k8s libraries
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I also don't understand the need for this, there are n number of other ways to create a catalog/subscription.
call oc apply -f - <<'EOF' with the file content
call the api in code via k8s libraries
By this logic, operator-sdk run bundle doesn't need to exists at all.
There was a problem hiding this comment.
For what it's worth, I think this feature request makes a lot of sense. There's a bunch of special sauce in run bundle to 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, the run bundle code 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.
@joelanford my keyword was 'here', as in this repo.
Fair, but I think the thinking at the time was that operator-sdk was a natural place because run bundle was geared toward operator authors and they were likely using operator-sdk to generate their bundle.
There was a problem hiding this comment.
my keyword was 'here', as in this repo.
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.
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:
- In SDK scaffold you have a target to install OPM already: https://github.com/operator-framework/operator-sdk/blob/master/testdata/go/v4/memcached-operator/Makefile#L302-L315
- You might want add a new target to automate your use case. You can create a target to generate your catalog, add your solution, and more.
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.
|
Closing as this prob won't get merged as is. Video_Ready_Tiger_s_Farewell.mp4 |
4 participants
Add a new --catalog-only flag to the 'operator-sdk run bundle' command
that creates only the catalog source without creating a subscription.
This allows users to deploy the catalog source for manual subscription
management or for use with other tools.
🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com
Description of the change:
This PR adds a new
--catalog-onlyflag to theoperator-sdk run bundlecommand. When this flag is used, the command creates only the catalog source without creating a subscription, operator group, or install plan.The implementation includes:
CatalogOnly boolfield to theInstallstruct ininternal/olm/operator/bundle/install.go--catalog-onlyflag binding with description "create only the catalog source without creating a subscription"RunCatalogOnlymethod that creates the catalog source using the existingCatalogCreator.CreateCatalogmethod and logs that subscription creation is being skippedRunmethod to check ifCatalogOnlyis true and route toRunCatalogOnlyinstead ofInstallOperatorMotivation for the change:
Currently, the
operator-sdk run bundlecommand creates both a catalog source and a subscription. However, there are use cases where users need only the catalog source:This change provides more flexibility in how users can deploy and manage operators using the SDK.
Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments(seechangelog/fragments/00-template.yaml)website/content/en/docs