modelmesh-serving
modelmesh-serving copied to clipboard
Stick with a specific version of Kubebuilder and Kustomize
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.
@Jooho @israel-hdez f.y.i
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.
Thanks @ckadner, noted. Are there any plans to maintain the make deploy / install goals? Or maybe, used the operator-sdk in the future?
But, for the specific targets
deployandinstall-- 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.