Open derrickburns opened 3 years ago
I guess my first question is do both those functions rely on any external CLI utilities. If they don't then I absolutely will include them, or something similar.
To your first question, I was trying to think of interesting ways a user could define additional functions at runtime. In my head at the time it didn't seem like it'd be worth the effort since the writer of the jsonnet can easily define the functions they need. That being said, having the ability to declare functions globally via another CRD or something could be interesting.
I looked at the code. The helm native func does make CLI calls.
And so does the kustomize native func. :(
However, I wonder if those are necessary. I believe that there is a Helm Go API.
Yea I have other projects where I've (at least with helm) invoked the needfuls via the Go API. But ya, we'd have to implement them into the controller. I'm trying to avoid embedding binaries - currently leaning on controller-runtime server-side apply for syncing state instead of using kubectl
.
I may take a stab at, at least, helm functionality later today or tomorrow
Awesome!
Sent from my iPhone
On Aug 8, 2021, at 6:55 AM, Avi Zimmerman @.***> wrote:
I may take a stab at, at least, helm functionality later today or tomorrow
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
I have a new feature on the latest
tag (when this run is done) for you to at least start playing with if you want. But I make no guarantees to its stability. I tried to mimic the tanka
example as close as possible (with a few omissions that are not available directly in the helm Go API without some hacking).
Simplest example is here:
local utils = import 'internal://utils.libsonnet';
{
chart: utils.helmTemplate('example', './chart', {
values: { replicaCount: 2 },
})
}
You can see the schema for the final opts
argument here. One important note is I skipped the calledFrom
construct for now. It's there in the options, but ignored. The path you give is assumed relative to where you are executing the jsonnet for now. In the controller that's the path you define in the CR.
To make testing a little easier I added to the konfig
CLI. There was already the build
command which did a server-side dry-run of a Konfiguration
. I added a simple (rather dumb for now, but can be expanded) show
command that behaves similarly to kubecfg
and regular jsonnet
. Just pass it a jsonnet file or path and it will run it through the same interpreter the controller uses.
It doesn't get released without a tag, so you'd have to build manually for now to get that command. If you have go installed you can run make build-konfig
in this repository and it will be installed to ~/go/bin/konfig
.
Any feedback is appreciated if you are able to give it a try 😄
Very nice!
Tanka now has support for helm templating and kustomize templating by way of new native functions. While helm and kustomize are supported by fluxcd, the inclusion of these in tanka means that transformations using jsonnet can be applied to the output of helm and/or kustomize. This is a win, particularly for helm, since helm is not composable.
Is there a way to configure the native functions at run time? If so, then one could leverage these.
Alternatively, could you add these particular native functions to your jsonnet interpreter?