Type generation from a cluster openAPI spec should be optional

[pwittrock]

orgs will probably want to explicitly choose the types that are used, rather than have them generated ad-hoc per user.

[willbeason]

I assume you mean directly from a CRD (or set of CRDs)?

[frankfarzan]

To expand on the feature request:

We should make type generation from user-supplied cluster optional. If the user just wants to use core types, we can have pre-generated types for one or more api versions.

[willbeason]

Ok, so if I understand correctly, the two modes are:

1. Generate all core types from built-in swagger definitions
2. Generate from swagger obtained from a cluster

[frankfarzan]

GoogleContainerTools/kpt-functions-sdk#1 is one implementation option. Alternatively, we can just package up pre-generated *.ts files (as part of the SDK or CLI NPM packages) and avoid a call to typegen all toghether.

[frankfarzan]

Where the pregenerated artifacts live is also up for discussion. It could be part of the NPM package or dynamically downloaded (e.g. from a GCS bucket). We take the latter approach with the typgen Go binary itself to avoid bloating the NPM package.

[frankfarzan]

For context: this would eliminate having a kubernetes cluster (locally or remotely) which would simplify the onboarding process.

[frankfarzan]

Talked with Phani, this is the proposal:

• In type_create.ts [1], provide these options:
  • Download swagger file from a cluster by choosing a kubeconfig context (Current behavior)
  • Use a default swagger file which is downloaded from a storage bucket. What's the default version? Do we want to support different API version?
  • Download swagger file from local disk (Optional, can be a follow up).

[1] https://github.com/GoogleContainerTools/kpt-functions-sdk/blob/master/ts/create-kpt-functions/src/cmd/type_create.ts