Update Kustomization integration KEP

keps/sig-cli/0008-kustomize.md

@@ -13,14 +13,14 @@ approvers:
   - "@soltysh"
 editor: "@droot"
 creation-date: 2018-05-05
-last-updated: 2018-05-23
+last-updated: 2019-01-09
 status: implemented
 see-also:
   - n/a
 replaces:
   - kinflate # Old name for kustomize
 superseded-by:
-  - n/a
+  - "kustomize-subbcommand-integration.md"
 ---
 
 # Kustomize

keps/sig-cli/kep-faq.md

@@ -0,0 +1,23 @@
+# SIG CLI KEP FAQ
+
+## Why not as a kubectl plugin instead of compiled in?
+
+- The kubectl plugin mechanism does not provide a solution for distribution.  Because the functionality is intended as
+ the project's solution to issues within kubectl, we want it to be available to users of kubectl without additional
+ steps.  Having users manually download only Kustomize as a plugin might be ok, but it won't scale as a good approach
+ as the set of commands grows.
+- The effort to build and test the tool for all targets, develop a release process, etc. would be much higher for SIG
+  CLI, also, and it would exacerbate kubectl's version-skew challenges.
+- It will not support integration at more than a surface level - such as into the resource builder
+  (which does not offer a plugin mechanism).
+    - It was previously decided we didn't want to add a plugin mechanism to the resource builder.
+      This could be reconsidered, but would need to think through it more and figure out how to address
+      previously brought up issues.  There may be other issues not listed here as well.
+      - https://github.com/kubernetes/kubernetes/issues/13241
+      - https://github.com/kubernetes/kubernetes/pull/14993
+      - https://github.com/kubernetes/kubernetes/pull/14918
+- There is a risk that publishing each command as a separately built binary could cause the aggregate download
+  size of the toolset to balloon.  The kubectl binary is *52M* and the kustomize binary is *31M*.  (extrapolate to
+  30+ commands x 30MB).  Before going down this route, we should consider how to we might want to design a solution
+  and the tradeoffs.  
+

keps/sig-cli/kustomize-file-processing-integration.md

@@ -0,0 +1,101 @@
+---
+title: Integrate Kustomize into cli-runtime
+authors:
+ - "@pwittrock"
+owning-sig: sig-cli
+participating-sigs:
+ - sig-cli
+reviewers:
+ - "@liggitt"
+ - "@seans3"
+ - "@soltysh"
+ - "@monopole"
+approvers:
+ - "@liggitt"
+ - "@seans3"
+ - "@soltysh"
+ - "@monopole"
+editors:
+ - "@pwittrock"
+creation-date: 2019-01-17
+last-updated: 2019-01-17
+status: provisional
+see-also:
+ - "kustomize-subcommand-integration.md"
+replaces:
+superseded-by:
+ - n/a
+---
+
+# Enable kustomize subcommand in kubectl
+
+## Table of Contents
+* [Table of Contents](#table-of-contents)
+* [Summary](#summary)
+* [Motivation](#motivation)
+  * [Goals](#goals)
+  * [Non-Goals](#non-goals)
+* [Proposal](#proposal)
+  * [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints)
+  * [Risks and Mitigations](#risks-and-mitigations)
+* [Graduation Criteria](#graduation-criteria)
+* [Implementation History](#implementation-history)
+* [Alternatives](#alternatives)
+
+[Tools for generating]: https://github.com/ekalinin/github-markdown-toc
+
+## Summary
+
+This is a follow up to [KEP Kustomize Subcommand Integration](kustomize-subcommand-integration.md)
+
+[Kustomize](https://github.com/kubernetes-sigs/kustomize) is a subcommand of kubectl.  However it is
+not tightly integrated into the file processing libraries, creating user friction around error
+handling and messaging.
+
+## Motivation
+
+- It is capable of removing friction that requires deeper integration - such as producing errors referencing line
+  numbers of the original files (rather than the output files) and providing the right error code if kustomization
+  fails.
+- It is more consistent with UX workflow with other commands and flags
+- It has a cleaner and simpler UX than pipes
+- It is clear which commands it should be used with - apply, get, delete, etc.
+
+### Goals
+
+- Provide a clean and integrated user experience when working with files from kubectl.
+- Provide consistent UX across kubectl commands for working with kustomized applications.
+
+### Non-Goals
+
+## Proposal
+
+Integrate kustomize directly into libraries that enable file processing for cli-runtime (e.g. resource builder).
+Kubectl commands taking the common flags (`-f`, `--filename`, `-R`, `--recursive`) will support `kustomization.yaml`
+files.
+
+Cli-runtime will add the flags `-k, --kustomize=[]`, which will be registered along side the other file processing
+flags.  If the `-k` flags are provided to a command, the experience will be similar to if the user had piped
+kustomize to stdin - e.g. `kubectl kustomize <value> | kubectl <command> -f -`.  It will differ in that it provides
+improved error handling and messaging.
+
+Example: `kubectl apply -k <dir-containing-kustomization>`
+
+Tools outside kubectl that use the cli-runtime to register file processing flags and build resources will get the
+`-k` by default, but can opt-out if they do not want the functionality.
+
+### Risks and Mitigations
+
+Low:
+
+When run against a kustomization.yaml with multiple bases, kubectl may perform multiple requests as part of the
+preprocessing.  Since `-k` is a separate flag from `-f`, it is transparent to a user whether they are running
+against a kustomization file or a directory of Resource Config.
+
+## Graduation Criteria
+
+NA
+
+## Implementation History
+
+## Alternatives