Skip to content

CSV specDescriptors for type pulled from wrong GVK #4409

@aharbis

Description

@aharbis

Bug Report

What did you do?

We currently have a single group, datapower.ibm.com, two versions: v1beta1 and v1beta2, and the CRDs are as follows:

  • datapower.ibm.com/v1beta1: DataPowerService
  • datapower.ibm.com/v1beta2: DataPowerService + DataPowerMonitor

In the v1beta1 DataPowerService, we had an embedded DataPowerMonitorSpec type defined, as this existed as a property within our DataPowerService CRD. In v1beta2 we lifted this spec out into its own CRD, but with a refactor of the properties to support a new business logic and implementation of that function.

Generating the manifests as follows:

$ make packagemanifests \
  VERSION=$version \
  CHANNEL=$channel \
  IS_DEFAULT_CHANNEL=1

What did you expect to see?

Base CSV (config/manifests/bases/${project}.clusterserviceversion.yaml) created / updated with specDescriptors and statusDescriptors from the appropriate GVK.

Versioned CSV (packagemanifests/${version}/${project}.clusterserviceversion.yaml) created / updated with specDescriptors and statusDescriptors from the appropriate GVK.

What did you see instead? Under which circumstances?

When I generate the CSV and package manifests, the v1beta2 DataPowerMonitor specDescriptors are for some reason being pulled from the embedded spec in the v1beta1 DataPowerService kind.

The v1beta2 DataPowerService specDescriptors also appear to be pulled from the v1beta1 version, because it still shows the embedded datapowerMonitor property.

As far as I can tell, the generator here is failing to differentiate between the GVKs, and the specDescriptors are getting jumbled together.

Environment

Operator type:

/language go

Kubernetes cluster type: OCP 4.6.x

$ operator-sdk version

operator-sdk version: "v1.0.1", commit: "4169b318b578156ed56530f373d328276d040a1b", kubernetes version: "v1.18.2", go version: "go1.13.15 linux/amd64", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

go version go1.13.12 linux/amd64

$ kubectl version

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0+7070803", GitCommit:"70708036fc265771f8d0a45598209018a8b9bd3e", GitTreeState:"clean", BuildDate:"2020-12-05T12:01:07Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Additional context

I've been working on migrating our project from v0.18.2 to v0.19.4 and recently made the jump to v1.0.1 to pick up the CSV marker support. I was not seeing this issue / behavior on v0.18.2, so it appears to be isolated to the new operator-sdk generate kustomize manifests or operator-sdk generate packagemanifests implementations.

$ cat PROJECT
projectName: datapower-operator-sdk-migration
domain: ibm.com
layout: go.kubebuilder.io/v2
multigroup: true
repo: github.ibm.com/datapower/datapower-operator-sdk-migration
resources:
- group: datapower
  kind: DataPowerService
  version: v1beta1
- group: datapower
  kind: DataPowerService
  version: v1beta2
- group: datapower
  kind: DataPowerMonitor
  version: v1beta2
version: 3-alpha
plugins:
  go.sdk.operatorframework.io/v2-alpha: {}

Metadata

Metadata

Assignees

Labels

kind/bugCategorizes issue or PR as related to a bug.language/goIssue is related to a Go operator project

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions