Full support for CRDs

[dmgtn]

Brief overview:

1. Add new kind of hooks for CR conversion requests.
2. Add cmd-line options for conversion webhook parameters (listen port, SSL, service, and so on).
3. Add a better way of installing CRDs (special directory; fill webhookClientConfig).

Add new kind of hooks for CR conversion requests

1. Introduce new binding:

"onCustomResourceConversion": {
  "kind": "MyCustomResourceType",
  "conversions": [
    {from: "v1beta1", to: "v1beta2"}
  ]
}

2. TODO: Introduce format for passing ConversionRequest to the hooks

• File with objects to convert (path to the file in an environment variable)
• Several objects of the same kind can be passed at a time
• DesiredAPIVersion field as an environment variable

3. TODO: Introduce format for passing ConversionResponse from the hooks

• Result using return code
• Stdout as an error message
• File to save to converted objects (path to the file in an environment variable)

Add cmd-line options for conversion webhook parameters

• Port to listen
• Certificate to use
• CA to set to webhookClientConfig
• Service name, port, etc. to set to webhookClientConfig

Add a better way of installing CRDs

1. Add support for the directory with CRDs (exact path can be supplied using cmd-line args)
2. Parse all the CRDs in that directory and populate them with webhookClientConfig, if there are onCustomResourceConversion hooks, mentioning the same kind.
3. Install and update parsed and enriched CRDs to Kubernetes
4. Consider implementing preprocessing (using go-templates and sprig). Add built-in objects containing information about kubernetes version and available capabilities:
   • before 1.11 we don't have versions field, only version
   • before 1.13 we don't have webhook conversions (and until 1.15 they feature gate should be enabled)
   • before 1.15 we don't have defaulting

Implement extra logic

1. Support automatic chaining of several conversion hooks, if needed. For example, if one hook can convert from v1alfa1 to v1alfa2, and another can do the conversion from v1alfa1 to v1beta1, and the api-server asks us to do the conversion from v1alfa1 to v1beta1 – to hooks has to be chained.
2. Consider implementing logic, that automatically finds all objects stored in an old apiVersion and triggers a change to rewrite them (and trigger conversion).
3. Add cmd-line command to delete all installed CRDs. By default, only CRDs having no objects should be deleted. Add --force flag, to also delete CRDs having stored objects.

[dmgtn]

Config:

kubernetesCustomResourceConversion:
  - name: foo
    crdName: some-name
    conversions:
    - fromVersion: v1beta1
      toVersion: v1beta2
    - fromVersion: v1beta2
      toVersion: v1beta3
  - name: bar
    crdName: some-other-name
    conversions:
    - fromVersion: v1beta1
      toVersion: v1beta2
  - name: baz
    crdName: some-name
    conversions:
    - fromVersion: v1beta3
      toVersion: v1beta4
    includeSnapshotsFrom: ["myCrdObjects"]
    group: "group name"

Functions name for shell framework:

crd_conversion::foo
crd_conversion::foo::v1beta1_to_v1beta2
crd_conversion::bar
crd_conversion

[diafour]

CRD has a field .spec.conversion.webhook.conversionReviewVersions with versions in short form: "v1", "v1beta1". ConversionReview specifes desiredAPIVersion and apiVersion in objects in a full form: "stable.example.com/v1beta1". We can change the group in CRD and the hook will receive objects with the old group.
Is it correct to call a hook with binding fromVersion: v1beta1 for objects with apiVersion: stable.example.com/v1beta1?
In general, it is not. That is why implementation in PR #250 has these changes:

1. fromVersion and toVersion should be full apiVersion:

- fromVersion: stable.example.com/v1beta1
  toVersion: stable.example.com/v1beta2

2. Framework supports these function names:

__on_conversion::foo
__on_conversion::foo::stable.example.com.v1beta1::stable.example.com.v1beta2

[diafour]

The extra logic for CRD is discussed and not needed anymore.