roadmap-2021.md

Kustomize roadmap 2021 Q3/4

Presented at the June 2, 2021 SIG-CLI meeting: recording

kustomize maintainers: @knverey, @monopole

Objective: Improve contributor community

Objective: Improve end-user experience

Objective: Improve extension experience

Objective: Improve contributor community

WHO: End user who also contributes source code.

• Publish (this) roadmap.
• Release sigs.k8s.io/kustomize/api v1.0.0 (PROJECT)
  • Fewer public packages:
    • builtins (generated code from legacy plugins): Internal
    • hasher (for secret and configmap generation): Internal, or maybe kyaml
    • ifc (single file with interfaces): Internal except maybe KustHasher and Validator
    • Image (utils for parsing image field): Move to image transformer
    • konfig: internalkrusty: keep external but rename it to e.g. “build” or “runner”
    • kv: internal
    • loader: internal
    • provenance: probably needs to stay external for the linker, but confirm
    • provider: internal
    • resmap: needs to stay external as long as the go plugins exist
    • testutils: try to make internal, but not a big deal
  • Vendor all transitive deps. Since kustomize is in kubectl, we must do as kubectl does to manage deps, exposing new transitive deps in code review.
  • Remove starlark dependencies (but make it possible to re-enable via injection)
• Kustomization v1 (also end-user impact) (PROJECT)
  • Deprecate vars field. Allowed but no longer honored. This includes:
    • merging and documenting the ReplacementTransformer
    • supporting vars→replacements migration in kustomize edit fix, with documentation
    • emitting warnings on stderr pointing users to the migration plan
  • Deprecate crds field with migration instructions to “openapi"
  • Add reorder field. Default should be FIFO and legacy should also be supported (could add alphabetic and custom sort support eventually). Replaces -reorder flag.
  • Consider deprecating configurations field (old, pre-plugin, pre-openapi global configuration)
• Improve contributor documentation
  • Clarify contributor docs regarding when discussions should happen on issues vs. brought to a SIG meeting
  • Add a top-level ARCHITECTURE.md document.
  • Improve docs for kyaml libraries, especially by adding examples.
  • Instructions to upgrade kustomize-in-kubectl (how to make a PR like this one). The description of that PR contains the instructions that worked on that particular date. Let this happen frequently
• Improve the release process to support regular biweekly releases PROJECT
  • More automation - it has toil because of the multiple modules.
  • More maintainers with authorization to do releases (e.g. create branches, delete mistake branches, move tags, trigger builds, etc.).
  • Include an upgrade PR to kubectl in the release process.
  • Send kustomize CLI version number into kubectl (kubectl issue / kustomize issue)
• Project administration
  • DONE Clean up Kustomize-related KEPs to reflect current status
  • DONE Onboard Kustomize repo to SIG-CLI’s Triage Party for bug scrubs
  • Rename master branch to main

Objective: Improve end-user experience

WHO: End user that wants kustomize build artifacts (binaries, containers).

• Improve end-user documentation PROJECT
  • Easily discovered tutorials for folks who just want to get the job done. Implicit best practice recommendation.
  • Usage tutorial videos
  • Clear explanation of differing capabilities of kustomize standalone vs. kustomize in kubectl. Document kubectl kustomize integration #3951
  • The kustomize doc site should pull examples from the kustomize repo
• Telemetry to guide investment decisions (PROJECT)
  • Idea: Resurrect "crawler" to gather stats on popularity of features so we know where to focus.
  • Idea: Allow opt-in to build data (Kustomize file sent to some server at build time)
  • A battery of Go benchmark tests to monitor performance. We've had reports of performance regression, but no measures in-repo.
• kustomize cli v5 (PROJECT)
  • Indentation changes from go-yaml, if we cannot prevent them in kubectl kustomize. (also related to a kyaml feature request)
  • Drop the --reorder flag
  • Decide what to do with kustomize cfg
    • Drop 'cfg create setter' and 'cfg set' and delete setter code from Kustomize (it lives in cmd/config).
    • Keep the cfg read-only commands: grep, cat, tree.
  • The --enable-alpha-plugins flag will remain in this version: this only changes when plugins graduate.
• Features
  • Kustomize Components KEP
    • Needs end-user docs
  • OpenAPI KEP
    • Should deprecate the existing crds field
  • Binary releases for M1 (darwin_arm64)
  • confusion around namespace replacement - this is the most +1’d feature request and is two years old
  • Release version 1.0 of sigs.k8s.io/kustomize/api for incorporating kustomize into other tools, as well as v1 of Kustomization. [see details under Contributor Community]
  • git caching scheme (behind a flag) kubernetes-sigs#3655
  • hashicorp go-getter support via dependency injection or external plugin

Objective: Improve extension experience

WHO: Plugin developers: end users who extend kustomize, but don’t think about internals.

• Replace Resource fields with annotations so that the data is visible to and survives across KRM function boundaries:
  • Replace Resource.options with annotations #3975
  • Replace Resource.refBy with annotations #3976
• Create KEP for plugin graduation out of alpha. PROJECT Proposals for this KEP:
  • Implement the Composition KEP .
  • Deprecation story
    • Deprecate shared Go libs. (if you use a Kustomization file that mentioned a plugin that must be loaded as a .so file, it fails). Although these have advantages--notably in terms of execution speed and ease of testing--they aren't portable.
    • Deprecate the legacy path lookup exec plugin style in favor of the KRM style that also already exists.
    • Add deprecation warnings if someone is using legacy plugins. See if we get complaints. Upon removal, add a fix command if feasible or at minimum a pointer to migration docs.
  • Create a roadmap for plugin inclusion in kustomize-in-kubectl, or explicitly document that plugins will never be included (and why).
  • Determine whether plugins need to be permanently gated with a flag. Remove the existing flag, and replace it with a non-alpha flag if necessary.
  • Deprecate KRM plugin configuration options that promote violations of Kustomize’s policy that everything required for a build should be committed (no side-effects from env, cli flags, etc). All plugin config should be in the KRM config object for the plugin.
    • Starlark plugins: Deprecate generic URL download for starlark plugins, replacing it with git-specific functionality in line with Kustomization’s own git URL support. Subject the relative path to loader restrictions.
    • Container plugins: Deprecate network access, storage mount and env options.
    • Exec plugins: Subject the exec path to loader restrictions.
  • Move KRM plugin provider specification from an annotation to a reserved field.
  • Add support for content-addressable OCI artifact storage for starlark and exec plugin providers.
  • Implement a Catalog KRM resource that uses OCI Artifacts (maybe) to improve plugin distribution and enable end users to bypass specifying explicit plugin provider versions in their KRM plugin configs. This likely deserves a KEP on its own.
  • Develop a streamlined contribution process for new “builtin” functionality, i.e. built-in transformers that essentially wrap kyaml filters.
• Add extensive docs, tests and examples for all plugin mechanisms that will remain supported after graduation.