Helm Dependencies: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 16: Line 16:
Helm does not automatically handle transitive dependencies, in the same manner as [[Maven]], for example, does: it is not possible to specify that chart "a" depends on chart "b", only specify the chart "b" "coordinates" (name, version and repository URL) and expect Helm to automatically pull "b" during the installation process. In this situation. Maven would contact the dependency's repository and pull the artifact. If that artifact had its own dependencies, specified by coordinates, Maven would recursively pull those as well, contacting as many repositories as necessary. This is known as what Maven friends refer to as "downloading the Internet".
Helm does not automatically handle transitive dependencies, in the same manner as [[Maven]], for example, does: it is not possible to specify that chart "a" depends on chart "b", only specify the chart "b" "coordinates" (name, version and repository URL) and expect Helm to automatically pull "b" during the installation process. In this situation. Maven would contact the dependency's repository and pull the artifact. If that artifact had its own dependencies, specified by coordinates, Maven would recursively pull those as well, contacting as many repositories as necessary. This is known as what Maven friends refer to as "downloading the Internet".


Help does not behave like that. It expects instead a chart to '''embed all dependencies it needs, recursively'''. This decision was probably taken because the chart metadata is really small, especially when compressed. and the chart transitive dependency graphs are not large, so embedding the whole graph in an archive is feasible, which would not be in Maven's case. Indeed, for a situation where an "a" chart depends on a "b" chart, and the "b" chart depends on a "c" chart, the structure of the "a"'s chart archive is;
Helm behaves differently. It expects instead a chart to '''embed all dependencies it needs, recursively'''. This decision was probably taken because the chart metadata is really small, especially when compressed. and the chart transitive dependency graphs are not large, so embedding the whole graph in an archive is feasible, which would not be in Maven's case. Indeed, for a situation where an "a" chart depends on a "b" chart, and the "b" chart depends on a "c" chart, the structure of the "a"'s chart archive is;
<syntaxhighlight lang='text'>
<syntaxhighlight lang='text'>
a
a

Revision as of 23:03, 15 December 2019

External

Internal

Overview


Revised for Helm 3


To Deplete

Helm Dependencies TODEPLETE

How Helm Dependencies Work

Helm does not automatically handle transitive dependencies, in the same manner as Maven, for example, does: it is not possible to specify that chart "a" depends on chart "b", only specify the chart "b" "coordinates" (name, version and repository URL) and expect Helm to automatically pull "b" during the installation process. In this situation. Maven would contact the dependency's repository and pull the artifact. If that artifact had its own dependencies, specified by coordinates, Maven would recursively pull those as well, contacting as many repositories as necessary. This is known as what Maven friends refer to as "downloading the Internet".

Helm behaves differently. It expects instead a chart to embed all dependencies it needs, recursively. This decision was probably taken because the chart metadata is really small, especially when compressed. and the chart transitive dependency graphs are not large, so embedding the whole graph in an archive is feasible, which would not be in Maven's case. Indeed, for a situation where an "a" chart depends on a "b" chart, and the "b" chart depends on a "c" chart, the structure of the "a"'s chart archive is;

a
├── Chart.yaml
├── charts
│   └── b
│       ├── Chart.yaml
│       ├── charts
│       │   └── c
│       │       ├── Chart.yaml
│       │       ├── templates
│       │       │   └── pod.yaml
│       │       └── values.yaml
│       ├── templates
│       │   └── pod.yaml
│       └── values.yaml
├── templates
│   └── pod.yaml
└── values.yaml



. Intermediate manual steps are required to install a chart that depends on other charts.

If we simply declare the chart "a" as dependent on chart "b" in the dependencies section of the "a"'s Chart and we attempt to install the chart "a", we get this:

Error: found in Chart.yaml, but missing in charts/ directory: b


What happens if a-1.0.0.zip is in a remote repository and does not have its dependencies in charts/?

Dependency Declaration

Dependencies are declared in Chart.yaml 'dependencies' section.

...
dependencies:
  - name: # The name of the dependency
    version: # The version of the dependency
    repository: # Repository URL
...

Example:

...
# 'a' Chart.yaml
dependencies:
  - name: b
    version: 1.0.0
    repository: # Repository URL
...

Packaging and Dependencies

Packaging and Dependencies

Dependencies and Values

Dependency Operations