-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
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:DataPowerServicedatapower.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=1What 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: {}