KubeCon F2F Meeting 2026-03-25/26

[CsatariGergely]

Participants

• @ciaranjohnston
• @kispaljr
• @mozesl-nokia
• @liamfallon
• @CsatariGergely

Topics

kpt to v1.0.0

• kpt does not have an API on wire, but it has an API on types
• kpt has some API objects in the repo first
• Let's do semantic versioning for kpt, the SDK and for the individual functions in the function catalog
• Things what we need to do before announcing v1.0.0
  • There are some types copied from Kuberntes and kubctl. We should go back and use the upstream ones. These are in kpt and in Porch also
  • Update the documentation
  • The SDK and the function catalog have their separate versions
  • kpt --version should also provide the right version on all architectures
• Dependencies
  • The functions use the SDK and the SDK uses kpt
  • The function use only kpt types, there is no need to bump the version in the functions until the types are backward compatible
• @liamfallon will create an issue to follow up on the version 1.0.0 work

We need to study mutation pipelines. Can we move the Porch mutation pipelines to kpt?

• For working on the pipeline we should not need Porch
• There are two things to move here
  • Function execution environment
  • Render pipeline execution
• Porch would just call these from kpt
  • The Porch multi executor should be moved to kpt
  • The render logic should not be duplicated
  • The render processor would receive only one function executor
• We should use consistent naming for this in the documentation
  • @kispaljr can explain these to Mike and Dominka (Nokia tech writer team) who could come up a name

kpt - Porch border

• Porch is responsible for automation
• kpt is the execution project
• We should start to organize a public go API in the kpt repo what is used by kpt

Clean up the kpt repo

• Clean up the upgrade / update terminology
• Need to refactor / remove the "thirdparty" - refer to upstream or absorb
• update the internal utils/update directory
• versioning, 3-way merge needs to be brought into the kpt documentation
• remove kpt/docs
• remove firebase references
• investigate healthcheck to see if it is needed
• refactor what was moved over from porch
• some of the stuff (all?) in internal can be moved out - are there internal APIs we want / need to protect?
• mdtogo - do we keep this or is it copied from somewhere else?
• should examples move to samples? These are used for running tests so maybe not
• investigate oci in the pkg directory
• kpt/pkg/printer needs investigating
• kpt/run needs investigating

Refactor the kpt code following the port of improvements from Porch EPIC: Refactor the kpt code following the port of improvements from Porch #4378

• Do bit by bit refactoring, no big bang refactoring

docs versioning

GSOC - expectations etc.

• Deadline is 31rd. We need to review submissions and decide on which one we want to bring forward.

Package developers guide in the documentation

• Needs to be put into the kpt documentation - @CsatariGergely will find out internally who will do this
• We should get rid of the book structure
• We need a better SDK

Marketing

• Let's start a kpt LinkedIn. @CsatariGergely can do it

Roadmap

• Add label to the roadmap issues and create a dashboard

The actual roadmap

• Refactor and improve mutation pipelines
• Introduce conditional expressions in mutation pipelines
• Stable API
• Secrets handling
• Independent subpackage creation, clone, update
• First class Helm support in mutation pipelines
• Multi cluster support
• Improved examples - more complex scenarios for multi-cluster deployments