Skip to content
This repository was archived by the owner on Jul 30, 2021. It is now read-only.

Update upstream Knative eventing operator to 0.12.0 #1192

Closed
aliok wants to merge 1 commit into from
Closed

Update upstream Knative eventing operator to 0.12.0 #1192

aliok wants to merge 1 commit into from

Conversation

@aliok
Copy link
Contributor

@aliok aliok commented Feb 4, 2020 •
edited
Loading

Signed-off-by: Ali Ok [email protected]

Thanks submitting your Operator. Please check below list before you create your Pull Request.

Flat operator directory structure is obsolete from 23-rd of October 2019, only nested directory structure will be accepted.

New Submissions

Updates to existing Operators

  • Is your new CSV pointing to the previous version with the replaces property?
  • Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
  • Have you tested an update to your Operator when deployed via OLM?
  • Is your submission signed?

Your submission should not

  • Modify more than one operator
  • Modify an Operator you don't own
  • Rename an operator - please remove and add with a different name instead
  • Submit operators to both upstream-community-operators and community-operators at once
  • Modify any files outside the above mentioned folders
  • Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

  1. Description about the managed Application and where to find more information
  2. Features and capabilities of your Operator and how to use it
  3. Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

  • Human readable name and 1-liner description about your Operator
  • Valid category name1
  • One of the pre-defined capability levels2
  • Links to the maintainer, source code and documentation
  • Example templates for all Custom Resource Definitions intended to be used
  • A quadratic logo

Remember that you can preview your CSV here.

--

1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need

2 For more information see here

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Feb 4, 2020
@aliok aliok force-pushed the knative-eventing-0.12.0 branch from 437cfb5 to 5d86eed Compare February 4, 2020 16:46
@aliok
Copy link
Contributor Author

aliok commented Feb 4, 2020 

error: unable to recognize "/tmp/tmp.MEJaph/deploy/knative-eventing-operator.operatorgroup.yaml": no matches for kind "OperatorGroup" in version "operators.coreos.com/v1alpha2"
make: *** [Makefile:82: operator.test] Error 1
Operator deployment                               [  FAILED  ]

@J0zi any idea what this could be? the travis build fails.

@openshift-ci-robot openshift-ci-robot added the kubernetes-operator An Operator targeting OperatorHub.io label Feb 4, 2020
@aliok aliok force-pushed the knative-eventing-0.12.0 branch from 5d86eed to 8e90f90 Compare February 5, 2020 08:20
@aliok
Copy link
Contributor Author

aliok commented Feb 5, 2020

Tried again. Still fails

@J0zi J0zi self-assigned this Feb 6, 2020
@J0zi
Copy link
Collaborator

J0zi commented Feb 6, 2020

@aliok, give me some time please, investigating

@J0zi
Copy link
Collaborator

J0zi commented Feb 7, 2020 •
edited
Loading

@aliok, please check following error:
installplan status for "null": Error from server (NotFound): installplans.operators.coreos.com "null" not found. Old error was due to Kubernetes and OLM incompatibility, fixed on our end.

Digging deeper:
error loading manifests from configmap: couldn't find owned CRD in crd list operator.knative.dev/v1alpha1/Eventing (eventings): %!s()" port=50051

@aliok
Copy link
Contributor Author

aliok commented Feb 7, 2020

@J0zi

Not sure what this error means:

installplan status for "null": Error from server (NotFound): installplans.operators.coreos.com "null" not found

Isn't installplan is something the CI process creates for the CSV?

There's an error before the final fail (https://travis-ci.com/operator-framework/community-operators/builds/147505989#L368)

subscription.operators.coreos.com/knative-eventing-operator-sub created
    Applying object to cluster                    [  OK  ]
    Checking subscriptions if passes              [  Processing  ]
Checking subscription "knative-eventing-operator-sub" reaches "AtLatestKnown" state
retrying check of subscription status for "knative-eventing-operator-sub"...
subscription status for "knative-eventing-operator-sub": null
subscription status for "knative-eventing-operator-sub": null
....
FAIL: Failed to reach AtLatestKnown subscription status for "knative-eventing-operator-sub"

This is the probably the reason, the subscription can't be created properly, thus no install plan can be found for it.

I'd appreciate if you let me know in case you've seen this before :) Else, I will debug the CI process and try to reproduce the problem locally.

@J0zi
Copy link
Collaborator

J0zi commented Feb 10, 2020

@aliok, I thing the root cause could be somewhere here:
error loading manifests from configmap: couldn't find owned CRD in crd list operator.knative.dev/v1alpha1/Eventing (eventings): %!s()" port=50051

@aliok aliok force-pushed the knative-eventing-0.12.0 branch from 8e90f90 to 3f4f639 Compare February 10, 2020 14:00
@aliok aliok force-pushed the knative-eventing-0.12.0 branch from 3f4f639 to f71f4aa Compare February 10, 2020 14:13
@J0zi
Copy link
Collaborator

J0zi commented Feb 11, 2020

@aliok, I have 3 ideas:) Some of them are just shoot from the hip, some intuitive. We will see.

  1. something tells me that CRD file name could couse an issue, try to play with it.
  2. Try to add selector at the end of CSV and put respected label to CRD. It could help.
  3. Or commenting out alm-exapmles worth to try, to identify where is an issue.

@aliok
Copy link
Contributor Author

aliok commented Feb 11, 2020

I fixed the CRD related error.
Now I receive an error from the scorecard test:

The operator should write into objects to update state. No PUT or POST requests from the operator were recorded by the scorecard.

I reproduced the error locally. Need to adapt the operator to use KUBECONFIG env var.

@aliok aliok mentioned this pull request Feb 11, 2020
Closed
@aliok
Copy link
Contributor Author

aliok commented Feb 11, 2020

The operator will have support for reading KUBECONFIG env var with the PR: knative/eventing-operator#100

However, I will close this ticket now as the upstream community won't have a new release for this operator just because of OperatorHub.io support.

I will add the CSV for next version.

@aliok aliok closed this Feb 11, 2020
This was referenced Feb 11, 2020
Closed
Merged
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@dmesser dmesser Awaiting requested review from dmesser

Assignees

@J0zi J0zi

Labels

kubernetes-operator An Operator targeting OperatorHub.io size/L Denotes a PR that changes 100-499 lines, ignoring generated files.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@aliok @J0zi @openshift-ci-robot