Skip to content
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

Stick with a specific version of Kubebuilder and Kustomize #489

Open
spolti opened this issue Feb 9, 2024 · 4 comments
Open

Stick with a specific version of Kubebuilder and Kustomize #489

spolti opened this issue Feb 9, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@spolti
Copy link
Contributor

spolti commented Feb 9, 2024

Describe the bug

There is no clear information about what is the current version of kubebuilder and kustomize versions.
When the commands make install or make deploy is executed, a lot of changes related to formatting changes will be made, e.g.:

git diff config/crd/bases/serving.kserve.io_predictors.yaml                                                                                                                               ─╯
diff --git a/config/crd/bases/serving.kserve.io_predictors.yaml b/config/crd/bases/serving.kserve.io_predictors.yaml
index c8086f3..5bbc00a 100644
--- a/config/crd/bases/serving.kserve.io_predictors.yaml
+++ b/config/crd/bases/serving.kserve.io_predictors.yaml
@@ -3,8 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
 kind: CustomResourceDefinition
 metadata:
   annotations:
-    controller-gen.kubebuilder.io/version: v0.7.0
-  creationTimestamp: null
+    controller-gen.kubebuilder.io/version: v0.11.4
   name: predictors.serving.kserve.io
 spec:
   group: serving.kserve.io
@@ -119,13 +118,13 @@ spec:
                       properties:
                         claimName:
                           description:
-                            "ClaimName is the name of a PersistentVolumeClaim
+                            "claimName is the name of a PersistentVolumeClaim
                             in the same namespace as the pod using this volume. More
                             info: https://kubernetes.io/docs/concepts/storage/persistent-volumes#persistentvolumeclaims"
                           type: string
                         readOnly:
                           description:
-                            Will force the ReadOnly setting in VolumeMounts.
+                            readOnly Will force the ReadOnly setting in VolumeMounts.
                             Default false.
                           type: boolean
                       required:
@@ -259,9 +258,3 @@ spec:
       storage: true
       subresources:
         status: {}
-status:
-  acceptedNames:
-    kind: ""
-    plural: ""
-  conditions: []
-  storedVersions: []

To Reproduce
If the kubebuilder version diverges too much, just do:

  • make install

Expected behavior

When the make goals are called, no formatting changes must be done.

@spolti spolti added the bug Something isn't working label Feb 9, 2024
@spolti spolti self-assigned this Feb 9, 2024
@spolti
Copy link
Contributor Author

spolti commented Feb 12, 2024

@Jooho @israel-hdez f.y.i

@ckadner
Copy link
Member

ckadner commented Feb 12, 2024

The results may vary based on the versions of the CLI's you have installed locally. To use the "standardized" versions of the CLI tools, we have the developer image. So, instead of make generate use make run generate which will run the Make target inside the developer image container.

But, for the specific targets deploy and install -- those have not been maintained since the original OS drop. Use the install script instead.

@spolti
Copy link
Contributor Author

spolti commented Feb 12, 2024

Thanks @ckadner, noted.
Are there any plans to maintain the make deploy / install goals?
Or maybe, used the operator-sdk in the future?

@israel-hdez
Copy link
Collaborator

But, for the specific targets deploy and install -- those have not been maintained since the original OS drop. Use the install script instead.

If the script is the standard method, for development I think it is worth to invoke the install script with some predefined/opinionated parameters suitable for a developer. Then, if customizations are needed, people would need to fallback to using the script.

Either that ^, or simply remove those make targets to prevent confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants