I’ve amended my prior class diagram to reflect the fact that
ChartVersion “is a”
Metadata is a generated structure—part of the Tiller API—that represents an actual Helm
Why is this important? Because now you can see the concepts: an
IndexFile is basically a collection of all the
Chart.yamls conceptually held (usually in gzip archives) by a
ChartRepository. And a
ChartRepository is really not much more than an
IndexFile. This whole structure can be greatly simplified.
The way I see it, the fact that this notional collection of
Chart.yamls is a file is incidental, and hence
IndexFile is a very poor name indeed. Structurally, all it is is a collection of things. We can also tell that because of the
Get() function signature, an item in that collection is uniquely identified (or at least should be!) by a name and a version. This means that this notional collection of
Chart.yamls is a set (and not, say, a list, or some sort of other collection type that permits duplicates).
Next, we can tell from the
Add() function that really what you’re doing with this function is creating a new
ChartVersion structure and adding it. That furthers our suspicion that really what we’re dealing with here is some sort of collection type of
ChartVersions, and nothing else.
If represented in Java, it really doesn’t need to be any more complicated than a
Map. In this case, it is a
ChartVersions (and hence
Metadata instances) indexed by a key consisting of name and version. So a
ChartRepository too is really not much more than this
Map located somewhere else, together with the information needed to talk to it.
ChartVersion is also a poor name. Something like
ChartDescriptor is probably better: the fact that a
Version attribute happens to be one of the things it logically contains doesn’t—it seems to me—elevate it to primacy here. What this thing is is really a full description of the state of a Helm chart (the
Metadata aspect of its nature) and some information about where you can find the real thing (the
URLs attribute of its
So instead of an
IndexFile having many
ChartVersions that it calls its
Entries (?!), in Java I propose a
Map (probably a
ChartDescriptors indexed by
ChartDescriptorKey instances. Obviously you can create one of these from an
index.yaml file from a chart repository—but just as importantly you could create it from something else.