`kpt live apply` can "render + deploy" DRY configs.

[yuwenma]

Describe the solution you'd like

Considering kpt as a compact tool, I expect running kpt live apply only can render my DRY config and deploy it to the cluster.

[yuwenma]

@droot @seans3 Any thoughts on this?

[morgante]

I think it's a good idea for apply to always render before deploying. We should never be applying un-rendered configs.

[frankfarzan]

This can potentially be provided as an option, but not done unconditionally. It should be possible to invoke post-processor function(s) imperatively after rendering a package:

$ kpt pkg get P
$ kpt fn render P
$ kpt fn eval P
$ kpt apply live P

[morgante]

Shouldn't it be safe to run kpt fn render again after running kpt fn eval?

[frankfarzan]

One of the use cases for eval is to execute a function from a CI/CD system on packages authored by other teams:

https://kpt.dev/book/04-using-functions/02-imperative-function-execution

So for example, a package pipeline can declare that value of label color should be set to orange. Using eval, you can override it by setting label color to blue before applying the package. In this use case, the package is not re-rendered again.

eval is for automating anything a human can do using an editor (in this case, manually changing all the labels). kpt doesn't care whether an edit was done manually using vim or automated via function and invoked using eval. It's conceptually part of the "Edit" noun:

https://kpt.dev/book/02-concepts/02-workflows

By design, there's no assumption than edits will not be overwritten by render.

[morgante]

What if you later update the package? Don't you need to re-render then anyways?

IMO we should really be pushing for idempotent render.

[droot]

I expect running kpt live apply only can render my DRY config and deploy it to the cluster.

At this stage of the project, the approach has been that each command should do one thing and they should do that one thing really well. And we should make it easy for users to compose these commands together and with other external programs, for ex. kpt fn render -o stdout| kpt fn eval -o unwrap|kubectl apply -. Mixing two commands such as apply and render also causes apply to be aware of all the failure modes of render and also expose all the render options (inplace/out-of-place etc) in apply.

Over time, we want to learn common workflows on how users chain/compose these commands together (so thanks for submitting this feedback) and potentially introduce porcelain or some other pattern to stitch commands together.

[frankfarzan]

What if you later update the package? Don't you need to re-render then anyways?

IMO we should really be pushing for idempotent render.

In the CI/CD use case, you would simply fetch the new version:

$ kpt pkg get P@v2
$ kpt fn render P
$ kpt fn eval P
$ kpt apply live P

For the iterative local flow, you would render again as shown in the 2nd image:

https://kpt.dev/book/02-concepts/02-workflows

Idempotency should hold for render:

1. kpt fn render
2. kpt fn render # no diff

But that's different from:

1. kpt fn render
2. Arbitrary edits (manual or automated)
3. kpt fn render # produces diff

Separate from this, there is outstanding work on improving merge strategy (pkg update) to better handle changes due to render.