Closed aboulay-numspot closed 2 months ago
Outcome from discussing this in our weekly:
we want to only add folderUid
and folderRef
fields. The createFolder
fields is implicitly defined through the presence of the new fields. This means:
folder
is set and none of the other fields is set (backwards compat. case): Create the folderfolderUID
or folderRef
is set, don't create the folderfolderUID
or folderRef
AND folder
is set, the new fields take priority -> don't create the folderWill clean up the proposal and we can further discuss this async
Outcome from discussing this in our weekly:
we want to only add
folderUid
andfolderRef
fields. ThecreateFolder
fields is implicitly defined through the presence of the new fields. This means:
- If
folder
is set and none of the other fields is set (backwards compat. case): Create the folder- If
folderUID
orfolderRef
is set, don't create the folder- If
folderUID
orfolderRef
ANDfolder
is set, the new fields take priority -> don't create the folderWill clean up the proposal and we can further discuss this async
@theSuess Normally, this should be fine now. I let you review a last time the document. :)
Aim of the merge request:
This MR aims to create a document to propose an evolution on the folder management related to the parent folder.
The suggested new features are:
folderRef
field to target a folder deployed thanks to the GrafanaFolder CR.folderUID
field to target an existing folder in Grafana.createFolder
(default: true for retrocompatibility). This field cannot be false iffolderUID
andfolderRef
are not set in the GrafanaDashboard manifest.Breaking change
There is no breaking change because it is just a proposal document. Nothing is implemented yet.
This should be discussed during a maintainer meeting.