-
Notifications
You must be signed in to change notification settings - Fork 194
Makes apis/run/v1alpha3 pkg a Go module #2222
base: main
Are you sure you want to change the base?
Conversation
This patch defines a new Go module for package apis/run/v1alpha3 so other projects may depend on this package without pulling in this project's entire dependency graph. The reason the module is not defined for apis/run is because versions v1alpha1 and v1alpha2 depend back on this project, pulling in its dependency graph anyway.
This change may not in fact be possible due to kubernetes-sigs/controller-tools#516. The tl;dr is that you cannot currently split multiple API versions into distinct Go modules, or one of them will not be processed in the CRD generation. For example, this is why this PR's tests are failing -- because the diff --git a/config/crd/bases/run.tanzu.vmware.com_tanzukubernetesreleases.yaml b/config/crd/bases/run.tanzu.vmware.com_tanzukubernetesreleases.yaml
index cb9ef038..104b5e61 100644
--- a/config/crd/bases/run.tanzu.vmware.com_tanzukubernetesreleases.yaml
+++ b/config/crd/bases/run.tanzu.vmware.com_tanzukubernetesreleases.yaml
@@ -357,196 +357,6 @@ spec:
storage: false
subresources:
status: {}
- - additionalPrinterColumns:
- - jsonPath: .spec.version
- name: Version
- type: string
- - jsonPath: .status.conditions[?(@.type=='Compatible')].status
- name: Compatible
- type: string
- - jsonPath: .metadata.creationTimestamp
- name: Created
- type: date
- name: v1alpha3
- schema:
- openAPIV3Schema:
- description: TanzuKubernetesRelease is the schema for the tanzukubernetesreleases
- API. TanzuKubernetesRelease objects represent Kubernetes releases available
- via TKG, which can be used to create TanzuKubernetesCluster instances. TKRs
- are immutable to end-users. They are created and managed by TKG to provide
- discovery of Kubernetes releases to TKG users.
- properties:
- apiVersion:
- description: 'APIVersion defines the versioned schema of this representation
- of an object. Servers should convert recognized schemas to the latest
- internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
- type: string
- kind:
- description: 'Kind is a string value representing the REST resource this
- object represents. Servers may infer this from the endpoint the client
- submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
- type: string
- metadata:
- type: object
- spec:
- description: TanzuKubernetesReleaseSpec defines the desired state of TanzuKubernetesRelease
- properties:
- bootstrapPackages:
- description: BootstrapPackages lists references to all bootstrap packages
- shipped with this TKR.
- items:
- description: LocalObjectReference contains enough information to
- let you locate the referenced object inside the same namespace.
- properties:
- name:
- description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
- TODO: Add other useful fields. apiVersion, kind, uid?'
- type: string
- type: object
- type: array
- kubernetes:
- description: Kubernetes is Kubernetes
- properties:
- coredns:
- description: CoreDNS specifies the container image repository
- and tag for coredns.
- properties:
- imageRepository:
- description: ImageRepository sets the container registry to
- pull images from. if not set, defaults to the ImageRepository
- defined in KubernetesSpec.
- type: string
- imageTag:
- description: ImageTag specifies a tag for the image.
- type: string
- type: object
- etcd:
- description: Etcd specifies the container image repository and
- tag for etcd.
- properties:
- imageRepository:
- description: ImageRepository sets the container registry to
- pull images from. if not set, defaults to the ImageRepository
- defined in KubernetesSpec.
- type: string
- imageTag:
- description: ImageTag specifies a tag for the image.
- type: string
- type: object
- imageRepository:
- description: ImageRepository specifies container image registry
- to pull images from.
- type: string
- kube-vip:
- description: KubeVIP specifies the container image repository
- and tag for kube-vip.
- properties:
- imageRepository:
- description: ImageRepository sets the container registry to
- pull images from. if not set, defaults to the ImageRepository
- defined in KubernetesSpec.
- type: string
- imageTag:
- description: ImageTag specifies a tag for the image.
- type: string
- type: object
- pause:
- description: Pause specifies the container image repository and
- tag for pause.
- properties:
- imageRepository:
- description: ImageRepository sets the container registry to
- pull images from. if not set, defaults to the ImageRepository
- defined in KubernetesSpec.
- type: string
- imageTag:
- description: ImageTag specifies a tag for the image.
- type: string
- type: object
- version:
- description: Version is Semantic Versioning conformant version
- of the Kubernetes build shipped by this TKR. The same Kubernetes
- build MAY be shipped by multiple TKRs.
- type: string
- required:
- - version
- type: object
- osImages:
- description: OSImages lists references to all OSImage objects shipped
- with this TKR.
- items:
- description: LocalObjectReference contains enough information to
- let you locate the referenced object inside the same namespace.
- properties:
- name:
- description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
- TODO: Add other useful fields. apiVersion, kind, uid?'
- type: string
- type: object
- type: array
- version:
- description: Version is the fully qualified Semantic Versioning conformant
- version of the TanzuKubernetesRelease. Version MUST be unique across
- all TanzuKubernetesRelease objects.
- type: string
- required:
- - kubernetes
- - version
- type: object
- status:
- description: TanzuKubernetesReleaseStatus defines the observed state of
- TanzuKubernetesRelease
- properties:
- conditions:
- items:
- description: Condition defines an observation of a Cluster API resource
- operational state.
- properties:
- lastTransitionTime:
- description: Last time the condition transitioned from one status
- to another. This should be when the underlying condition changed.
- If that is not known, then using the time when the API field
- changed is acceptable.
- format: date-time
- type: string
- message:
- description: A human readable message indicating details about
- the transition. This field may be empty.
- type: string
- reason:
- description: The reason for the condition's last transition
- in CamelCase. The specific API may choose whether or not this
- field is considered a guaranteed API. This field may not be
- empty.
- type: string
- severity:
- description: Severity provides an explicit classification of
- Reason code, so the users or machines can immediately understand
- the current situation and act accordingly. The Severity field
- MUST be set only when Status=False.
- type: string
- status:
- description: Status of the condition, one of True, False, Unknown.
- type: string
- type:
- description: Type of condition in CamelCase or in foo.example.com/CamelCase.
- Many .condition.type values are consistent across resources
- like Available, but because arbitrary conditions can be useful
- (see .node.status.conditions), the ability to deconflict is
- important.
- type: string
- required:
- - lastTransitionTime
- - status
- - type
- type: object
- type: array
- type: object
- type: object
- served: true
- storage: false
- subresources:
- status: {}
status:
acceptedNames:
kind: "" I'm playing around with a few ideas, but nothing is working so far. Ideally we'd just mark |
So there is a work-around, but it reformats the CRDs in such a way that they look changed, but only due to formatting. There's a command for
Using this we can:
Again, the result of the second step produces CRDs that are formatted differently (indentation, order, etc.), but have the same contents. Update
Basically these two commands emit the calculated objects to YAML with entirely different logic, resulting in entirely inconsistent output. I think it's possible for either to use the marshal logic of the other, but it's unclear to me if that's desired. For example, the disparate behavior could be by design. |
I filed a patch for controller-tools that introduces cross-module support when generating CRDs, webhooks, RBAC rules, etc. -- kubernetes-sigs/controller-tools#663. I verified this patch by building |
@akutz I believe this has been addressed by @vijaykatam in #3169. |
What this PR does / why we need it
This patch defines a new Go module for package apis/run/v1alpha3 so other projects may depend on this package without pulling in this project's entire dependency graph.
The reason the module is not defined for apis/run is because versions v1alpha1 and v1alpha2 depend back on this project, pulling in its dependency graph anyway.
Which issue(s) this PR fixes
Fixes
NA
Describe testing done for PR
Release note
PR Checklist
Additional information
Related to #2216
cc @vijaykatam @sidharthsurana @jmoroski
Special notes for your reviewer