-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify exporting dashboards for Devs #7730
Conversation
@@ -96,6 +98,27 @@ func Fields() error { | |||
return mage.GenerateFieldsYAML("module") | |||
} | |||
|
|||
func ExportDashboard() error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exported function ExportDashboard should have comment or be unexported
dev-tools/mage/dashboard.go
Outdated
"github.com/magefile/mage/sh" | ||
) | ||
|
||
func ExportDashboard(id, path string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exported function ExportDashboard should have comment or be unexported
@andrewkroh My first time creating a
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My approach so far has been to:
- Create
ExportDashboard(params ExportDashboardArgs)
in dev-tools/mage. - Create an
ExportDashboardArgs
struct with all the available parameters to control the behavior. - Provide a
DefaultExportDashboardArgs
that returns a ExportDashboardArgs object initialized with the defaults (including reading the env vars, seemage.EnvOr
). This it's still possible to override params programmatically if need be. - Update each magefile.go to use the new common method.
func ExportDashboards() error { return mage.ExportDashboards(mage.DefaultExportDashboardsArgs()) }
Unfortunately in this case I think there are no defaults. Do we have a way to make certain ENV variables required? Similar to EnvOr but EnvRequired? Do you add all magefile commands to the Makefile or would it be ok to have new commands only in mage? |
No, my goal is just to not break the existing Makefile targets and interface that people depend on. I think we can add mage targets and iterate on them.
Not at the moment. And I'm not sure we should. The underlying function that consumes the params would still need to validate them any way. So I'd opt for using |
f81d48c
to
fb4b20b
Compare
@andrewkroh Could you have a look again? |
dee35d3
to
20dcc51
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a compile issue, but besides that LGTM. This seems worthy of a note in the developer changelog.
dev-tools/mage/dashboard.go
Outdated
} | ||
|
||
// TODO: This is currently hardcoded for KB 6, we need to figure out what we do for KB 7 | ||
file := filepath.Join(beatsDir, BeatName, "module", module, "_meta/kibana/6/dashboard", id+".json") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this work with dashboards at locations like https://github.com/elastic/beats/tree/master/heartbeat/monitors/active/http/_meta/kibana/6/dashboard ?
Should those move to this new simpler pattern?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't at the moment. We should probably make the path a config param which each beat can set, so it also work here (follow up PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the output file you don’t want to use a path that is relative to the ElasticBeatsDir
because this won’t work for community beats or x-pack beats. Instead use CWD()
or just leave it as a relative path assuming the tool this is being passed to does the write thing and writes the output based on the CWD that it was executed from.
So in short, use file := CWD(“module”, module, “_meta/kibana/6/dashboard”, id+”.json”)
.
I think this is looking good. We should get it merged soon. |
9ff0847
to
9638612
Compare
Did rebase and quickly run it locally but exited with 1. Need to investigate what changed. |
9638612
to
879e807
Compare
A new `mage` command is introduced to simplify exporting dashboards and contributing them to Beats. Currently a contributor is required to know about folder hierarchy under which dashboards are stored and are versioned. To simply this a simple `mage` command is provided: ``` MODULE=mysql ID=the-dashboard-id mage ExportDashboard ``` The Dev must provide the module he wants to export the dashboard for and the dashboard id. The script will take care of extracting it from Kibana, creating directories and files. The current script only supports to export dashboards from localhost:5061 as no params are provided to change the host at the moment. Also this change is only for Metricbeat for now. Filebeat should also be added. Additional changes: * Create directories * Pass module and dashboard id * Add exit code 1 in case of export failure * Improve error handling
a44d482
to
f3cb335
Compare
@andrewkroh Should be ready for an other round of review. Tested now locally and works. |
@andrewkroh I tried to add it to x-pack filebeat and it the export worked. But it seems as BeatsDir it takes the one from the OSS Filebeat and puts the data there. I wonder if this is a general issue with the magefile? I suggest for now we skip this and get this in to then iterate on top of it. |
@ruflin I see the problem that would prevent you from using it in x-pack and left a comment on how to fix it. Should be a simple fix. |
If this is merged my PR needs an rebase: #9097 |
@andrewkroh I tried it with your adjustement in the code. It keeps working in OSS but for x-pack it still creates the data in OSS. I would prefer to rather get this PR in as is and get it improved in a follow up PR, especially as this conflicts with the work from @kvch . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with merging it in its current state. And then have it fixed for x-pack/*beat
in a follow-up PR.
@kvch Merged. You can rebase your PR on top of it now. In case you plan to backport your PR, should we backport this one too to 6.x? |
I think we can backport it along with the follow-up PR with the fix. But TBH I don't see as much value of this improvement on 6.x than on master. Devs would run it on master or on a branch from master, then backport the dashboards they have exported to 6.x. |
@kvch Ok, leave it up to you to decide if you will need this in 6.x or not. |
A new
mage
command is introduced to simplify exporting dashboards and contributing them to Beats. Currently a contributor is required to know about folder hierarchy under which dashboards are stored and are versioned. To simply this a simplemage
command is provided:The Dev must provide the module he wants to export the dashboard for and the dashboard id. The script will take care of extracting it from Kibana, creating directories and files. The current script only supports to export dashboards from localhost:5061 as no params are provided to change the host at the moment. Also this change is only for Metricbeat for now. Filebeat should also be added.
Additional changes: