kpt should support advanced package update workflows

[droot]

Trying to capture two CUJs related to package update scenario and looking for feedback.

Package update workflow

namespace provisioning user guide features day 0 user journey for platform and application teams. This doc describes the day 2 user journey for for platform and application teams for namespace provisioning use-case.

If you completed the day 0 journey in the guide, then they will have following setup:

day 0

• An abstract package basens in the blueprint repository at a version say v4.
• A few deployable instances of basens in the deployment repository with different initial upstream versions v3, v4.

day 2

• Abstract basens package is updated in following ways and new version v5 is pushed:
  • New resources say network policy with defaults is added.
  • Some changes in an existing resource quota are made.
• In Config as data UI:
  • For deployable instances on version v3, UI should show that an update v3 --> v5 is available.
  • For deployable instances on version v4, UI should show that an update v4 -->v5 is available.
  • On the abstract package, UI should show affected deployable instances that needs to be updated to new version. A bulk operation to push the update to all deployable instances. Generally bulk action will be initiated after rolling/testing the update on a few individual deployable instances.
• In kpt CLI:
  • kpt alpha rpkg should implement similiar workflow listed for the UI above.
  • It will be nice to have following enhancements to kpt pkg update:
    • kpt pkg update --show-available-versions that shows available versions.
• Being able to preview or dry-run the update operation will be a great UX without a git PR will be a great UX.

Enforcing guardrails on downstream packages

The platform teams want to enforce guardrails for downstream packages. Let's make this more concrete in context of the namespace provisioning example. The platform teams want to enforce that all deployable instances of basens package should have a network policy that allows selective ingress traffic (i.e. disallow all ingress traffic except a few ports). basens package can have a validator function in its Kptfile but that assumes that the deployable instances will keep the validator function the Kptfile. Application team can manually remove the validator function either intentionally or accidentally and violations can go unchecked in that case.

There are a few ways to go about it:

1. admission control functionality at the repository level: platform teams can register set of functions at the repo level (deployment repo in this case) and whenever any package is modified through porch, the registered functions will be invoked on the package to enforce the guardrails. This obviously requires users to use porch.
2. package level workflow: This isn't super clear yet, but high level goal is that an upstream package (abstract package in this case) can constraint rendering workflow (especially validation) for a downstream package (deployable instances) (similar to inner mechanism https://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Thanks @bgrant0607 for reference). So we want to explore if concept of these guardrails can be baked natively in the kpt package workflow or not.

/cc @bgrant0607 @justinsb @mortent

[sbellan]

As a consumer, I might deploy the package in a dev/personal cluster and I might not need all the guardrails. Each team might want to do the enforcement differently. So if someone really wants guardrails, it is preferable to do it at the cluster level. Possibly kpt can have a utility to generate the manifest for the admission control.

[bgrant0607]

We are looking at injecting guardrails at the level of a registered repo in porch.

[bgrant0607]

Repo level guardrails: #3279