operator [N] [CI] oracle-database-operator (1.1.0)

[psilberk]

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

New Submissions

• Are you familiar with our contribution guidelines?
• Have you packaged and deployed your Operator for Operator Framework?
• Have you tested your Operator with all Custom Resource Definitions?
• Have you tested your Operator in all supported installation modes?
• Have you considered whether you want use semantic versioning order?
• Is your submission signed?
• Is operator icon set?

Updates to existing Operators

• Did you create a ci.yaml file according to the update instructions?
• Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
• Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.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
• 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 name¹
• One of the pre-defined capability levels²
• 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.

--

¹ If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need

² For more information see here

[github-actions]

Dear @psilberk,
Some errors and/or warnings were found while doing the check of your operator (oracle-database-operator/v1.1.0) against the entire suite of validators for Operator Framework with Operator-SDK version v1.36.0 and the command $ operator-sdk bundle validate <bundle-path> --select-optional suite=operatorframework.

Errors (:bug:) must be fixed while warnings (:warning:) are informative, and fixing them might improve the quality of your solution.

Type	Message
⚠️	Value database.oracle.com/v1alpha1, Kind=DbcsSystem: provided API should have an example annotation
⚠️	Value : (oracle-database-operator.v1.1.0) csv.Spec.minKubeVersion is not informed. It is recommended you provide this information. Otherwise, it would mean that your operator project can be distributed and installed in any cluster version available, which is not necessarily the case for all projects.
⚠️	Value oracle-database-operator.v1.1.0: owned CRD "dbcssystems.database.oracle.com" has an empty description

[mporrato]

@psilberk you are submitting two bundles with the same name and version in two different directories: please remove the v1.1.0 directory. Also, I think the name field in the metadata section of the csv should be oracle-database-operator.v1.1.0 instead of oracle-database-operator.1.1.0.

[github-actions]

Dear @psilberk,
Some errors and/or warnings were found while doing the check of your operator (oracle-database-operator/1.1.0) against the entire suite of validators for Operator Framework with Operator-SDK version v1.36.0 and the command $ operator-sdk bundle validate <bundle-path> --select-optional suite=operatorframework.

Errors (:bug:) must be fixed while warnings (:warning:) are informative, and fixing them might improve the quality of your solution.

Type	Message
⚠️	Value database.oracle.com/v1alpha1, Kind=DbcsSystem: provided API should have an example annotation
⚠️	Value : (oracle-database-operator.v1.1.0) csv.Spec.minKubeVersion is not informed. It is recommended you provide this information. Otherwise, it would mean that your operator project can be distributed and installed in any cluster version available, which is not necessarily the case for all projects.
⚠️	Value oracle-database-operator.v1.1.0: owned CRD "dbcssystems.database.oracle.com" has an empty description

[psilberk]

Hi @mporrato I tested this approach. I still fail in one check and it's not clear what the error is by looking at the logs.
Thanks for you help in advance.

@haripate @tomasbakk if you could also check this and let me know what the error seems to be I'll appreciate.

Thanks

[psilberk]

@mporrato @haripate @tomasbakk any hints on how can I move forward? Should I just drop the contribution?

[psilberk]

@mporrato @haripate @tomasbakk any update or hints? Thanks

[psilberk]

Probably the last attempt before dropping the contribution: @mporrato @haripate @tomasbakk any update or hints? Thanks

[mantomas]

@psilberk I have very low understanding how operators work internally. I guess you are able to deploy the operator in your local/testing k8s cluster? Is the deployment stable? The kiwi test is failing to find the running pod, so it might be already shut down for some reason and the test does not find it (it just calls oc get pods ... internally) - or there might be some identifier mismatch.

[psilberk]

@psilberk I have very low understanding how operators work internally. I guess you are able to deploy the operator in your local/testing k8s cluster? Is the deployment stable? The kiwi test is failing to find the running pod, so it might be already shut down for some reason and the test does not find it (it just calls oc get pods ... internally) - or there might be some identifier mismatch.

Hi @mantomas yes, the operator works ok locally. Does this 'oc get pods ...' looks in every namespace? Because by default all of our resources are linked to an specific namespace (oracle-database-operator)

[mantomas]

@psilberk I think the test uses its own namespace based on the command in the logs. Here is the source task where the error occurs and if needed it should be possible to run the kiwi test locally and see what is happening.
Sorry I'm not too familiar with this workflow, so my own approach would be try and error. I will sync with our SME next week when he is back from hollydais.

[mantomas]

@psilberk I tried to install the operator in my local cluster and it throws this error: error parsing step manifest: cdb1-secret: illegal base64 data at input byte 0 so I think there might be issue with this secret. It is not base64 encoded and if it is needed for installation, then it should be correct. Is the secret really needed to install the operator? If not, then you can maybe try some dummy b64 data or exclude the secret from operator instalation.

[github-actions]

Dear @psilberk,
Some errors and/or warnings were found while doing the check of your operator (oracle-database-operator/1.1.0) against the entire suite of validators for Operator Framework with Operator-SDK version v1.36.0 and the command $ operator-sdk bundle validate <bundle-path> --select-optional suite=operatorframework.

Errors (:bug:) must be fixed while warnings (:warning:) are informative, and fixing them might improve the quality of your solution.

Type	Message
⚠️	Value database.oracle.com/v1alpha1, Kind=DbcsSystem: provided API should have an example annotation
⚠️	Value : (oracle-database-operator.v1.1.0) csv.Spec.minKubeVersion is not informed. It is recommended you provide this information. Otherwise, it would mean that your operator project can be distributed and installed in any cluster version available, which is not necessarily the case for all projects.
⚠️	Value oracle-database-operator.v1.1.0: owned CRD "dbcssystems.database.oracle.com" has an empty description

[psilberk]

@psilberk I tried to install the operator in my local cluster and it throws this error: error parsing step manifest: cdb1-secret: illegal base64 data at input byte 0 so I think there might be issue with this secret. It is not base64 encoded and if it is needed for installation, then it should be correct. Is the secret really needed to install the operator? If not, then you can maybe try some dummy b64 data or exclude the secret from operator instalation.

Hi @mantomas , thanks so much for looking into this. I changed that yaml with some dummy base64 values, but it still failed in the kiwi check. Yes, the operator should work with any values in these files.

[mantomas]

@psilberk it looks like there is second bad b64 secret - sorry, I didn't noticed sooner.
I gave it another try and looks like cdb1-secret_v1_secret.yaml and pdb1-secret_v1_secret.yaml define CRDs which are not accessed (only reference is in the alm-examples). I removed both of the malformed secrets and was able to install the operator. If I'm correct then those secrets are user defined and are not needed in the bundle definition.

[framework-automation]

/merge possible

[framework-automation]

/merge possible

[psilberk]

@psilberk it looks like there is second bad b64 secret - sorry, I didn't noticed sooner. I gave it another try and looks like cdb1-secret_v1_secret.yaml and pdb1-secret_v1_secret.yaml define CRDs which are not accessed (only reference is in the alm-examples). I removed both of the malformed secrets and was able to install the operator. If I'm correct then those secrets are user defined and are not needed in the bundle definition.

Thank you so much @mantomas ! Now all checks are clear

[framework-automation]

/merge possible