That view of things has a lot of gRPC cruft in it that for the most part you won’t be concerned with. To help show you what the conceptual structure of the Tiller object model really is, I put together a UML class view of the main object model exposed by Tiller, eliminating the gRPC methods you’re not likely to use:
So fundamentally in the Helm/Tiller ecosystem, you’re working with charts, that, when installed, result in releases. In the gRPC-generated object model, a Chart has a Metadata, several files, many values, and many Templates.
Each of these objects represents one of the items in the Helm chart file structure. But, obviously, because with microbean-helm these are Java objects you can create them from any source you like.
Of note here is the use of
Any for non-template files (like
NOTES.txt). While there are apparently lots of different ways to use this general purpose class, the Helm ecosystem appears to encode a chart file’s simple relative filename as the return value of its
getTypeUrl() method, and its textual content as the return value of its
getData() method. It’s not entirely clear whether Helm and Tiller got this right, but that is currently the behavior, so there you go.
It strikes me that, fuzzily, there are interesting opportunities here that involve microbean-helm, fabric8’s DefaultKubernetesClient, fabric8’s DockerClient, and so on to create Tiller-compatible charts but using plain Java.