I’ve created a UML class diagram to help me decipher the main structures in the Go code of Helm around chart repositories and their related concepts:
For the most part I stayed true to UML notation. Similarly-colored boxes are from the same source files:
pkg/repo/repo.go
: a source file dealing withRepoFile
structures.pkg/repo/chartrepo.go
: a source file dealing withChartRepository
andEntry
structures.pkg/repo/index.go
: a source file dealing withChartVersion
andIndexFile
structures.
A few interesting things stand out here.
First, from a conceptual standpoint, a ChartRepository
is basically a glorified wrapper around an IndexFile
, which is, in turn, a glorified wrapper around a set of ChartVersion
s. A ChartVersion
, in turn, is also a Metadata
, which is a gRPC/Protocol Buffers object you’ve seen before (I didn’t indicate that relationship here on this diagram, but probably should have). ChartVersion
s are stored (well, should be stored) within their containing IndexFile
sorted by their version. Go maybe doesn’t have the same concept as Java’s sorted collections and Comparator
s, so there’s some additional sorting logic that really you don’t need in the IndexFile
concept.
ChartRepository
instances are notionally “stored” in a RepoFile
, but really what the RepoFile
stores is a “pointer” to a ChartRepository
—a primary key, of sorts—called, confusingly, an Entry
. More confusingly, a ChartRepository
refers to its identifying Entry
as its Config
! But if you think of an Entry
as a primary key of a ChartRepository
you should do OK. A RepoFile
is basically a pile of Entry instances, so, again, notionally, a collection of ChartRepository
pointers. (There is some question about why this data structure permits duplicate Entry
instances (i.e. with the same Name
but different contents); see Helm issue #2606 for details.)
I’m in the process of translating this to Java, and I think the resulting object model is going to look a lot cleaner, while delivering the same functionality, and permitting alternate implementations of chart storage and discovery. Stay tuned.
One thought on “Helm from Java, Part 4”
Comments are closed.