operators [R] cert-manager (1.4.0 1.4.1 1.4.2 1.4.3 1.4.4 1.5.3 1.5.4 1.6.0 1.6.1)

[wallrj]

Here I'm bringing the cert-manager packages in this repo in sync with redhat-openshift-ecosystem/community-operators-prod

• operators [R] cert-manager (1.4.0 1.4.1 1.4.2 1.4.3 1.4.4 1.5.3 1.5.4 1.6.0 1.6.1) redhat-openshift-ecosystem/community-operators-prod#434

/cc @yselkowitz
/hold

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

[openshift-ci]

@wallrj: GitHub didn't allow me to request PR reviews from the following users: yselkowitz.

Note that only k8s-operatorhub members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

Here I'm bringing the cert-manager packages in this repo in sync with redhat-openshift-ecosystem/community-operators-prod

• operators [R] cert-manager (1.4.0 1.4.1 1.4.2 1.4.3 1.4.4 1.5.3 1.5.4 1.6.0 1.6.1) redhat-openshift-ecosystem/community-operators-prod#434

/cc @yselkowitz
/hold

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[wallrj]

Blocked by #749

[camilamacedo86]

HI @wallrj,

The test is not passing because of the following errors:

    time="2022-02-09T12:23:41Z" level=error msg="Error: Value cert-manager-cainjector: invalid service account found in bundle. This service account cert-manager-cainjector in your bundle is not valid, because a service account with the same name was already specified in your CSV. If this was unintentional, please remove the service account manifest from your bundle. If it was intentional to specify a separate service account, please rename the SA in either the bundle manifest or the CSV."
    time="2022-02-09T12:23:41Z" level=error msg="Error: Value cert-manager-webhook: invalid service account found in bundle. This service account cert-manager-webhook in your bundle is not valid, because a service account with the same name was already specified in your CSV. If this was unintentional, please remove the service account manifest from your bundle. If it was intentional to specify a separate service account, please rename the SA in either the bundle manifest or the CSV."

You have invalid SA in the bundle and you can check it out by using SDK ( latest release ) to test your bundle with operator-sdk bundle validate <bundle-path> --select-optional suite=operatorframework

[wallrj]

/unhold

[wallrj]

The test is not passing because of the following errors:
Error: Value cert-manager-cainjector: invalid service account found in bundle. "
You have invalid SA in the bundle and you can check it out by using SDK ( latest release ) to test your bundle with operator-sdk bundle validate <bundle-path> --select-optional suite=operatorframework

I know this and I will fix it in the next release (1.6.2) but according to the documentation I should not (can not?) make modifications to existing bundles, other than to the metadata, right?

The CI pipeline should not be retesting my already released CSVs using new stricter validation rules,
because I have no way to fix the errors, according to the documentation.

Here are links and extracts from the documentation that I am referring to:

Updating your existing Operator

Unless of purely cosmetic nature, subsequent updates to your Operator should result in new bundle directories being added, containing an updated CSV as well as copied, updated and/or potentially newly added CRDs. Within your new CSV, update the spec.version field to the desired new semantic version of your Operator.

Operator deploy tests (lemon/orange) test failures

All operator versions are already in catalog
You are trying to edit an existing operator version. It is not recommended. But there are some exceptions, where you just edit some description or link. In this case, repository maintainers can set appropriate labels to override such errors and approve release pipeline action to overwrite an existing operator.

Minor (cosmetics) changes

There are some case when only some minor changes to the existing operator are needed (like description update or an update of icon). In this case pipeline will set corresponding label and automatically handle such case.

And I suppose the reason for not allowing e.g. ServiceAccount changes to existing bundles is that OLM would have no way to upgrade users who had already installed the existing bundle.
Here for example. The cert-manager 1.6.1 bundle will already be wide spread use. So if I change the ServiceAccount for 1.6.1 and if the CI allowed that, and if those updated packages got published to the OLM catalogue then we'd end up with users with slightly different OLM installations of cert-manager 1.6.1, which will cause confusion at best and may cause upgrade headaches at worst.

[wallrj]

@camilamacedo86 I'll give up on this. I don't think it's correct to change files outside the CSV in already released bundles for the reasons given in the documentation above and additionally in https://olm.operatorframework.io/docs/reference/file-based-catalogs/#immutable-bundles

OLM’s general advice is that bundle images and their metadata should be treated as immutable. If a broken bundle has been pushed to an index, you must assume that at least one of your users has upgraded to that bundle. Based on that assumption, you must release another bundle with an upgrade edge from the broken bundle to ensure users with the broken bundle installed receive an upgrade. OLM will not reinstall an installed bundle if the contents of that bundle are updated in the index.

In my view the CI in this repo should allow me to change CSV labels for already released bundles.