kubernetes-sigs / controller-tools

Tools to use with the controller-runtime libraries

Kubernetes controller-tools Project

The Kubernetes controller-tools Project is a set of go libraries for building Controllers.

Development

Clone this project, and iterate on changes by running ./test.sh.

This project uses Go modules to manage its dependencies, so feel free to work from outside of your GOPATH. However, if you'd like to continue to work from within your GOPATH, please export GO111MODULE=on.

Releasing and Versioning

See VERSIONING.md.

Community, discussion, contribution, and support

Learn how to engage with the Kubernetes community on the community page.

controller-tools is a subproject of the kubebuilder project in sig apimachinery.

You can reach the maintainers of this project at:

• Slack channel: #kubebuilder
• Google Group: [email protected]

Code of conduct

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.

controller-tools's Issues

controler-gen fails if "group/version/types.go" is not an immediate child of "apis"

Overview

Current project organization expects versioned types go files to be 2 directories deep under apis directory. For example:

./pkg/apis/foo/v1alpha1/types.go

Adding any additional top-level grouping (but still under apis) - breatk controller-gen functionality.
For example:

pkg/apis
├── addtoscheme_foo_v1alpha1.go
├── apis.go
└── foo
    ├── buz
    │   ├── group.go
    │   └── v1alpha1
    │       ├── bar_types.go
    │       ├── bar_types_test.go
    │       ├── doc.go
    │       ├── register.go
    │       ├── v1alpha1_suite_test.go
    │       └── zz_generated.deepcopy.go
    └── group.go

3 directories, 10 files

make manifests
go run vendor/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go all
panic: Cannot get version for unversioned type github.com/user/foo/pkg/apis/foo/buz/v1alpha1.Bar

goroutine 1 [running]:
github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse.GetVersion(0xc427252b00, 0xc4218e0ad4, 0x3, 0xc4218e0ad4, 0xc42728ea50)
        /home/illya/go/src/github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse/util.go:218 +0x112
github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse.(*APIs).parseIndex(0xc4272878c0)
        /home/illya/go/src/github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse/index.go:68 +0x1ec
github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse.NewAPIs(0xc42727b020, 0xc4202554a0, 0xc42027b600, 0xc, 0xc42015b913, 0x1f, 0xc42015b7c0)
        /home/illya/go/src/github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse/parser.go:69 +0xc7
github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/crd/generator.(*Generator).Do(0xc426bbbc30, 0x0, 0x0)
        /home/illya/go/src/github.com/user/foo/vendor/sigs.k8s.io/controller-tools/pkg/crd/generator/generator.go:126 +0x366
main.newAllSubCmd.func1(0xc42026ec80, 0xeaf990, 0x0, 0x0)
        /home/illya/go/src/github.com/user/foo/vendor/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go:144 +0x1aa
github.com/user/foo/vendor/github.com/spf13/cobra.(*Command).execute(0xc42026ec80, 0xeaf990, 0x0, 0x0, 0xc42026ec80, 0xeaf990)
        /home/illya/go/src/github.com/user/foo/vendor/github.com/spf13/cobra/command.go:766 +0x2c1
github.com/user/foo/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc42026e500, 0x2, 0xc42026ec80, 0xc42026e650)
        /home/illya/go/src/github.com/user/foo/vendor/github.com/spf13/cobra/command.go:852 +0x30a
github.com/user/foo/vendor/github.com/spf13/cobra.(*Command).Execute(0xc42026e500, 0xc42016df60, 0x3)
        /home/illya/go/src/github.com/user/foo/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
        /home/illya/go/src/github.com/user/foo/vendor/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go:51 +0x14a
exit status 2
Makefile:30: recipe for target 'manifests' failed
make: *** [manifests] Error 1

Request

Add/update functionalilty in controller-gen to support apis to types organization that is more than 2 directories deep.

Add support for webhook namespace selector tag

The https://godoc.org/k8s.io/api/admissionregistration/v1beta1#Webhook configuration supports a namespace selector. That should be suppoorted in code generation as well.

Fix all context.TODO()

There are many context.TODO() in the repo.
They should be replaced with reasonable context.

Move godocbot to CR or KB repo

godocbot is currently under examples/godocbot.
Though it has its own vendor for dependencies, depwhen running at root dir still think it should vendor controller-runtime.

