Skip to content

Is it possible to generate a single CRD yaml with multiple versions using operator-sdk? #1724

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

Closed
dannyzaken opened this issue Jul 22, 2019 · 1 comment

Comments

@dannyzaken
Copy link

Type of question

general context and help around the operator-sdk

Question

I want to create a new API version for an existing CRD. I would like to know if it's possible to do it using operator-sdk commands. If not, than what is the best way to do that?

What did you do?

  • Created a new operator:

    operator-sdk new test-operator
    
  • Added an api and controller:

    operator-sdk add api --api-version=test.io/v1alpha1 --kind=Test
    operator-sdk add controller --api-version=test.io/v1alpha1 --kind=Test
    
  • implemented the contorller and deployed the CRD to the cluster

  • Now I want to add a new version v1alpha2. I want to keep old instances of v1alpha1 and also be able to deploy Test resources of the new v1alpha2 versions.
    if I try to run operator-sdk add api --api-version=test.io/v1alpha2 --kind=Test I get a new CRD file test_v1alpha2_test_crd.yaml, which shares the same resource name as test_v1alpha1_test_crd.yaml, but it exposes only v1alpha2

What did you expect to see?
I expected to get a crd that supports both versions, e.g.

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: tests.test.io
spec:
  group: test.io
  names:
    kind: Test
    listKind: TestList
    plural: tests
    singular: test
  scope: Namespaced
  subresources:
    status: {}
  validation:
    openAPIV3Schema:
      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/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/api-conventions.md#types-kinds'
          type: string
        metadata:
          type: object
        spec:
          type: object
        status:
          type: object
  version: v1alpha2
  versions:
  - name: v1alpha2
    served: true
    storage: true
  - name: v1alpha1
    served: false
    storage: false

Environment

  • operator-sdk version:
❱ operator-sdk version
operator-sdk version: v0.9.0, commit: 560208dc998de497bbf59fea1b63426aec430934
  • Kubernetes version information:
    not relevant

  • Kubernetes cluster kind:
    not relevant

Additional context
Add any other context about the question here.

@dannyzaken dannyzaken changed the title Is it possible to generate a single CRD yaml with multiple versions using operator-sdk Is it possible to generate a single CRD yaml with multiple versions using operator-sdk? Jul 22, 2019
@hasbro17
Copy link
Contributor

@dannyzaken We're still waiting on upgrading to controller-runtime v0.2.0 to get support for CRD conversion webhooks in the SDK #1455
With that update the SDK should support generating CRDs with the versions field and scaffolding conversion webhooks to help with upgrading the CRD apiversion.

For now however we do have some WIP documentation that walks through adding a new API version and all the necessary code and CRD manifest changes needed to support the new version #1680

In summary for now you will have to write a new CRD manifest and add the versions field and make v1alpha2 your storage version as you've shown above.

However you'll still need a conversion webhook
to handle conversions between v1alpha1 and v1alpha2 in your cluster.

I'm going to close this issue since we're already tracking the feature requests for CRD upgrade documentation and conversion webhooks support in #1541 and #1240
However feel free to ask questions here or preferably on the parent issue #1541

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants