| hip | 9999 | |
|---|---|---|
| title | Introduce Alias Support for OCI Registries | |
| authors |
|
|
| created | 2022-07-08 | |
| type | feature | |
| status | draft |
Non-OCI chart repositories can be referenced via an alias string like @repo or alias:repo. By introducing support for OCI charts and therefore OCI registries in Helm this feature was not implemented. This HIP proposes the addition of this feature to provide feature parity with legacy chart repositories for OCI registries.
Aliasing can be used in various scenarios but the one that stands behind this HIP is the following. Such examples of more advanced use cases might hinder adoption of OCI charts.
Let's say your company is deploying various services using proprietary Helm charts. There are different deployment environments which are all independent and deployed in different data centers around the world and operated by the company itself. This means that every data center has its own registry and kubernetes cluster and so on. To make the deployment as easy as possible each Helm chart defines its dependencies using an alias for the registry. In each environment the alias is setup to point to the respective registry (e.g. using a tool like ArgoCD) so each chart can be deployed in each environment without changes.
This usecase is not possible with OCI charts right now. If said company would like to use OCI charts some workaround would need to be in place that changes the dependency definitions of each chart to point to the correct registry for the target environment.
The missing part for alias support for OCI registries is that they are currenty referenced by URI only and have no additional identifier like legacy chart repositories.
Therefore the command for adding registries helm registry login should be extended with an optional argument --alias to add a name to the specified registry. A complete example would look like this:
helm registry login oci.example.com --alias myregistryAs Helm is using an external library for handling authentication with an OCI registry it is not easy to add metadata to the authentication data saved in ~/.config/helm/registry/config.json. The proposed solution to this would be to create a separate file (e.g. ~/.config/helm/registry/aliases.json|.yaml) which includes mappings in the form of alias:repouri. For the example above it would have an entry like this (using yaml syntax):
myregistry: "oci://oci.example.com"These mappings need to be updated whenever helm registry login or helm registry logout is called.
As alias support is already in place for legacy repositories it should be relatively easy to add support for aliased OCI repositories at the same place using the mapping file.
Making the alias for OCI registries optional prioritizes backwards compatibility over being consistent with helm repo add which requires a name. By using an additional mapping file for the aliases no changes should be required to the existing authentication flow for OCI registries.
Since the added command argument should be optional there should be no breaking change to any functionality.
None
Aliases are already well known and documented. The documentation of handling OCI registries should be extended to include a hint that aliases are also supported. The documentation of helm registry login should include the new optional argument and state where aliases are stored.
None