Closed raffaelespazzoli closed 2 years ago
Hi @raffaelespazzoli,
Could you please describe and point out what do you make here:
I tried to understand the workaround and apply it to my project but it didn't work.
Also, you say:
the issue above suggests that when two types with the same name and different packages appear in the same CRD the operator-sdk bundle enters an infinite loop...
I am looking at : https://github.com/raffaelespazzoli/patch-operator/blob/main/PROJECT and I can see only 1 API scaffold.
If you are looking to have multi-group support which means allow your project have more than one group for you have scenarios such as:
Then, you must allow its supports on the project. See:
Link: https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/
By clicking on the link informed you will be redirected to the doc: https://book.kubebuilder.io/migration/multi-group.html which has all steps.
Also, be aware of: https://sdk.operatorframework.io/docs/faqs/#can-i-customize-the-projects-initialized-with-operator-sdk and I'd recommend you always try to use the tool to do the scaffolds as not to deviate from the default layout and instead of that just add your customizations on top.
You can check the doc: https://sdk.operatorframework.io/docs/overview/project-layout/ to understand better the layout scaffold by default.
Hi @raffaelespazzoli,
I could reproduce your scenario. Following the steps:
1) Create a new project:
mkdir patch-operator-bkp
cd patch-operator-bkp
operator-sdk init
2) Create the API
operator-sdk create api --group redhatcop --kind Patch --version v1
3) Create the webhook
operator-sdk create webhook --group redhatcop --kind Patch --version v1 --programmatic-validation --defaulting
4) Run make bundle
(ALL works fine)
The problem only occurs when we add a new attr for the type(API) using the lib: "github.com/redhat-cop/operator-utils/api/v1alpha1"
and version v1.3.0
package v1
import (
utilsv1alpha1 "github.com/redhat-cop/operator-utils/api/v1alpha1"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)
// EDIT THIS FILE! THIS IS SCAFFOLDING FOR YOU TO OWN!
// NOTE: json tags are required. Any new fields you add must have json tags for the fields to be serialized.
// PatchSpec defines the desired state of Patch
type PatchSpec struct {
// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
// Important: Run "make" to regenerate code after modifying this file
// Patches is a list of patches that should be enforced at runtime.
// +kubebuilder:validation:Required
Patch *utilsv1alpha1.Patch `json:"patch,omitempty"`
// ServiceAccountRef is the service account to be used to run the controllers associated with this configuration
// +kubebuilder:validation:Required
// +kubebuilder:default={"name": "default"}
ServiceAccountRef corev1.LocalObjectReference `json:"serviceAccountRef,omitempty"`
}
What is the problem?
Shows that the issue here is because you are adding the lib "github.com/redhat-cop/operator-utils/api/v1alpha1"
and spec Patch *utilsv1alpha1.Patch json:"patch,omitempty"
which requires a multigroup support layout. See; https://book.kubebuilder.io/migration/multi-group.html
Following the steps to check that it would be solved by using the multi-group support which shows required in your case because the lib added
1) Create a new project:
mkdir patch-operator-bkp
cd patch-operator-bkp
operator-sdk init
Add Multigroup support with operator-sdk edit --multigroup
2) Create the API
operator-sdk create api --group redhatcop --kind Patch --version v1
3) Create the webhook
operator-sdk create webhook --group redhatcop --kind Patch --version v1 --programmatic-validation --defaulting
4) Run make bundle
(ALL works fine)
The problem only occurs when we add a new attr for the type(API) using the lib: "github.com/redhat-cop/operator-utils/api/v1alpha1"
and version v1.3.0
package v1
import (
utilsv1alpha1 "github.com/redhat-cop/operator-utils/api/v1alpha1"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)
// EDIT THIS FILE! THIS IS SCAFFOLDING FOR YOU TO OWN!
// NOTE: json tags are required. Any new fields you add must have json tags for the fields to be serialized.
// PatchSpec defines the desired state of Patch
type PatchSpec struct {
// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
// Important: Run "make" to regenerate code after modifying this file
// Patches is a list of patches that should be enforced at runtime.
// +kubebuilder:validation:Required
Patch *utilsv1alpha1.Patch `json:"patch,omitempty"`
// ServiceAccountRef is the service account to be used to run the controllers associated with this configuration
// +kubebuilder:validation:Required
// +kubebuilder:default={"name": "default"}
ServiceAccountRef corev1.LocalObjectReference `json:"serviceAccountRef,omitempty"`
}
5) Checking the result:
You can check the POC test at: https://github.com/camilamacedo86/patch-operator-bkp
So, can we close this one since all shows are sorted out?
Also, might be nice maybe we be able to raise a warning or error in this scenario when we try to run the command operator-sdk generate kustomize manifests -q
. Would you like to collab with that?
wonderful thanks. we can close this.
Bug Report
running the bundle build command I get a segmentation fault.
What did you do?
here is the commands I run:
on this project: https://github.com/raffaelespazzoli/patch-operator
What did you expect to see?
bundle gets created in the ./bundle directory
What did you see instead? Under which circumstances?
Environment
Operator type:
/language go
Kubernetes cluster type:
N/A
$ operator-sdk version
$ go version
(if language is Go)$ kubectl version
Possible Solution
this issue might be related: https://github.com/operator-framework/operator-sdk/issues/4990 I tried to understand the workaround and apply it to my project but it didn't work.
Additional context
the issue above suggests that when two types with the same name and different packages appear in the same CRD the operator-sdk bundle enters an infinite loop...