Skip to content
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

replaces meta data for operator will throw fatal error when no previous version of operator is found. #831

Closed
aneeshkp opened this issue Apr 29, 2019 · 3 comments

Comments

@aneeshkp
Copy link

If the replace operator is mentioned in CSV file without actually having an older version of the operator in the marketplace, the CatalogSourceConfig fails to run due to a fatal error

If it doesn't find the replacement, it should ignore and continue instead of throwing a fatal error.

Message: time="2019-04-29T17:35:06Z" level=fatal msg="error loading manifest from remote registry - kubevirtoperator.0.17.0-alpha.0 specifies replacement that couldn't be found" port=50051 type=appregistry

In the below example "replaces: kubevirtoperator.0.16.2" is causing the fatal error since there is no operator to replace.

spec:
displayName: KubeVirt
description: |
KubeVirt is a cluster add-on that provides a way to run virtualized workloads alongside containerized workload in a Kubernetes / OpenShift native way.
Minor and patch level updates are supported.
keywords:
- KubeVirt
- Virtualization
version: 0.17.0-alpha.0
maturity: alpha
replaces: kubevirtoperator.0.16.2

 kubectl get pods -n marketplace
NAME READY STATUS RESTARTS AGE
installed-upstream-community-operators-5cb468-2zfff 0/1 CrashLoopBackOff 8 17m
marketplace-operator-7bb459dd57-chq47 1/1 Running 0 3d2h
upstream-community-operators-7df5b67589-hfhcz 0/1 CrashLoopBackOff 8 19m

Code throwing error:
https://github.com/operator-framework/operator-lifecycle-manager/blob/master/vendor/github.com/operator-framework/operator-registry/pkg/sqlite/load.go#L176.

@ecordell
Copy link
Member

ecordell commented May 9, 2019

Would you mind moving this to operator-registry?

Originally we thought it was useful to know if you accidentally publish an operator that doesn't replace the right thing, but there are definitely valid use cases for publishing catalogs that don't contain a chain back to the first operator in a channel

@aneeshkp
Copy link
Author

aneeshkp commented May 10, 2019

@ecordell, As you suggested, I created an issue under operator-registry .
operator-framework/operator-registry#47

@ecordell
Copy link
Member

thank you! closing here so we can track at operator-registry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants