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

pkg/lib/bundle/generate.go mis-parses channels list annotation "operators.operatorframework.io.bundle.channels.v1" if list contains space after comma #1052

Open
jfrancin opened this issue Jan 16, 2023 · 0 comments

Comments

@jfrancin
Copy link

The channel list annotation operators.operatorframework.io.bundle.channels.v1 is mis-parsed if the comma-separated list provided contains one or more spaces after a comma.

I encountered this issue with a Red Hat partner's operator bundle. In the Infinibox 2.3.0 certified operator annotations.yaml file, the last line in the excerpt below

annotations:
  com.redhat.openshift.versions: v4.8-v4.11
  operators.operatorframework.io.bundle.channel.default.v1: stable
  operators.operatorframework.io.bundle.channels.v1: alpha, stable       # note leading space before 'stable'

gets inserted into the catalog.json file as

{
    "schema": "olm.channel",
    "name": " stable",                                     #   <=== note leading space
    "package": "infinibox-operator-certified",
    "entries": [
        {
            "name": "infinibox-operator.v2.3.0",
            "skipRange": "<2.3.0"
        }
    ]
}
{
    "schema": "olm.channel",
    "name": "stable",                                     #   <=== note no leading space
    "package": "infinibox-operator-certified",
    "entries": [
        {
            "name": "infinibox-operator.v2.2.0",
            "skipRange": "<2.2.0"
        }
    ]
}

and since there are other operator bundles in the intended "stable" channel, the OpenShift OperatorHub shows two different "stable" channels on OpenShift v4.11.

I suspect that it's actually the underlying `gopkg.in/yaml.v2' that is mishandling the leading space in the annotations.yaml file, but would it make sense to check for spaces in the channel names - since a channel name cannot contain spaces?

There's nothing in the YAML space at https://yaml.org/spec/1.2.2/ that indicates that spaces in unquoted comma-separated strings should be included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant