Operator install fails to find the bundle after this commit: 6a065947e60f3f2afc1dd3b934cbc802696a1807

[rgomez-casa]

The indexes built since the lastest image of the upstream-opm-builder was released with this commit: 6a06594

6a06594#diff-2980e058bdab1972cf3ef402d7ca4ac938e2f7f93130c9164610a2716303704e

Are not producing a working catalog we can subscribe to.

Subscribing to the operator causes this error, and does not produce and CSV or Install Plan.

E0804 17:45:18.483224 1 queueinformer_operator.go:290] sync {"update" "openshift-operators"} failed: constraints not satisfiable: no operators found matching the subscription criteria for my-operator, a subscription to package my-operator exists in the namespace
I0804 17:45:18.483478 1 event.go:282] Event(v1.ObjectReference{Kind:"Namespace", Namespace:"", Name:"openshift-operators", UID:"b0e3c148-aa21-420c-b115-e42785e5e92c", APIVersion:"v1", ResourceVersion:"1115", FieldPath:""}): type: 'Warning' reason: 'ResolutionFailed' constraints not satisfiable: no operators found matching the subscription criteria for my-operator, a subscription to package my-operator exists in the namespace

Using images prior to that commit as base images, like this one:

quay.io/operator-framework/upstream-opm-builder@sha256:49a3dc17e128c1fa687b9237780d95d522359b304aa8a94b9eee0ee66e792b1b

works fine and produce a valid CSV and Install Plan.

This was tested on Openshift 4.7.0.

[benluddy]

Do you see https://github.com/operator-framework/operator-lifecycle-manager/blob/4b67acc560a790caa37fdff2f2c1a1eb50a4949f/pkg/controller/registry/resolver/operators.go#L282 in the logs for catalog-operator? If so, please watch https://bugzilla.redhat.com/show_bug.cgi?id=1986932 for a fix in an upcoming 4.7.z release.

Otherwise, if you're able to share an index image or a SQLite registry database that reproduces what you're seeing, that would be helpful.

[rgomez-casa]

Hello @benluddy,

We get that error you mention in the logs, but it refers to a different catalog, the community operators one, not with our catalogs. We'll take a look to the bug you mentioned anyway.

But in our case the error is related to the /bin/opm binary in the image of the catalog.

The same SQLite registry database produces the error or not depending on the /bin/opm binary, and we have verified this with different databases and different operators.

We've identified that binaries generated prior to the commit above behave as expected and binaries generated after that commit present this error, even with different images.

index.db.gz

For example, the attached index shows the error when built with this docker file:

FROM quay.io/operator-framework/upstream-opm-builder
LABEL operators.operatorframework.io.index.database.v1=/database/index.db
ADD database/index.db /database/index.db
EXPOSE 50051
ENTRYPOINT ["/bin/opm"]
CMD ["registry", "serve", "--database", "/database/index.db"]

But it works correctly when build with this one:

FROM quay.io/operator-framework/upstream-opm-builder@sha256:49a3dc17e128c1fa687b9237780d95d522359b304aa8a94b9eee0ee66e792b1b
LABEL operators.operatorframework.io.index.database.v1=/database/index.db
ADD database/index.db /database/index.db
EXPOSE 50051
ENTRYPOINT ["/bin/opm"]
CMD ["registry", "serve", "--database", "/database/index.db"]

Regards,
Roberto.

[benluddy]

Thanks for providing that database file.

I can't imagine another explanation for what you're observing other than the one I shared initially. However, I do see that your operator does not provide or require any APIs, and the database is on schema version 8 which is quite old and earlier than the introduction of the properties table. Still, I would have expected schema migration 9 to automatically generate at least one property, which would have saved you from triggering this compatibility mode.

On looking at schema migration 9, I noticed that it would not generate the expected property for catalog entries that do not provide any APIs.

PR to fix that migration here #742. I expect either using a server binary built with this change OR the removal of the catalog-operator compatibility mode linked earlier will address your problem, unless there's an additional contributing factor.

[rgomez-casa]

Hello @benluddy,

Notice that this index.db I provided is just the simpler one I could find to illustrate the problem, other catalogs provide the APIs, have multiple channels and dependencies, replace and skip versions, etc.

They all present the same behavior, this is just free of all complications to illustrate the issue.
This example catalog completes the install plan and installs the CSV when using and old /bin/opm binary, but fails with the newer one and never creates the install plan or CSV.

About the old schema, we are still using Opm version: 1.12.3 to generate the index, because we found compatibility problems in the past with newer versions.

Regards,
Roberto.

[benluddy]

Hi Roberto, you may want to try building with a base image containing #744, which resolves an issue that is likely to cause symptoms similar to what you've reported in many catalogs on schema 8 or older.

[rgomez-casa]

Thanks @benluddy,

I see this is already merged into master so I guess it will be part of last nights' build. Isn't it?
I'll test it next wee and let you know how it goes.

Regards,
Roberto.

[rgomez-casa]

Hello @benluddy,

I have just confirmed that the most recent versions of the upstream-opm-builder are not producing this error.
From my side this seems to be fixed.

Thanks a lot.

Regards,
Roberto Gomez.

[benluddy]

Thanks for taking the time to file an issue and for following up!