Open rashmigottipati opened 2 years ago
I removed the release-blocker label because this turns out to be more of an RFE than a bug.
Removed the milestone for re-triage. @jmrodri thoughts?
There was some internal discussion a while back about what possibly needs to be done to resolve this. To make it more transparent and easier to find I wanted to copy that discussion over here:
Things that likely need to be done:
<operator-name>-index.Dockerfile
<operator-name>-index
<operator-name>-index/index.yaml
file OR run the command:
$ opm init <operator_name> \
--default-channel=preview \
--description=./README.md \
--icon=./operator-icon.svg \
--output yaml \
> <operator_name>-index/index.yaml
<operator-name>-index/index.yaml
file<operator-name>-index/index.yaml
fileopm validate
docker build . \
-f <operator_name>-index.Dockerfile \
-t <registry>/<namespace>/<catalog_image_name>:<tag>
/unassign jmrodri
I don't think this one is ready to be worked. The existing makefile targets assume an imperative flow where new bundles can be added to existing catalogs. File-based catalogs are a major change because an individual bundle (which is the context of an individual commit of an operator-sdk project) no longer carries upgrade edge information necessary to add that bundle to a catalog.
IMO any work related to this is blocked until we have more answers about the way we expect upstream users to build and maintain file-based catalogs.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen
.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
/lifecycle frozen
/lifecycle frozen
Facing same issue. Any update ? How/When can we have FBC: catalog-build target in Makefile ?
Facing same issue. Any update ? How/When can we have FBC: catalog-build target in Makefile ?
@Nilesh20 this issue is still blocked by Joe's comment in https://github.com/operator-framework/operator-sdk/issues/5832#issuecomment-1377612560
Is there any plan to update the opm index add
command to support File Based Catalogs (FBC), any time soon? This ticket has been open for 1.5 years. We depend on the opm index
commands for our automation to test Operator upgrades and install scenarios. The RedHat Marketplace catalog moved to FBC long ago with OpenShift 4.11. Kindly provide an update. Thanks.
This is important for operators that expect OLM to manage install and uninstall with file-based catalogs. The current Makefile target is in fact broken if a developer wants to "shim" their bundle into an existing FBC catalog.
For the Red Hat OpenShift Builds operator, I was able to template a test FBC catalog that could be built and deployed as part of a developer "inner loop": https://github.com/redhat-openshift-builds/operator/pull/38
Bug Report
What did you do?
The catalog-build target in Makefile still uses
opm index add
to generate a SQLite catalog index image. This needs to be updated to generating an FBC index image as we will be defaulting to using File-Based Catalogs once PR is merged into master.How reproducible: Always
Steps to Reproduce:
What did you expect to see?
Generate the FBC index image in the following way: $ mkdir catalog $ opm generate dockerfile catalog $ mkdir catalog/xxxx $ opm init xxxx -c alpha -o yaml > catalog/xxxx/index.yaml $ opm render quay.io/test/xxxx:v1.0 -o yaml >> catalog/xxxx/index.yaml
What did you see instead? Under which circumstances?
Environment
$ operator-sdk version
operator-sdk version: "v1.20.0-16-g38b8b8d9", commit: "38b8b8d949578a44fb23319e56c242fd620523ca", kubernetes version: "v1.23", go version: "go1.17.4", GOOS: "linux", GOARCH: "amd64"
$ go version
(if language is Go)go version: "go1.17.4"