Add support for nested output layout

Currently, CRD generate emit CRD files in a "flat" layout structure: foo_v1alpha1_bar.yaml
It would be convenient/helpful to emit CRD files in a nested layout that resembles apis types organization:
foo/v1alpha1/bar.yaml

Remove generated file rules from gitignore

The generated project's gitignore contains rules to ignore zz_generated.*.
When a new CRD object API definition is generated, and zz_generated.deepcopy.go isn't committed, any other operator that consumes this API fails to build with error

*<ObjectName> does not implement runtime.Object (missing DeepCopyObject method)

Removing the rule and committing the generated file fixes the build issue for a consumer of the API.

Respect `+optional` comment tag during CRD generation

According to https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#optional-vs-required there are valid use cases for using the +optional comment tag without using omitempty.

Also note that according to the api-conventions.md doc linked above, omitempty's behavior in Kubernetes "may change in [the] future".

Therefore when generating CRDs, fields should be considered optional if they have either the +optional comment tag or omitempty.

Currently only omitempty is being respected.

A Prototype for this feature can be seen here:
https://github.com/kubernetes-sigs/controller-tools/compare/master...twiest:add_optional_comment_tag_support?expand=1

CRD generate still requires PROJECT file when --domain arg is set

Attempting to run crd generate --domain xyz in a non-kubebuilder project, which does not have a PROJECT file.

The help text seems to imply that a PROJECT file is not required if the --domain flag is set, however I am seeing that as not being the case:

crd generate --domain xyz
Writing CRD files...
2019/04/18 10:53:57 PROJECT file missing in dir 

FWIW, I am running this in the root directory of my project and the api path is correct.

Umbrella: Refactor for simpler building blocks, composability

We're hitting a number of issues with the current design of controller-tools (#81, #148, kubernetes-sigs/kubebuilder#620) that are due to internal architectural designs of controller-tools.

Currently, a several cases in controller-tools (e.g. controller-gen on crds) assume directory structures to infer information, which makes controller-gen difficult to re-use in other cases. Furthermore, a bunch of our code is based around gengo, which complicates the code itself and has its own set of assumptions (e.g. traversing sub-directories).

We should:

• Simplify controller-tools to have a base set of tooling that directly takes names of types to operate on, and single packages
• Wean controller-tools off of gengo in favor of a lighter-weight solution more appropriate for the limited functionality that we need
• Bring deepcopy-gen in line with the rest of controller-tools in terms of how it behaves and the information it requires (e.g. not requiring separate package level annotations, assuming we want runtime.Object implementations, potentially operating on specific types)

In order to do this, it's probably a good idea to deprecate the old auto-inferring behavior for a release.

More obvious reference docs

The book has some documentation on the various commands invovled in controller-tools, but some of it's hard to discover (e.g. reference docs for crd-gen are burried in Beyond Basics -> Deployment Workflow), some bits are quasi-external (like deepcopy-gen) and thus don't have docs, and other bits (like type-scaffold) aren't documented at all.

We should write some reference documentation on the commands, their invocations, and when you would use them to complement the book, and focus on the "why does KubeBuilder call these, and why are they needed bits".

support dry run with admission webhook

v0.1.9
Does it currently support dry run with admission control? In my CRD I will return this error "admission webhook "validating-create-update-s2ibuilder.kubesphere.io" does not support dry run", is there any plan support?

simpler base image?

controller-tools/examples/godocbot/Dockerfile

Line 28 in 7bc3911

FROM ubuntu:latest

Ubuntu is rather large and full of known exploits... https://hub.docker.com/r/library/ubuntu/tags/

Could we get something pinned to a version and maybe use a lightweight base image like Alpine.

Stop testing within the Dockerfile

quote escaping doesn't work properly in JsonPath for additionalPrinterColumn annotation

What happened:
Quote escaping expression does not work as expected in Jsonpath foradditionalPrinterColumns feature.

What you expected to happen:
It should handle the quote escaping expression

