-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
CSV specDescriptors for type pulled from wrong GVK #4409
Comments
I will add that it looks like this isn't limited to Looking in |
I've narrowed down that (incorrect meaning: for the operator-sdk/internal/generate/clusterserviceversion/bases/definitions/definitions.go Lines 65 to 80 in 8eb3fda
|
Digging a little more, the problem may not be within kindType, hasKind := g.types[gvk.Kind] |
/kind bug |
@estroz Regarding the milestone, just wondering if this bug fix would be back-ported to the prior release streams, or if we'd be looking at an upgrade to |
@aharbis likely backported if you want it to be (as per the backport policy). It is in v1.5.0 because I don't expect to have the time to fix this until that release. If you have time to work on this earlier (or anyone else reading this), feel free to assign yourself. |
Bug Report
What did you do?
We currently have a single group,
datapower.ibm.com
, two versions:v1beta1
andv1beta2
, and the CRDs are as follows:datapower.ibm.com/v1beta1
:DataPowerService
datapower.ibm.com/v1beta2
:DataPowerService
+DataPowerMonitor
In the
v1beta1
DataPowerService, we had an embeddedDataPowerMonitorSpec
type defined, as this existed as a property within our DataPowerService CRD. Inv1beta2
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:
What did you expect to see?
Base CSV (
config/manifests/bases/${project}.clusterserviceversion.yaml
) created / updated withspecDescriptors
andstatusDescriptors
from the appropriate GVK.Versioned CSV (
packagemanifests/${version}/${project}.clusterserviceversion.yaml
) created / updated withspecDescriptors
andstatusDescriptors
from the appropriate GVK.What did you see instead? Under which circumstances?
When I generate the CSV and package manifests, the
v1beta2
DataPowerMonitorspecDescriptors
are for some reason being pulled from the embedded spec in thev1beta1
DataPowerService kind.The
v1beta2
DataPowerServicespecDescriptors
also appear to be pulled from thev1beta1
version, because it still shows the embeddeddatapowerMonitor
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
$ go version
(if language is Go)$ kubectl version
Possible Solution
Additional context
I've been working on migrating our project from
v0.18.2
tov0.19.4
and recently made the jump tov1.0.1
to pick up the CSV marker support. I was not seeing this issue / behavior onv0.18.2
, so it appears to be isolated to the newoperator-sdk generate kustomize manifests
oroperator-sdk generate packagemanifests
implementations.The text was updated successfully, but these errors were encountered: