add proposal for GrafanaLibraryPanel CRD #1611
Conversation
diurnalist
requested review from
NissesSenap,
weisdd,
ishanjainn,
theSuess,
hubeadmin and
pb82
as code owners
There was a problem hiding this comment.
Really nice feature to get, thanks for the initial design.
Personally I think it would be interesting to discuss how the dashboard would reference lib panels. I think it would be reasonable to do it in a similar way as we do here: #1604
Just because we talk about the design, doesn't mean that we have to have this feature to be a part of the initial implementation, but it might have an impact on how we make the implementation.
How do you feel about it?
|
This PR hasn't been updated for a while, marking as stale |
|
Can we have this re-opened? This seems like a good thing to have. |
|
This PR hasn't been updated for a while, marking as stale |
|
Any chance this gets merged, so people can start to work on it? |
|
@applike-ss i feel that we need more details in - the suggestion as I asked for in my above comment. But I haven't gotten any reply from @diurnalist . If you are up for it to clarify the document I would love to see a new PR around this design. |
|
hey - I'm still interested in getting this done since we already have most of the code in our fork. I haven't had as much time to focus on it b/c my priorities have moved on to other things at $JOB and the operator fork we have is working fine. i might have some cycles this weekend and could donate some to finishing the proposal to address the above questions. |
diurnalist
force-pushed
the
f/library-panels
branch
from
1aced81 to
e887a99
Compare
|
@NissesSenap, all, I have updated the proposal to include two ways to reference panels from w/in dashboards. One way, via static UID, is more friendly if the model is that end-users pick and choose from library panels in the UI and then export for persistence to code. The other way, dynamic reference, allows for administrators to provision library panels and dashboards in concert w/ one another and have them be linked up correctly, similar to how the Datasource mapping features work right now. This would also provide a mechanism to understand dependencies between dashboards and library panels in the Operator. |
| "id": 2, | ||
| "libraryPanel": { | ||
| "uid": "${LP_GRPC_SERVER_SUCCESS_RATE}", | ||
| "name": "gRPC Server Success Rate" |
There was a problem hiding this comment.
tbh I am not sure what this .name field is even used for. It could possibly also be dynamically injected, and we could have this just be "libraryPanel": "${LP_GRPC_SERVER_SUCCESS_RATE}", but that might be a bit too surprising of an interface.
There was a problem hiding this comment.
I tested importing this with an arbitrary value, and it seems to work, so I guess we can just ignore that field
this adds a proposal for a GrafanaLibraryPanel CRD, which would enable the operator to manage Library Panels similar to other assets. the Library Panel behaves similar as a Dashboard; it has a JSON model and can optionally be associated to a Folder.
full disclosure: we actually have a patch that we are using in production that implements the proposal documented here. We don't have chainsaw tests for it though; I think that would be one possible next step. still, open to discussion about the approach. we opted to implement this with high parity with how Dashboards worked because we reasoned folks might want to manage the JSON models for both in similar ways, be that as config maps, or nested on the CR itself, or external URL.