Operator-sdk: `operator-sdk bundle validate` fails with "cannot convert int64 to float64" when manifests contains specific version number

Created on 1 May 2020  ยท  5Comments  ยท  Source: operator-framework/operator-sdk

Bug Report

What did you do?
I'm trying to create a bundle image with a specific version like:

VERSION=0.2.0
operator-sdk generate csv --apis-dir ./pkg/apis/apps/v1alpha1 --verbose --operator-name nexus-operator --csv-version $VERSION
operator-sdk bundle create quay.io/m88i/nexus-operator.v${VERSION}:latest  -d ./deploy/olm-catalog/nexus-operator/${VERSION} --package nexus-operator --channels alpha  --overwrite
docker push quay.io/m88i/nexus-operator.v${VERSION}:latest
operator-sdk bundle validate quay.io/m88i/nexus-operator.v${VERSION}:latest

The bundle validate command fails with:

INFO[0000] Unpacked image layers                         bundle-dir=/tmp/bundle-879233443 container-tool=docker
INFO[0000] running docker pull                           bundle-dir=/tmp/bundle-879233443 container-tool=docker
INFO[0002] running docker save                           bundle-dir=/tmp/bundle-879233443 container-tool=docker
FATA[0003] Bundle content validation failed: Bundle validation errors: cannot convert int64 to float64  bundle-dir=/tmp/bundle-879233443 container-tool=docker

Here's what looks like the /tmp/bundle-879233443 directory:

tree /tmp/bundle-879233443
/tmp/bundle-879233443
โ”œโ”€โ”€ manifests
โ”‚   โ”œโ”€โ”€ apps.m88i.io_nexus_crd.yaml
โ”‚   โ”œโ”€โ”€ nexus-operator.clusterserviceversion.yaml
โ”‚   โ””โ”€โ”€ nexus-operator.v0.2.0.clusterserviceversion.yaml
โ””โ”€โ”€ metadata
    โ””โ”€โ”€ annotations.yaml

Seems ok to me, but looks like the command is having trouble when trying to convert the version number.

What did you expect to see?
My bundle corrected validated.

What did you see instead? Under which circumstances?
The error was described above.

Environment

  • operator-sdk version:
operator-sdk version
operator-sdk version: "v0.17.0", commit: "2fd7019f856cdb6f6618e2c3c80d15c3c79d1b6c", kubernetes version: "unknown", go version: "go1.13.10 linux/amd64"
  • go version:
go version
go version go1.14.2 linux/amd64
  • Kubernetes version information:
kubectl version
]Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2", GitCommit:"52c56ce7a8272c798dbc29846288d7cd9fbae032", GitTreeState:"clean", BuildDate:"2020-04-16T11:56:40Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-25T14:50:46Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
  • Kubernetes cluster kind:
    Minikube

  • Are you writing your operator in ansible, helm, or go?
    Go

Possible Solution

Additional context
Here's my full script:

VERSION=0.2.0
operator-sdk generate csv --apis-dir ./pkg/apis/apps/v1alpha1 --verbose --operator-name nexus-operator --csv-version $VERSION
operator-sdk bundle create quay.io/m88i/nexus-operator.v${VERSION}:latest  -d ./deploy/olm-catalog/nexus-operator/${VERSION} --package nexus-operator --channels alpha  --overwrite
docker push quay.io/m88i/nexus-operator.v${VERSION}:latest
operator-sdk bundle validate quay.io/m88i/nexus-operator.v${VERSION}:latest

On a side note, what's the recommended image name for bundles? In the docs you guys are using the operator's name, I've found this other doc that suggest a better approach IMHO, that's using a name like' <operator-name>.vN.N.N:latest. The operator name should be reserved for the operator image itself.

Thanks!

kinbug olm-integration

All 5 comments

Also fails if our directory has version names:

operator-sdk bundle validate deploy/olm-catalog/nexus-operator
FATA[0000] Bundle content validation failed: Bundle validation errors: cannot convert int64 to float64  bundle-dir=/home/zanini/dev/github.com/m88i/nexus-operator/deploy/olm-catalog/nexus-operator

Tree structure:

tree deploy/olm-catalog/nexus-operator
deploy/olm-catalog/nexus-operator
โ”œโ”€โ”€ 0.1.0
โ”‚   โ”œโ”€โ”€ apps.m88i.io_nexus_crd.yaml
โ”‚   โ””โ”€โ”€ nexus-operator.v0.1.0.clusterserviceversion.yaml
โ”œโ”€โ”€ 0.2.0
โ”‚   โ”œโ”€โ”€ apps.m88i.io_nexus_crd.yaml
โ”‚   โ””โ”€โ”€ nexus-operator.v0.2.0.clusterserviceversion.yaml
โ”œโ”€โ”€ manifests
โ”‚   โ”œโ”€โ”€ apps.m88i.io_nexus_crd.yaml
โ”‚   โ”œโ”€โ”€ nexus-operator.clusterserviceversion.yaml
โ”‚   โ””โ”€โ”€ nexus-operator.v0.2.0.clusterserviceversion.yaml
โ”œโ”€โ”€ metadata
โ”‚   โ””โ”€โ”€ annotations.yaml
โ”œโ”€โ”€ nexus-operator-operatorsource.yaml
โ””โ”€โ”€ nexus-operator.package.yaml

@ricardozanini this error is coming from a library we use to validate. From https://github.com/operator-framework/operator-registry/pull/334#issuecomment-632857559:

I did some digging on the conversion error that this PR intends to fix:

cannot convert int64 to float64

I found a similar issue (https://github.com/vmware-tanzu/octant/issues/143) that linked the fix needed in sigs.k8s.io/yaml, an upstream fork of github.com/ghodss/yaml and the library the default unstructured converter uses. That fix has been merged and exists in sigs.k8s.io/yaml v1.2.0. In the SDK we've made an effort to remove the direct github.com/ghodss/yaml dependency because it isn't maintained unlike the upstream fork. So perhaps this issue is caused by use of the unmaintained dep, and even if it isn't now it could arise again in the future. I suggest switching to the upstream dep and seeing if that fixes your issue before using a different decoder.

So this is a bug and will be fixed very soon.

/kind bug

@estroz We can bump to operator-registry v1.12.4 which should have this fix https://github.com/operator-framework/operator-sdk/pull/3106

Sigh, apparently #3106 didn't fix this. Still some upstream stuff that needs to be patched.
https://github.com/operator-framework/api/blob/197407cd70e8ddfef85d21216085ed52fbb4bb2d/pkg/manifests/bundleloader.go#L143

Closed by #3132

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nrvnrvn picture nrvnrvn  ยท  3Comments

joelanford picture joelanford  ยท  3Comments

kristiandrucker picture kristiandrucker  ยท  5Comments

smiklosovic picture smiklosovic  ยท  4Comments

camilamacedo86 picture camilamacedo86  ยท  4Comments