Does operator v5 support jsonnet/libraries? #1292
Comments
|
Ok, I tried with gzip & jPath to jsonnet: |-
local thm = import '/vendor/rhowe-grafonnet/thm.libsonnet';but it cause a bug in fetcher: INTERNAL ERROR: (CRASH) runtime error: invalid memory address or nil pointer dereference
upd: Looks like for jsonnet there is only embed fs importer T_T |
|
I found a bit hacky workaround, because it uses security issue here (you can leave unpacked-sandbox directory): you could mount configmap with libsonnet with k8s mounts and then use jsonnetLib:
jPath:
- ./../../../vendorsomething like this to get access to the mounted files.. |
|
@vchirikov v5 currently only supports the main Grafonnet library (which is bundled). No external libraries are supported. @HubertStefanski is that still correct? |
|
we should remove |
|
Isn't this what you are looking for @vchirikov https://grafana-operator.github.io/grafana-operator/docs/dashboards/#providing-runtime-to-build-jsonnet-dashboards ? |
|
It's close, but to use THE SAME library in 100 dashboards I need to create 100 tar.gz with THE SAME library. I want to reuse the libsonnet code. For now I can reuse it only with hacky workaround. I think it will be nice to provide a way to add libsonnet code without duplicating it inside archives, e.g. add the real FS importer in jsonnet fetcher (now it's |
|
So none of the maintainers use or know jsonnet (this might change soon), but we have relied a lot on the community and its feedback when it comes to jsonnet implementations. So I will do that once again. |
|
@vchirikov if you have an idea on how this could be solved, we would also love to see a PR around it. Preferably not a breaking change, but if it's needed we can do that as well as long as we can get feedback from multiple jsonnet users. |
|
@pb82 @HubertStefanski is there a clear status on the jsonnet library support ? I'm also trying to migrate from v4 and I was using libraryLabelSelector to reference custom jsonnet libraries I've developped. |
|
not sure how this worked in v4, but how about introducing two new custom resources for cluster- and namespace-scoped jsonnet libraries and allow them to be referenced in the existing GrafanaDashboard resources? A example could look like this: apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDashboard
metadata:
name: grafanadashboard-jsonnet
spec:
jsonnetLibaries:
- name: namespaced-lib
kind: JsonnetLibrary
- name: cluster-scoped-lib
kind: ClusterJsonnetLibrary
jsonnet: |
local grafana = import 'grafonnet/grafana.libsonnet';
local namespaced = import 'namespaced-lib';
local cluster = import 'cluster-scoped-lib';
...The individual jsonnet library resources could use the existing tar.gz based approach but would allow re-use of of those blobs across multiple dashboards. |
|
This issue hasn't been updated for a while, marking as stale, please respond within the next 7 days to remove this label |
|
would still love to have this |
|
If anyone can come up with a design document that describes how you want this to work, it would be great. |
|
This issue hasn't been updated for a while, marking as stale, please respond within the next 7 days to remove this label |
Hi guys, I'm working on migration from v4 to v5 and it's time to figure out how to work with libsonnet library. I use
rhowe-grafonnetfork and want to provide their version of grafonnet to generate dashboards.I saw awesome work of @olejeglejeg with external libs, but I want to reuse libsonnet code over multiple dashboards, so I think it's not a good solution to tar.gz all dashboards with same dependency multiple times (instead of reuse them).
I found on API Reference that LibraryLabelSelector is still there, but I didn't find any examples of this in v5.
Does it work in v5?
If it's not I'm ok with mounting config map into operator's fs, like:
but in current api spec of grafana dashboard I can't use
jPathwithout gzip :( As a workaround I can try to gzip only the dashboard itself and providejPathas/vendor, but it will be great to have an option to use jPath without gzip. What do you think?The text was updated successfully, but these errors were encountered: