Repository: GoogleContainerTools/kpt
Pull request #3101 (2022-05-06 18:06:55)

Update the auth flags for registering repositories
We will eventually add support for other auth types than just basic auth. Therefore we need a convention for how we name the flags used for authentication against package repositories. This updates the current flags to follow the following convention:
* Flags used the format: `repo-<auth type>-<input>`
  * Every flag use the `repo-` prefix to make it clear it pertains to repository auth (rather than cluster) and to avoid conflicts with existing flags we inherit from kubectl (examples are username and password).
  * The auth type section tells which type of authentication this flag is used for. Currently we only support basic auth.
  * The last part contains the name of data needed for the specified auth type. For example, for basic auth, we need username and password.

Following this convention, the flags for specifying username and password for basic auth results in the flags `repo-basic-username` and `repo-basic-password`.


Patch:
diff --git a/CODEOWNERS b/CODEOWNERS
index f3d1f4b0..d298b84e 100644
--- a/CODEOWNERS
+++ b/CODEOWNERS
@@ -1,12 +1,18 @@
-# Docs need to have a single approver to maintain consistency.
-/site @droot @frankfarzan @phanimarupaka @mengqiy @yuwenma @natasha41575
+# Generally we are following a permissive policy of code ownership
+# Some people have asked for only minimal permissions to avoid notification spam: @bgrant0607
+
+# Default, unless something takes precedence below
+* @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
+
+# Docs
+/site @bgrant0607 @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
 # These packages are referenced in docs.
-/package-examples/nginx/ @droot @mortent @phanimarupaka @mengqiy
-/package-examples/wordpress/ @droot @mortent @phanimarupaka @mengqiy
+/package-examples/nginx/ @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
+/package-examples/wordpress/ @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
 
 # Schemas changes additional scrutiny.
-/pkg/api @droot @mortent @phanimarupaka @mengqiy
+/pkg/api @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
 
 # These tests enforce the behavior for fn
-kpt/e2e/testdata/fn-render @droot @phanimarupaka @mengqiy
-kpt/e2e/testdata/fn-eval @droot @phanimarupaka @mengqiy
+kpt/e2e/testdata/fn-render @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
+kpt/e2e/testdata/fn-eval @droot @justinsb @mengqiy @martinmaly @mortent @natasha41575 @yuwenma
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
index cc2c3719..f70138ee 100644
--- a/docs/ROADMAP.md
+++ b/docs/ROADMAP.md
@@ -1,55 +1,26 @@
-# kpt roadmap for 2021
+# kpt roadmap
 
-Last updated: November 5th, 2021
+Last updated: May 6th, 2022
 
 Please follow the [installation](https://kpt.dev/installation/) guide for installing the latest version of kpt.
 
-## Latest releases
+We are planning to build a new roadmap pending user feedback on the new package orchestration capabilities.
 
-### Targeting resources in `kpt fn` commands
+## Latest releases
 
-Users want to invoke a kpt function (imperatively and declaratively) on a subset of
-resources in the package by selecting them on the basis of GVKNN(Group, Version, Kind, Name, Namespace), package-path,
-file path etc. For example, set work-load identity annotation on all Kubernetes
-Service Account resources in this package. Here is the documentation for list of
-available selectors for [render] and [eval]. Available in [v1.0.0-beta.7]+ versions of kpt.
-More selectors will be added incrementally.
+Coming soon...
 
 ## Detailed release notes
 Please refer to the [release notes] page for more information about the latest features.
 
 ## Upcoming features
 
-### Improve Function Authoring Experience
-
-We need a rich ecosystem of third party functions. Users should be able to write
-functions with custom logic very quickly using the tools they are familiar with.
-So we are investing on making function authoring experience very easy. This is an
-ongoing effort. 
-- [Starlark enhancements](https://catalog.kpt.dev/starlark/v0.3/?id=developing-starlark-script)
-have been released. 
-- For Golang SDK([issue](https://github.com/GoogleContainerTools/kpt/issues/2568)), **Estimated release date:** End of November 2021.
-
-### Best practices for kpt with idiomatic package examples
-
-We need to publish best practices to use kpt inorder to create and use kpt packages.
-This will help users to understand the right way of using kpt. These best practice
-guidelines should be backed by idiomatic kpt package examples. These packages should
-be designed reflecting the best practices, easily discoverable and simple to understand.
-This is an ongoing effort. [Tracking issue](https://github.com/GoogleContainerTools/kpt/issues/2541)
-- Best practices guide, **Estimated release date:** End of November 2021.
-- Idiomatic package examples, **Estimated release date:** End of December 2021.
-
-### Merging pipeline section during `kpt pkg update`
-
-Currently, `kpt pkg update` doesn't merge pipeline section in the Kptfile as expected.
-The fact that pipeline section is non-associative list with defined ordering makes it 
-very difficult to merge with upstream counterpart. This is forcing users to use setters
-and discouraging them from declaring other functions in the pipeline as they will be
-deleted during `kpt pkg update`. Merging pipeline correctly will reduce
-huge amount of friction in declaring new functions which in turn helps to avoid
-excessive parameterization. [Tracking issue](https://github.com/GoogleContainerTools/kpt/issues/2529). 
-**Estimated release date:** End of December 2021.
+A few areas of work are ongoing. (This is not exhaustive.)
+
+### Package orchestration
+
+See the [package orchestration roadmap](https://github.com/GoogleContainerTools/kpt/blob/main/porch/docs/porch-roadmap.md)
+for more details.
 
 ### Explore various options for function runtime
 
@@ -59,15 +30,6 @@ be exploring different function runtimes in order to address those issues. This
 just an exploratory step and actual implementation if any, will be taken up after December 2021.
 [Tracking issue](https://github.com/GoogleContainerTools/kpt/issues/2567).
 
-### Integrate kpt with Cloud Code
-
-One of the major areas of investment is to integrate [Cloud Code](https://cloud.google.com/code) with kpt to provide
-package authoring assistance. Users can author Kptfile and functionConfig files with
-features like auto-complete and error detection. This significantly improves the
-discoverability of Kptfile schema, catalog functions and their functionConfigs.
-- Cloud code integration with Kptfile schema has been [released](https://github.com/GoogleCloudPlatform/cloud-code-intellij/blob/main/CHANGELOG.md) and available from 21.10.1+ versions of Cloud Code.
-- Function catalog integration, **Estimated release date:** End of December 2021.
-
 ### Additional storage beyond Git
 
 Currently, `kpt pkg` workflows only support Git repositories. There is some increasing
@@ -79,15 +41,10 @@ be spending time understanding the use-cases and need for this project. [Trackin
 1. kpt-users@googlegroups.com
 
 [new issue]: https://github.com/GoogleContainerTools/kpt/issues/new/choose
-[declarative function execution]: https://kpt.dev/book/04-using-functions/01-declarative-function-execution
-[apply-setters documentation]: https://catalog.kpt.dev/apply-setters/v0.1/ 
 [The Kpt Book]: https://kpt.dev/book/
 [apply chapter]: https://kpt.dev/book/06-apply/
 [cli-utils]: https://github.com/kubernetes-sigs/cli-utils
 [function catalog]: https://catalog.kpt.dev/
 [kpt milestones]: https://github.com/GoogleContainerTools/kpt/milestones
 [migration guide]: https://kpt.dev/installation/migration
-[render]: https://kpt.dev/book/04-using-functions/01-declarative-function-execution?id=specifying-selectors
-[eval]: https://kpt.dev/book/04-using-functions/02-imperative-function-execution?id=specifying-selectors
-[v1.0.0-beta.7]: https://github.com/GoogleContainerTools/kpt/releases/tag/v1.0.0-beta.7
-[release notes]: https://github.com/GoogleContainerTools/kpt/releases
\ No newline at end of file
+[release notes]: https://github.com/GoogleContainerTools/kpt/releases
diff --git a/docs/design-docs/07-package-orchestration.md b/docs/design-docs/07-package-orchestration.md
index 23bf57a4..b57bbee8 100644
--- a/docs/design-docs/07-package-orchestration.md
+++ b/docs/design-docs/07-package-orchestration.md
@@ -509,8 +509,8 @@ GITHUB_TOKEN=<GitHub Personal Access Token>
 
 $ kpt alpha repo register \
   --namespace default \
-  --repo-username=${GITHUB_USERNAME} \
-  --repo-password=${GITHUB_TOKEN} \
+  --repo-basic-username=${GITHUB_USERNAME} \
+  --repo-basic-password=${GITHUB_TOKEN} \
   https://github.com/${GITHUB_USERNAME}/blueprints.git
 ```
 
@@ -526,8 +526,8 @@ All command line flags supported:
 * `--deployment` - Boolean value; If specified, repository is a deployment
   repository; published packages in a deployment repository are considered
   deployment-ready.
-* `--repo-username` - Username for repository authentication.
-* `--repo-password` - Password for repository authentication.
+* `--repo-basic-username` - Username for repository authentication using basic auth.
+* `--repo-basic-password` - Password for repository authentication using basic auth.
 
 Additionally, common `kubectl` command line flags for controlling aspects of
 interaction with the Kubernetes apiserver, logging, and more (this is true for
diff --git a/internal/cmdreporeg/command.go b/internal/cmdreporeg/command.go
index 58afbca1..21f9ac2c 100644
--- a/internal/cmdreporeg/command.go
+++ b/internal/cmdreporeg/command.go
@@ -50,11 +50,11 @@ Flags:
 --deployment
   Repository is a deployment repository; packages in a deployment repository are considered deployment-ready.
 
---repo-username
-  Username for repository authentication.
+--repo-basic-username
+  Username for repository authentication with basic auth.
 
---repo-password
-  Password for repository authentication.
+--repo-basic-password
+  Password for repository authentication with basic auth.
 
 --directory
   Directory within the repository where to look for packages.
@@ -87,8 +87,8 @@ func newRunner(ctx context.Context, rcg *genericclioptions.ConfigFlags) *runner
 	c.Flags().StringVar(&r.name, "name", "", "Name of the package repository. If unspecified, will use the name portion (last segment) of the repository URL.")
 	c.Flags().StringVar(&r.description, "description", "", "Brief description of the package repository.")
 	c.Flags().BoolVar(&r.deployment, "deployment", false, "Repository is a deployment repository; packages in a deployment repository are considered deployment-ready.")
-	c.Flags().StringVar(&r.username, "repo-username", "", "Username for repository authentication.")
-	c.Flags().StringVar(&r.password, "repo-password", "", "Password for repository authentication.")
+	c.Flags().StringVar(&r.username, "repo-basic-username", "", "Username for repository authentication using basic auth.")
+	c.Flags().StringVar(&r.password, "repo-basic-password", "", "Password for repository authentication using basic auth.")
 
 	return r
 }
diff --git a/site/book/02-concepts/00.md b/site/book/02-concepts/00.md
index a59aef26..d52440cc 100644
--- a/site/book/02-concepts/00.md
+++ b/site/book/02-concepts/00.md
@@ -1,51 +1,44 @@
 What is kpt?
 
-> kpt is a Git-native, schema-aware, extensible client-side tool for packaging, customizing,
-> validating, and applying Kubernetes resources.
-
-That's a pretty terse description, so let's break it down:
-
-- **Git-native**: kpt uses Git to share, consume, and update configuration. As a result,
-  configuration changes may be reviewed, approved, audited and rolled back using existing Git
-  workflows.
-
-- **Schema-aware**: Configuration used by kpt must conform to the _Kubernetes Resource Model
-  (KRM)_ which have a defined schema and semantics. KRM resources — whether core Kubernetes
-  resources such as `Deployment` or custom resources defined using a `CRD` — have an OpenAPI
-  specification which is used for schema-aware operations in kpt. For example, when rebasing a
-  locally modified package to a new version, the merge operation is more than simply performing a
-  text-based file merge, it takes the schema into account.
-
-  In contrast, many configuration tools today interleave data and code, for example by embedding a
-  templating language in YAML. As configuration becomes complex, it becomes hard to read and
-  understand. Furthermore, this prevents external tooling from easily consuming such configuration
-  leading to a closed ecosystem.
-
-- **Extensible**: kpt provides a small core machinery and powerful extension mechanisms. There are
-  two main extension mechanisms in kpt: a) kpt can gain semantic understanding of arbitrary KRM
-  resources by consuming OpenAPI documents. kpt core itself does not hardcode any type-specific
-  information. b) kpt can perform arbitrary operations on resources using kpt functions.
-
-- **Packaging**: A package is a bundle of KRM resources representing a useful unit of functionality.
-
-- **Customizing**: Off-the-shelf packages are rarely deployed without any customization. We know
-  from experience working with Kubernetes configuration and with internal systems at Google that
-  there is no one-size-fit-all customization technique. Sometimes the most appropriate customization
-  is to edit a YAML file directly. Sometimes, you want to automate a one-time customization,
-  sometimes you want to repeatedly perform a customization. Sometimes you want to use
-  parameterization, sometimes perform bulk search & replace, sometimes you want to use a
-  general-purpose programming language. kpt enables all these techniques. In contrast, tools that
-  provide just one customization technique (e.g. parameterization) cannot address all these
-  different use cases well and inevitably lead to anti-patterns (e.g. over-parameterization).
-
-- **Validating**: In the era of fast-paced DevOps, we need to reduce the risk of misconfiguration
-  leading to an outage, security vulnerabilities, or non-compliance. Validation goes hand-in-hand
-  with customization and kpt functions can be used to automate both mutation and validation of
-  resources. Example of validator functions include schema-validation, linting, policy enforcement,
-  and security auditing.
-
-- **Applying**: When it comes to deploying a package to a Kubernetes cluster, kpt complements
-  `kubectl`. By keeping an inventory of deployed resources, kpt enables resource pruning, aggregated
-  status and observability, and an improved dry-run experience.
-
-The two fundamental concepts in kpt are packages and functions. Let's define them.
+> A package-centric toolchain that enables a WYSIWYG configuration authoring, automation, and delivery experience, which simplifies managing Kubernetes platforms and KRM-driven infrastructure at scale by manipulating declarative Configuration as Data, separated from the code that transforms it.
+
+kpt supports management of [Configuration as Data](https://github.com/GoogleContainerTools/kpt/blob/main/docs/design-docs/06-config-as-data.md), which enables WYSIWYG editing and interoperable automation on a declarative data model for Kubernetes and any infrastructure represented in the [Kubernetes Resource Model (KRM)](https://github.com/kubernetes/design-proposals-archive/blob/main/architecture/resource-management.md).
+
+kpt manages KRM resources in bundles called **packages**.
+
+Off-the-shelf packages are rarely deployed without any customization. Like [kustomize](https://kustomize.io), kpt applies transformation **functions**, using the same [KRM function specification](https://github.com/kubernetes-sigs/kustomize/blob/master/cmd/config/docs/api-conventions/functions-spec.md), but optimizes for in-place configuration transformation rather than out-of-place transformation. 
+
+Validation goes hand-in-hand with customization and kpt functions can be used to automate both mutation and validation of resources, similar to [Kubernetes admission control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/). 
+
+The kpt toolchain includes the following components:
+
+- [**kpt CLI**](https://kpt.dev/reference/cli/): The kpt CLI supports package and function operations, and also
+  deployment, via either direct apply or GitOps. By keeping an inventory of deployed resources, kpt enables resource pruning,
+  aggregated status and observability, and an improved preview experience.
+
+- **Function SDKs**: Any general-purpose or domain-specific language can be used to create functions to transform and/or validate
+  the YAML KRM input/output format, but we provide SDKs to simplify the function authoring process, in 
+  [Go](https://kpt.dev/book/05-developing-functions/02-developing-in-Go), 
+  [Typescript](https://kpt.dev/book/05-developing-functions/03-developing-in-Typescript), and 
+  [Starlark](https://catalog.kpt.dev/starlark/v0.2/), a Python-like embedded language.
+
+- [**Function catalog**](https://catalog.kpt.dev/): A catalog of off-the-shelf, tested functions. kpt makes configuration
+  easy to create and transform, via reusable functions. Because they are expected to be used for in-place transformation,
+  the functions need to be idempotent.
+
+- [**Package orchestrator**](https://github.com/GoogleContainerTools/kpt/blob/main/docs/design-docs/07-package-orchestration.md): 
+  The package orchestrator enables the magic behind the unique WYSIWYG experience. It provides a control plane for creating,
+  modifying, updating, and deleting packages, and evaluating functions on package data. This enables operations on packaged resources
+  similar to operations directly on the live state through the Kubernetes API.
+
+- [**Config Sync**](https://cloud.google.com/anthos-config-management/docs/config-sync-overview): While the package orchestrator
+  can be used with any GitOps tool, Config Sync provides a reference GitOps implementation to complete the WYSIWYG management
+  experience and enable end-to-end development of new features, such as 
+  [OCI-based packages](https://github.com/GoogleContainerTools/kpt/issues/2300). Config Sync is also helping to drive improvements
+  in upstream Kubernetes. For instance, Config Sync is built on top of [git-sync](https://github.com/kubernetes/git-sync) and
+  leverages [Kustomize](https://kustomize.io) to automatically render manifests on the fly when needed. It uses the same apply
+  logic as the kpt CLI.
+
+- **Backage UI plugin**: We've created a proof-of-concept UI to demonstrate the WYSIWYG experience that's possible on top of the
+  package orchestrator. More scenarios can be supported by implementing form-based editors for additional Kubernetes resource types.
+  


Test patch:
diff --git a/internal/cmdreporeg/command_test.go b/internal/cmdreporeg/command_test.go
index fbeaa1c6..77dad9fc 100644
--- a/internal/cmdreporeg/command_test.go
+++ b/internal/cmdreporeg/command_test.go
@@ -75,7 +75,7 @@ func TestRepoReg(t *testing.T) {
 		},
 		{
 			name: "AuthRegister",
-			args: []string{"https://github.com/platkrm/test-blueprints.git", "--repo-username=test-username", "--repo-password=test-password"},
+			args: []string{"https://github.com/platkrm/test-blueprints.git", "--repo-basic-username=test-username", "--repo-basic-password=test-password"},
 			actions: []httpAction{
 				{
 					method:       http.MethodPost,