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

entity for package "project-quay" not found in solution when trying to upgrade to the next version using replaces #321

Closed
m1kola opened this issue Aug 4, 2023 · 6 comments · Fixed by #326
Labels
kind/bug Categorizes issue or PR as related to a bug.
Milestone

Comments

@m1kola
Copy link
Member

m1kola commented Aug 4, 2023

I'm getting entity for package "project-quay" not found in solution when trying to upgrade to the next version.

project-quay uses replaces to speficy upgrade edges and support for this was added #275. I see that PR has an e2e test confirming an upgrade so it might be that I'm missing something.

Steps to reproduce

  1. Run the operators from master:
make run
  1. Create a catalog:
kubectl apply -f config/samples/catalogd_operatorcatalog.yaml
  1. Create an operator
kubectl apply -f - <<EOF
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  labels:
    app.kubernetes.io/name: operator
    app.kubernetes.io/instance: operator-sample
    app.kubernetes.io/part-of: operator-controller
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: operator-controller
  name: operator-sample
spec:
  packageName: project-quay
  channel: stable-3.8
  version: 3.8.1
EOF
  1. Wait for the operator to be installed:
kubectl wait operators operator-sample --for condition=Installed
  1. Edit operator to have a next valid version (in this specific example - 3.8.2 replaces 3.8.1):
kubectl patch operator operator-sample --type json -p '[{"op": "replace", "path": "/spec/version", "value": "3.8.2"}]'
  1. Observe conditions:
kubectl get operator operator-sample -o json | jq ".status"

Output:

{
  "conditions": [
    {
      "lastTransitionTime": "2023-08-04T14:24:02Z",
      "message": "installation has not been attempted as resolution failed",
      "observedGeneration": 13,
      "reason": "InstallationStatusUnknown",
      "status": "Unknown",
      "type": "Installed"
    },
    {
      "lastTransitionTime": "2023-08-04T14:24:02Z",
      "message": "entity for package \"project-quay\" not found in solution",
      "observedGeneration": 13,
      "reason": "ResolutionFailed",
      "status": "False",
      "type": "Resolved"
    }
  ]
}

Expected results

Operator is correctly resolved and installed

@m1kola m1kola added the kind/bug Categorizes issue or PR as related to a bug. label Aug 4, 2023
@m1kola
Copy link
Member Author

m1kola commented Aug 4, 2023

I see that PR has an e2e test confirming an upgrade

Just noticed that the E2E doesn't not specify a channel. I tested the steps described above, but removed the channel from Operator's sepc and got the same result.

@joelanford
Copy link
Member

I'm not seeing this problem in v0.3.0, I don't think.

@m1kola
Copy link
Member Author

m1kola commented Aug 4, 2023

@joelanford v0.3.0 was cut before #275. So I think we missed something in #275, but I can't figure out what is the difference between my example and the E2E test which works.

I'll come back to it on Monday.

@m1kola
Copy link
Member Author

m1kola commented Aug 7, 2023

From @jmprusi:

I've seen issues with the version being written as "v0.0.1" vs "0.0.1" (that missing v)

We might need to add toleration for versions with v since there are already plenty of operators with v prefix in versions.

Another option is to not allow v prefix, but in this case we want need to decide what to do with existing operators.

@joelanford
Copy link
Member

I didn't see any project-quay bundles in the operatorhub catalog that use a v prefix in their olm.package property, so perhaps something else is going on?

@m1kola
Copy link
Member Author

m1kola commented Aug 8, 2023

This turned out to be unrelated to v prefix. Our test catalog currently looks like this:

schema: olm.channel
name: beta
package: prometheus
entries:
- name: prometheus-operator.0.37.0
- name: prometheus-operator.0.47.0
replaces: "prometheus.v0.37.0"
- name: prometheus-operator.0.65.1
replaces: prometheus.v0.47.0

It looks like replaces in the test are in format $packageName.$version when in reality they are $bundleName.$version.

Most likely this means that controller also builds the problem incorrectly (using package name).

@m1kola m1kola mentioned this issue Aug 8, 2023
4 tasks
@m1kola m1kola added this to the v0.4.0 milestone Aug 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants