operators kong (0.9.0)

[rainest]

Version 0.9.0 of the Kong Operator intentionally does not indicate any replaces version. As we've migrated to a new CRD API group to comply with Kubernetes requirements, upgrading from prior versions requires manual work. The 0.9.0 CSV description calls this out and links to the manual upgrade steps.

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

[rainest]

Any idea what's causing the error interpreting channels, please manually input channels instead error on the operator info test for the existing 0.1.0 version?

operator-framework/operator-registry#386 indicates a cause, but I'm not sure I'm interpreting the issue correctly. We have:

$ cat kong.package.yaml                                                 
channels:
- currentCSV: kong.v0.9.0
  name: alpha
packageName: kong

$ cat 0.1.0/kong.v0.1.0.clusterserviceversion.yaml| grep name: | head -1
  name: kong.v0.1.0

$ cat 0.9.0/kong.v0.9.0.clusterserviceversion.yaml | grep name: | head -1 
  name: kong.v0.9.0

Looking at the apparent fix doesn't suggest what's broken in our bundle--in that case, there actually was a difference between one of the current channel CSV names in the package and CSV definition. In our case, we've only ever used kong in the CSV name and that is the currentCSV of the only channel (although it's a different version, not 0.1.0)

https://github.com/operator-framework/operator-registry/blob/c426f78b97458fe5f25208e4ecee398bbc7ae065/pkg/lib/bundle/interpreter.go#L35-L46 doesn't immediately suggest any other causes that will break the check, as it is performing a basic string comparison and nothing else, though I didn't look into the source of those string arrays too closely, so I may be missing something there.

[framework-automation]

/merge possible

[github-actions]

Current PR can be merged automatically, but there is missing authorized-changes label. One can find out more info here.

[mflendrich]

@J0zi @mvalarh this is ready for review now.

[rainest]

Alright, the original issue happens as a side effect of adding a version without replaces info. If the current CSVs of channels' replace graphs doesn't find some version via registry.getChannelNodes(), it won't have any associated channel and the "error interpreting channels, please manually input channels instead" error will occur.

That could be indicated more clearly, though I don't know where in the code would be the best place to try and catch it.

operator-framework/community-operators#1992 indicates that you were previously able to rename the existing channel to keep the current channel name (we still wanted it to indicate that it was alpha status), but that now causes a failure in orange / Deploy k8s latest.

  cmd: '/tmp/operator-test/bin/opm index add -c podman --bundles quay.io/operatorhubio/kong:v0.1.0,quay.io/operatorhubio/kong:v0.2.6,quay.io/operatorhubio/kong:v0.3.0,quay.io/operatorhubio/kong:v0.4.0,quay.io/operatorhubio/kong:v0.5.0,quay.io/operatorhubio/kong:v0.6.0,quay.io/operatorhubio/kong:v0.7.0,quay.io/operatorhubio/kong:v0.8.0,kind-registry:5000/test-operator/kong:v0.9.0 --tag kind-registry:5000/test-operator/catalog:latest --mode replaces '
...
    Error: [add prunes bundle kong.v0.1.0 (quay.io/operatorhubio/kong:v0.1.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.2.6 (quay.io/operatorhubio/kong:v0.2.6) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.3.0 (quay.io/operatorhubio/kong:v0.3.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.4.0 (quay.io/operatorhubio/kong:v0.4.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.5.0 (quay.io/operatorhubio/kong:v0.5.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.6.0 (quay.io/operatorhubio/kong:v0.6.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.7.0 (quay.io/operatorhubio/kong:v0.7.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces []), add prunes bundle kong.v0.8.0 (quay.io/operatorhubio/kong:v0.8.0) from package kong, channel alpha: this may be due to incorrect channel head (kong.v0.9.0, skips/replaces [])]

[framework-automation]

/merge possible

[gallettilance]

@rainest I'm noticing that 0.9.0 is not attached to the graph (via replaces, skips, or skipRange). This means that anyone installed on <= 0.8.0 will not be able to get to 0.9.0 without manually uninstalling the operator and re-installing on the alpha.1 channel. Is this something you intended to do?
cc @camilamacedo86

[mflendrich]

@gallettilance This was intentional. The reason was that Kubernetes 1.22 forced us to change the apigroup of the Kong CRD from *.k8s.io to something different.

Therefore, the upgrade path for our users is to replace any kongs.charts.helm.k8s.io CRDs with equivalent kongs.charts.konghq.com. An automatic upgrade from <0.9.0 to 0.9.0 would make our users accidentally tear down all of their Kong runtimes managed by the operator.

Does this make sense? It seems that several other operators were affected by this upstream change (k8s 1.22 enforcing CRDs in the k8s.io apigroup to be annotated as "approved" upstream) as well. Please advise if there's a better way to handle this situation.

[gallettilance]

@mflendrich I'll take an action item to describe this in the OLM docs but basically we want to avoid you opting out of OLM (which is sort of what is happening when you have a detached graph) in order to achieve an API migration.

You can use two versions to achieve this migration:

1. The first release (let's say this is 0.9.0 and replaces 0.8.0) will own both kongs.charts.helm.k8s.io and kongs.charts.konghq.com and contain logic for performing the migration from one to the other (I'm assuming there is domain specific logic that would make this possible on the operator side).
2. The second release (let's say this is 0.10.0 and replaces 0.9.0 only owns kongs.charts.konghq.com and is not responsible for any migration.

All existing installs will go through this "special migration only" kong version (0.9.0 above) and 0.10.0 becomes your supported 1.22+ version.

I understand that the version 0.9.0 may be implying a certain version of Kong so you could use 0.9.0-1 (a pre-release) for the migration version and then 0.9.0 for the second release (instead of the above 0.9.0 and 0.10.0).

Please let me know if you have questions.

[gallettilance]

@mflendrich do you have a link to where Kubernetes 1.22 says you can't use *.k8s.io?

[rainest]

@gallettilance kubernetes/enhancements#1111.

There some mention of the change buried in the SDK change docs that does indicate this as well, and while I can no longer find that, IIRC guidance there was a bare-bones "you need to do this, figure out how".