Proposal to converge helm repositories with docker registries

proposals/helm-repo-container-registry-convergence/001-repo-registry.md

@@ -0,0 +1,33 @@
+# Proposal 1 - Container Registries provide Helm Repositories
+
+As Helm Charts are designed around the intention of deploying images, it's a natural evolution to store Helm Charts in registries, alongside the images they reference. 
+
+As Helm is evolving as the defacto deployment technology, it's believed it's time to evolve registries to support additional artifacts, such as Helm Charts.
+
+
+For registries to support Helm Charts, a few changes are proposed
+1. [Helm Charts align with registry repositories](./002-chart-registry-repo.md)  
+  enabling fully qualified charts
+1. [Helm Charts use registry authentication](./003-chart-authentication.md)  
+1. [Helm Chart Versions merge with docker tags](./006-helm-version-tags.md)   
+    With all the good and evil of "latest" and "stable" tags and versions.
+1. [Local Helm Store becomes a cache](./007-helm-store-cache.md)  
+  aligning more with docker run, intermittently does pulls, avoiding the need to continually call `helm repo add`
+1. [`helm search` becomes a server side query](./008-helm-search-server-query.md)  
+  Further converging the local Helm store as a remote cache
+
+
+## Converging with Registries
+While docker provides a baseline reference implementation through [docker distribution](https://github.com/docker/distribution), cloud providers of registries have had to fill in specifics for high scale/concurrent delivery. 
+
+Delivering images at cloud scale requires a number of enhancements including:
+- indexing
+- caching
+- authentication
+- versioning
+
+The evolution and implementation required to deliver Image Manifests and images at cloud scale are a super-set of the needs to deliver charts at cloud scale. 
+
+## Upstream Support to Docker Distribution 
+
+Proposal to commit upstream changes to [docker distribution](https://github.com/docker/distribution) to enable all implementors of the upstream project to easily adopt Helm Repositories. 

proposals/helm-repo-container-registry-convergence/002-chart-registry-repo.md

@@ -0,0 +1,23 @@
+## Helm Charts Align With Registry Repositories
+Container images are referneced with a multi-part URL:
+
+- [**login url**] / [**namespace**] / [**repo**] : [**tag**]
+- [**namespace**] / [**repo**] : [**tag** ] are equally referred to as an "image"
+
+Different clouds implement the unique login url in a few different forms, while effectively meaning the same thing:
+
+| Cloud | Format | eg: image |
+|-----|-----|-----|
+| Docker Hub | [**org**\|**user** ] / [**image**] : [**tag**] **\*1**| [contoso/marketing-fall2018-web:aab1]() |
+| Azure Container Registry (acr) | [**uniqueId**].azurecr.io / [**namespace**] / [**image**] : [**tag**] | contoso.azurecr.io/marketing/fall2018/web:aab1 |
+| Google Container Registry (gcr) | gcr.io/[**uniqueId**] / [**image**] : [**tag**] | gcr.io/marketing/fall2018-web:aab1 |
+| AWS Container Registry (ecr) | [**aws_account_id**].dkr.ecr.region.amazonaws.com/ [**image**] : [**tag**] | 123abc456def.dkr.ecr.region.amazonaws.com/marketing/fall2018-web:aab1 |
+
+1. Docker Hub has a default login url [docker.io]()
+1. Docker Hub [**org**\|**user** ] is a [**namespace**] which is currently limted to two nodes.  
+  *The [Microsoft Container Registry (mcr)](mcr.microsoft.com) has implemented a syndicated catalog representing a product hierarchy within the docker store, and looks for Docker to expand this for other partners with deep image catalogs.*
+
+## Helm References
+
+Proposal aligns Helm Charts with the same referencing scheme:
+- [**login url**] / [**namespace**] / [**chart**] : [**version/tag**]

proposals/helm-repo-container-registry-convergence/003-chart-authentication.md

@@ -0,0 +1,31 @@
+# Helm Charts Use Registry Authentication
+
+Enabling a registry to assign a user/group/service account access to one or more chart and image repositories
+
+Client authentication is cached, similar to docker credentials, but doesn't depend on docker locally installed
+
+## Helm CLI Integrated
+Different cloud providers have different methods of authentication. However, this creates a disjointed experience requiring the user to use the clouds CLI and tool CLI. 
+The proposed goal here is to enable a common authentication model that doesn't require additional plug-ins.
+
+It's intended to support a common API on Helm Chart repositories to support:
+
+- Basic Auth
+- Token Auth
+- Cert Based Auth
+- 2 Factor Auth
+
+### Proposed Experience
+To create a Helm native experience, we're proposing:
+```sh
+# basic auth
+helm login [registryURL] -u $USER -p $PASSWORD
+# token
+helm login [registryURL] --token $TOKEN 
+# cert
+helm login [registryURL] --cert --certPath $OPTIONAL_CERT_PATH
+```
+Example:
+```sh
+helm login demo42.azurecr.io -u -p 
+```

proposals/helm-repo-container-registry-convergence/005-helm-fetch-url.md

@@ -0,0 +1,21 @@
+# `helm update` & `helm install` support remote urls
+
+Deploying a helm chart from a remote URL is supported today, however the repo must be specified as a parameter.
+```sh
+helm upgrade \
+    --repo=https://demo42.azurecr.io/base-charts/team-charts \
+    myrelease \
+    chartmuseum
+```
+This proposal suggests charts can be fully referenced:
+
+```sh
+helm upgrade myrelease demo42.azurecr.io/base-charts/team-charts/chartmuseum
+```
+
+Helm Charts do not need to be fully qualified
+Just as docker images don't need to be fully qualified to be used, a helm chart wouldn't require this either.
+
+A user can build a chart locally, refer to it as chartmusueum, and deploy it. 
+
+To push the chart, it would be "tagged", in docker terms to prepend the registry login url.

proposals/helm-repo-container-registry-convergence/006-helm-version-tags.md

@@ -0,0 +1,21 @@
+# Proposal 6 Helm Chart Versions merge with docker tags
+
+2.0 Helm Charts use semantic versioning. Semantic versioning is far more predictable and structured then docker tags. 
+
+Proposal:
+
+1. [Maintain semantic versioning](#proposal-8-1)
+2. Align with : notation to differentiate domains (.), namespaces (/) and file name extensions. 
+3. Maintain "latest" concept, which also aligns with the docker manifest concept to have two tags equate tot the same chart.
+### 1 Maintain Semantic Versioning <a id="proposal-8-1"></a>
+To avoid the open form, difficult to parse docker tagging format, semantic versioning will continue to be supported. 
+However, similar to stable tags, including :latest, helm charts would provide versioned, stable releases.
+Helm Charts would leverage manifests that enable two or more "versions" to reference the same chart.
+
+- `helm pull demo42.azrecr.io/base-charts/team-charts/chartmuseum:1.2.1`
+- `helm update myDeployment demo42.azrecr.io/base-charts/team-charts/chartmuseum:1.2.1`
+
+
+
+
+

proposals/helm-repo-container-registry-convergence/007-helm-store-cache.md

@@ -0,0 +1,14 @@
+# Proposal 7 - Helm Chart Cache
+To support multiple registries, with nested repositories, a folder cache, with matching hierarchy is proposed:
+`demo42.azrecr.io/base-charts/team-charts/chartmuseum:1.2.1` would be represented on disk as:
+
+```
+└── demo42.azrecr.io
+    └── base-charts
+        └── team-charts
+            └── chartmuseum
+                └── 1.2.1
+```
+### Helm Chart Cache
+
+The helm chart store is typically a local store. To pull a public chart, make changes, then push the chart to a private helm repository, the local store can get out of sync.

proposals/helm-repo-container-registry-convergence/readme.md

@@ -0,0 +1,57 @@
+# Helm Repo and Container Registry Convergence Proposal
+
+As Helm Charts become the way customers deploy and update multi-image deployments to Kubernetes, which references images stored in a registry, theirs an opportunity to align Helm concepts with registry concepts. 
+
+This proposal suggests aligning some of the commands and chart references to align more consistently with a container registry. 
+
+The proposal doesn't suggest changes in how charts are deployed, rather the storage and referencing of Helm charts.
+
+The proposal covers the following:
+
+1. [Container Registries are collections of Helm Repositories](./001-repo-registry.md)  
+  Evolution of [Docker Distribution](https://github.com/docker/distribution) to support Helm Repositories
+2. [Helm Charts Align With Registry Repositories](./002-chart-registry-repo.md)  
+    Consistent with an image repository, a chart repository is a specific chart, with unique tags representing a versioned history  
+3. [Helm Charts use registry authentication](./003-chart-authentication.md)  
+4. [`helm fetch` becomes `helm pull`](./004-helm-fetch-pull.md)  
+  aligning the commands more consistently
+5. [`helm update` & `helm install` support remote urls](./005-helm-fetch-url.md)  
+  Without having to set a `--repo` parameter
+6. [Helm Chart Versions merge with docker tags](./006-helm-version-tags.md)   
+    With all the good and evil of "latest" and "stable" tags and versions.
+7. [Local Helm Store becomes a cache](./007-helm-store-cache.md)  
+  aligning more with docker run, intermittently does pulls, avoiding the need to continually call `helm repo add`
+8. [`helm search` becomes a server side query](./008-helm-search-server-query.md)  
+  Further converging the local Helm store as a remote cache
+
+## Background
+Helm Charts evolved as a means to streamline and empower deployment of Kubernetes templates. Chart Museum evolved Helm Charts to provide a storage means for Charts. To maximize the ease for server side support, Chart Museum supported minimal storage requirements. Chart Museum can be stored directly in an S3 storage account. As cloud providers implement Helm Repositories, each are facing the same challenges providing charts at cloud-scale. 
+
+## Why Unify?
+
+To be massively successful, Helm and Helm Repositories should appeal and be easily adopted by the masses. Docker has done a great job providing a progressive disclosure of complexity to the user, with a set of commands that most can grok.
+
+The more things are different, the more difficult it is for users to adopt. Helm, Repositories even Kubernetes are the underlying infrastructure we hope all will use. But, we need to leave room for mental processing of concepts to all the other things developers and operational users need to account for.
+
+By converging some of the underlying implementations, along with the commands, we can simplify the number of things users need to remember.
+
+- `helm fetch` vs. 
+`docker pull`
+- A **Helm Repo** is a collection of charts
+- A **Helm Chart** has a collection of versions
+- A **container repo** is a **single image**, with a **collection of versions** (tags)
+- `docker run` will implicitly issue `docker pull` if the image doesn't exist
+- `helm upgrade` requires a `helm fetch` first, or a `--repo` parameter that is different than a image
+
+
+## Why should Helm change, when "it's better"?
+
+We can certainly make the argument that several of the helm concepts, such as semantic versioning is far better than the open field of tags. And, some of those concepts are preserved, while still aligned with tags. However, Docker has a large installed base, which is only growing. Attempting to either change docker, or insist the changes are justified only increases friction to adoption. 
+
+## Involved Participants
+
+As the goal is broad adoption, we are proposing this proposal be supported by all major clouds ([Azure](www.azure.com), [Google Cloud](https://cloud.google.com/) & [AWS](https://aws.amazon.com)) as well as container vendors, such as [Docker](https://www.docker.com), [Codefresh](https://codefresh.io), [JFrog](https://jfrog.com) and others...
+
+## Proposed Timeline
+
+Helm 3.0 is entering final design phases. Given the growth and quick adoption, with the significance of changes, it's proposed these changes are incorporated into Helm 3.0.