Kubebuilder: Question on external CRDs document and best practices for testing

[steveQuadros]

I was checking out this doc on external types following from https://github.com/kubernetes-sigs/kubebuilder/issues/369 which lead me to https://github.com/kubernetes-sigs/kubebuilder/pull/752
There is also an issue that mentions this exists in the kubebuilder book/Cronjob tutorial, but I couldn't find it.

Are there established best practices for including external CRD definitions?

The doc mentions having them in vendor, but config isn't a go pkg, and isn't included by default. I wanted to check if there was something obvious I was missing.

I'd be happy to update the docs to clarify if there is already a solution.

/triage support

[camilamacedo86]

HI @steveQuadros,

By running the command create api is generate the Custom Resource (CR) in the config/samples and Custom Resource Definition (CRD) in config/crds/bases for the Kind provided. This command is creating the API for the project. In this way, we can create our APIs and objects that will represent our solutions on these platforms and it can have as many Kinds as needed (1…N). Basically, the CRDs are a definition of our customized Objects, and the CRs are an instance of it.

However, we can also use third-APIs in the projects. For that, we need to register the API with the scheme to the manager as described in the doc Using an External Type and such as in the main.go:

      import (
            myextrenalschema "pathimport"
      ) 

       if err := myextrenalschema.AddToScheme(mgr.GetScheme()); err != nil {
        log.Error(err, "")
        os.Exit(1)
    }

In this way, if we add the schema we are able to use them in the controllers which mean to create, to delete, to get, to update an etc resources of these types. But if you would like to reconcile CR's of this external kind and have a controller for it then, you can also create api for the external kind with its controller in the way that shows described in the doc. Might give a look in the here can help you with.

Regards:

The doc mentions having them in vendor, but config isn't a go pkg, and isn't included by default. I wanted to check if there was something obvious I was missing.

I understand that you are speaking about:

// Get a config to talk to the apiserver
    t := &envtest.Environment{
        Config:             cfg,
        CRDDirectoryPaths:  []string{
          filepath.Join("..", "..", "..", "config", "crds"),
          filepath.Join("..", "..", "..", "vendor", "github.com", "theiruser", "theirproject", "config", "crds"),
        },
        UseExistingCluster: true,
    }

This part of the code is describing how to add the external CRDs to the suite_test.go based on the steps informed. Note that in the suite_test.go it is required to inform the path for the CRD's for the envttest setup. More info: https://book.kubebuilder.io/cronjob-tutorial/writing-tests.html

Please, let me know if it is what you were looking for. I am looking for your reply to know if has anything else that we should address here or if it can be closed.

[DirectXMan12]

We get asked this question quite a bit -- we should have a short tutorial or a cookbook/short-recipes section that describes this, among other things, and explains how external types related to local types (they're mostly the same).

/help

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.