How to reproduce it (as minimally and precisely as possible):
you can use the below annotation for a given API type
// +kubebuilder:printcolumn:name="ready",type="string",JSONPath=".status.conditions[?(@.type==\"Ready\")].status"
With the above annotation, it genrates the following CRD:

  additionalPrinterColumns:
  - JSONPath: .status.conditions[?(@.type==\"Ready\")].status
    name: ready
    type: string

and if you use kubectl, it will print the information shown below:

$ kubectl get federatedclusters -n federation-system
NAME       
cluster1     
cluster2   

Ideally, it should output the following information:

$ kubectl get federatedclusters -n federation-system
NAME         AGE           READY
cluster1     20m           true
cluster2     20m           true

Check if dep is installed before running it. Instruct user how to download if not

Could CRD generation include field descriptions?

It'd be useful if the comment above each field in the type definition was included as the description field for that property in the OpenAPI schema for the generated CRDs.

json fields that contains numbers are ignored in json schema validation

json fields like json:"s3,omitempty" are omited in generated openAPIV3Schema validation for CRD yaml

struct tags containing digits are omitted from generated CRD

Using kubebuilder 1.0.7 and 1.0.8, given a struct that includes numbers in the value of a struct field tag, the resulting generated CRD will be missing any fields that had digits in their json tag:

struct

type MySpec struct {
	Foo  string `json:"foo"`
	Bar1 string `json:"bar1"`
}

command
go run vendor/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go all

CRD snippet

spec:
  properties:
    foo:
      type: string

hardcoded ns generation

according to
kubernetes-sigs/cluster-api-provider-openstack#213

the following hard coded ns lead to issue, better to make it configuable...

// Namespace returns the namespace to be used in the RBAC manifests.
func (o *ManifestOptions) Namespace() string {
// TODO(droot): define this as a constant and share it with scaffold pkg.
return "system"
}

Update controller-runtime to v0.1.10

To keep up-to-date with controller-runtime and controller-tools in general.
To leverage new features:

• CRD description
• logger

scaffold kustomization.yaml's for the configs

• config/manager
• config/crd

Should array schema include "format" key?

Does it make sense to include the "format" key within a schema when the type is "array"? For example, I created an array of strings and wanted those strings to be formatted as IPv4 addresses. After fixing #123 to ensure that "format" keys are included for strings I found that the "format" key was included in both the array definition and the "items" definitions. I cannot think of a reason why the outer format would be required.

With this in my types.go struct:

	// +kubebuilder:validation:Format=ipv4
	// list of IP addresses
	Addresses []string `json:"addresses,omitempty"`

I get this in my CRD yaml (notice the "format: ipv4" at both the array and items levels). I am proposing to remove the one at the array level unless there is a reason for this that I have not yet uncovered:

        spec:
          properties:
            addresses:
              description: list of IP addresses
              format: ipv4
              items:
                format: ipv4
                type: string
              type: array

OpenAPI schema description generation does not work for all types of fields

It looks like the description generation implemented in #102 works for some types of fields but not all.

For example, from the following type definition:

package v1alpha1

import (
        metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

// FooSpec description doesn't work
type FooSpec struct {
        // thisWorks description works
        thisWorks int64 `json:"thisWorks,omitempty"`

        // thisDoesntWork description does not work
        thisDoesntWork *DoesntWork `json:"thisDoesntWork,omitempty"`
}

type DoesntWork struct {
        // bar description does not work
        bar map[string]string `json:"bar,omitempty"`

        // baz description works
        baz string `json:"baz,omitempty"`
}

// +genclient
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

// Foo is the Schema for the foos API
// +k8s:openapi-gen=true
type Foo struct {
        metav1.TypeMeta   `json:",inline"`
        metav1.ObjectMeta `json:"metadata,omitempty"`

        Spec   FooSpec   `json:"spec,omitempty"`
}

// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object

// FooList contains a list of Foo
type FooList struct {
        metav1.TypeMeta `json:",inline"`
        metav1.ListMeta `json:"metadata,omitempty"`
        Items           []Foo `json:"items"`
}

func init() {
        SchemeBuilder.Register(&Foo{}, &FooList{})
}

The following CRD is generated:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  creationTimestamp: null
  labels:
    controller-tools.k8s.io: "1.0"
  name: foos.foobar.test.io
spec:
  group: foobar.test.io
  names:
    kind: Foo 
    plural: foos
  scope: Namespaced
  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:
          properties:
            thisDoesntWork:
              properties:
                bar:
                  type: object
                baz:
                  description: baz description works
                  type: string
              type: object
            thisWorks:
              description: thisWorks description works
              format: int64
              type: integer
          type: object
  version: v1alpha1
status:
  acceptedNames:
    kind: ""
    plural: ""
  conditions: []
  storedVersions: []

I would expect there to also be descriptions for spec, thisDoesntWork, and bar, but they don't show up.

The OWNERS_ALIASES file is invalid.

The OWNERS_ALIASES file in this repo cannot be loaded by Prow because it is not in the correct format.
https://github.com/kubernetes-sigs/controller-tools/blob/master/OWNERS_ALIASES

The aliases field should be a map[string][]string so the -s in front of the alias identifiers need to be removed. Example.

/assign @pwittrock

segfault panic on running `controller-gen webhook`

When run from the root of controller-runtime. Probably should just be a normal error.

Reproducer:

Have CR and CT checked out

$ cd $GOPATH/src/sigs.k8s.io/controller-runtime
$ go run ../controller-tools/cmd/controller-gen webhook
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0x115fbb2]

goroutine 1 [running]:
sigs.k8s.io/controller-tools/pkg/webhook.(*ManifestOptions).labelPatch(0xc0004ec9c0, 0x0, 0x0)
        $GOPATH/src/sigs.k8s.io/controller-tools/pkg/webhook/manifests.go:123 +0x42
sigs.k8s.io/controller-tools/pkg/webhook.Generate(0xc0004ec9c0, 0xc000510500, 0xc000139d30)
        $GOPATH/src/sigs.k8s.io/controller-tools/pkg/webhook/manifests.go:102 +0x671
main.newWebhookCmd.func1(0xc00013d180, 0x21f1870, 0x0, 0x0)
        $GOPATH/src/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go:181 +0x36
sigs.k8s.io/controller-tools/vendor/github.com/spf13/cobra.(*Command).execute(0xc00013d180, 0x21f1870, 0x0, 0x0, 0xc00013d180, 0x21f1870)
        $GOPATH/src/sigs.k8s.io/controller-tools/vendor/github.com/spf13/cobra/command.go:766 +0x2ae
sigs.k8s.io/controller-tools/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc0000eef00, 0xc000139f68, 0x4, 0x4)
        $GOPATH/src/sigs.k8s.io/controller-tools/vendor/github.com/spf13/cobra/command.go:852 +0x2c0
sigs.k8s.io/controller-tools/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        $GOPATH/src/sigs.k8s.io/controller-tools/vendor/github.com/spf13/cobra/command.go:800
main.main()
       $GOPATH/src/sigs.k8s.io/controller-tools/cmd/controller-gen/main.go:53 +0x166

Scaffold samples for APIs when they are created

Don't include Kind in names

Including the type name in the name of an object is superfluous and obscures the relations between them (IMO).

Thus, for example, we should call the ClusterRole foo-manager, not foo-manager-role. The StatefulSet / Deployment should be foo-manager, it uses a ServiceAccount of foo-manager, which has a ClusterRoleBinding foo-manager to a ClusterRole foo-manager.

The other problem is that adding -role (for example) is actually misleading, because it's actually a ClusterRole, not a Role.

For basic validation and defaulting webhooks, default to a stronger failurepolicy

Since we're working on making the cases of webhook use for defaulting and validation easier, we might want to consider generating webhook configs with a "stronger" failurepolicy (i.e. not "ignore") for those, so that bad objects can't sneak into the cluster if our webhook server fails.

cc @mengqiy

Scaffolding unit tests for webhooks

Currently we don't scaffold any unit tests.
But we should do it like scaffolding controller tests.

Tests are failing when running locally

Am I running them wrong?

$ ./test.sh
[...]
pkg/crd/generator/generator.go:32:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen not allowed
pkg/crd/generator/generator.go:33:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen/parse not allowed
pkg/internal/codegen/parse/apis.go:27:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/internal/codegen not allowed
pkg/internal/codegen/parse/index.go:27:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/internal/general not allowed
pkg/rbac/manifests.go:28:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/internal/general not allowed
pkg/webhook/manifests.go:32:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/internal/general not allowed
pkg/webhook/manifests.go:33:2: use of internal package github.com/kubernetes-sigs/controller-tools/vendor/sigs.k8s.io/controller-tools/pkg/webhook/internal not allowed

Come up with a solution for distributing binaries for apiserver, etcd, kubectl

Maybe controller-tools install command that downloads and installs them. Should be in a location found by these tools

https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/test/server.go#L32

Avoid overriding values if already set in rbac options when setting defaults

pkg/rbac.ManifestOptions.SetDefaults overrides existing values without checking them. If they have already be set this method should not override with the default as commented in #147 (comment).

Allow generation of validation for types from k8s.io/api

We currently explicitly skip types from k8s.io/api, for no apparent reason. We should allow generating validation for such types, even if it's only structural (optional vs required, basic type information)

/kind feature
/priority important-soon

CLI option to generate complete schema

Currently, in the generated CRD schema, the fields ObjectMeta and TypeMeta are just objects. This seems to be by design. Anyhow, there needs to be a command-line option to generate a complete schema. This will be useful for IDE consumption.

Add alpha command tree

In order to allow more flexibility for developers to add features without disrupting the existing roadmap, create an alpha cmd tree

Failure: controller-gen/main.go crd processes all directories (including vendor)

It appears to be a regression as a result of #144 where apis-path and apis-pkg were added only in cmd/crd/cmd/generate.go, whereas it should be added in both cmd/crd/cmd/generate.go and cmd/controller-gen/main.go.

This results in failure when running via controller-gen/main.go since it attempts to process all directories under root path (including vendor) and ultimately fails on:
panic: Cannot get version for unversioned type sigs.k8s.io/controller-tools/pkg/internal/codegen/parse.IsAPIResource

Util funcs do not correctly handle windows paths

This issue was found in an attempt to run kubebuilder on Windows.

As an example, assume a windows GOPATH of C:\Whisk\knative\testevtsrc with the complete project folder being C:\Whisk\knative\testevtsrc\src\github.ibm.com\mdeuser\test-event-source

Some of the pkg\crd\util\util.go funcs, such as DirToGoPkg, do not correctly handle the UNC path separators. Using the above example, DirToGoPkg would produce the package prefix string

github.ibm.com\mdeuser\test-event-source

which kubebuilder would use to produce import statements having incorrect separators

github.ibm.com\mdeuser\test-event-source/pkg/apis
github.ibm.com\mdeuser\test-event-source/pkg/controller
github.ibm.com\mdeuser\test-event-source/pkg/webhook

Mildly related to kubernetes-sigs/kubebuilder#300

Support overriding CRD type validation for structs

Currently, it seems the validation type for structs is always assumed to be object.

controller-tools/pkg/internal/codegen/parse/crd.go

Lines 436 to 441 in 5752ac2

	func (b *APIs) parseObjectValidation(t *types.Type, found sets.String, comments []string, isRoot bool) (v1beta1.JSONSchemaProps, string) {
	buff := &bytes.Buffer{}
	props := v1beta1.JSONSchemaProps{
	Type: "object",
	Description: parseDescription(comments),
	}

However, structs can be serialized into types other than object. Is there a way to override the type detection for structs?

I'm trying to do something like the following:

package status

// Conditions manages status conditions
type Conditions struct {
    conditions map[ConditionType]Condition
}

// MarshalJSON marshals Conditions into a JSON array 
func (c Conditions) MarshalJSON() ([]byte, error) {
    conditionList := []Condition{}
    for k, v := range c.conditions {
        conditionList = append(conditionList, v)
    }
    return json.Marshal(conditionList)
}

package v1alpha

// +k8s:openapi-gen=true
type MyAppStatus struct {
    // When the CRD generator creates the validations, it sees that Conditions
    // is a struct, but since it is marshalled as a JSON list, the default type detection
    // doesn't work.
    //
    // Perhaps support for a new Type validation tag could be added?
    // +kubebuilder:validation:Type=array
    Conditions status.Conditions `json:"conditions"`
}

[RBAC] Allow to configure ServiceAccount

Would enable what was proposed in kubernetes-sigs/kubebuilder#601.

/kind feature
/priority important-longterm
/sig api-machinery

"crd generate" with CRD versioning?

Any plans for how crd generate can support the upcoming CRD versioning? Or does it work already?

E.g. there is a Versions field that contains per-version schema, printer columns, etc.

Just curious if you have plans to support this before we adopt the tool, thanks!

pkg/apis/... tests don't compile after adding a second time

The test name for each api is TestStorage so when we create 2 apis in the same package their names conflict.

Format validation key specified for string typed field is being ignored

Following http://kubebuilder.netlify.com/beyond_basics/generating_crd.html#validation I tried to specify Format validation key for a string typed field e.g.

	// +kubebuilder:validation:Format=hostname
	Hostname string `json:"hostname"`

Generated CRD validation openAPIV3Schema included the property but format was ignored:

          properties:
            hostname:
              type: string

I expected

          properties:
            hostname:
              type: string
              format: hostname

Bug seems to be in https://github.com/kubernetes-sigs/controller-tools/blob/master/pkg/internal/codegen/parse/crd.go#L279
where additionally f should be set to props.Format if one is set (i.e. non-empty string).

Affected version: "v0.1.8"

deepcopy-gen should support unset GOPATH

deepcopy-gen currently requires gopath to be set, despite the fact that a default gopath exists. We should support both that use case, and the eventual go modules usecase, which doesn't require a gopath.

cc kubernetes-sigs/kubebuilder#542

[RBAC] Allow to configure output file names

Would allow to execute multiple rbac generatios in the same project without having to rename the files after each operation in case all need to be ketp.

Would enable what was proposed in kubernetes-sigs/kubebuilder#601 (comment).

/kind feature
/priority important-longterm
/sig api-machinery

Add flags of other generators in `controller-gen all`

controller-gen all runs all available generators, but doesn't provide flags of those generators. For example, controller-gen crd --skip-map-validation. It should be extended to include all those flags.

Merge existing and newly generated CRD OpenAPIv3 validation blocks

Whenever I modify a type, or add/remove/update +kubebuilder:validation: directives from api's in pkg/apis/<group>/<version>/*.go, a CRD is generated with a validation block containing these changes. However if I add some validation field in a CRD that exists on-disk for an existing api, that field should be preserved in certain situations. Example:

On-disk CRD:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
...
spec:
  validation:
    openAPIV3Schema:
      properties:
        apiVersion:
          type: string
...
        spec:
          properties:
            size:
              format: int32
              type: integer
            test:
              type: string
          required:
          - size
          type: object
...

Then write a value to some field manually, ex. spec.validation.openAPIV3Shema.properties.spec.properties.size.title = "foo bar".

Desired CRD after generation:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
...
spec:
  validation:
    openAPIV3Schema:
      properties:
        apiVersion:
          type: string
...
        spec:
          properties:
            size:
              format: int32
              type: integer
              title: foo bar # << added manually
            test:
              type: string
          required:
          - size
          type: object
...

As far as I can tell, the CRD generator will overwrite the title field, even though there is no +kubebuilder:validation:Title annotation according to the kubebuilder book. Is it possible to support persisting fields added manually, i.e. merge old and new CRD's, if:

• There is no +kubebuilder:validation: directive for that field
• The CRD generator did not generate a value for that field

Make Gofmt goldenfiles work

• Remove option to generate Makefile without gofmt
• Make scaffolded files already gofmted by sorting imports to match gofmt

Add external Type to scaffold

Configure scaffold to access a non-core type created in another project.

• A CRD that is created and installed in another project.
• A CR defined via an API Aggregation (AA). Aggregated APIs are subordinate APIServers that sit behind the primary API server, which acts as a proxy.

controller-scaffold external-type --domain example.com --group ship --version v1beta1 --kind Frigate

Add support for additionalPrinterColums

Related: kubernetes-sigs/kubebuilder#447

It should be possible to generate additionalPrinterColumns for CRDs, possible example:

//+kubebuilder:printcolumn:ready:type=string
//+kubebuilder:printcolumn:ready:description="Is the cluster ready?"
//+kubebuilder:printcolumn:ready:jsonpath=".status.conditions[?(@.type==\"Ready\")].status"
//+kubebuilder:printcolumn:ready:format=bla
//+kubebuilder:printcolumn:ready:priority=1

Figure out if we want an install.sh script

Do we want something like this:

https://github.com/golang/dep/blob/master/install.sh