Allow to export and edit dashboards from Serverless environments#3007
Allow to export and edit dashboards from Serverless environments#3007mrodm merged 23 commits intoelastic:mainfrom
Conversation
| // These fields are not expected to be part of responses from APIs | ||
| DataStream string `json:"-"` | ||
| SourcePath string `json:"-"` |
There was a problem hiding this comment.
I could not find any usage of these two fields in APIs.
It looks like that they are used in test asset and they are filled programmatically.
elastic-package/internal/packages/assets.go
Line 139 in fc03bdf
elastic-package/internal/packages/assets.go
Line 171 in fc03bdf
elastic-package/internal/packages/assets.go
Line 207 in fc03bdf
If the json:"-" tag is not added to the fields, queries with this struct fail with the error of those fields being not available/undefined.
internal/kibana/dashboards.go
Outdated
| func (c *Client) exportAllDashboards(ctx context.Context) ([]common.MapStr, error) { | ||
| logger.Debug("Export dashboards using the Kibana Saved Objects Export API") | ||
|
|
||
| request := ExportSavedObjectsRequest{ | ||
| ExcludeExportDetails: true, | ||
| IncludeReferencesDeep: false, | ||
| Type: "dashboard", | ||
| } | ||
|
|
||
| return c.ExportSavedObjects(ctx, request) | ||
| } |
There was a problem hiding this comment.
This method would return all the dashboards available in the Kibana Instance.
According to the documentation, the number of assets that will be exported depend on savedObjects.maxImportExportSize setting (link):
NOTE: The savedObjects.maxImportExportSize configuration setting limits the number of saved objects which may be exported.
By default that setting is 10000 elements (savedObjects.maxImportExportSize setting):
The maximum count of saved objects that can be imported or exported. This setting exists to prevent the Kibana server from running out of memory when handling large numbers of saved objects. It is recommended to only raise this setting if you are confident your server can hold this many objects in memory. Default: 10000
|
/test |
| // Even if no error is returned, we need to check if the import was successful. | ||
| if !resp.Success { | ||
| return fmt.Errorf("importing %s %s was not successful", savedObjectType, id) | ||
| } | ||
|
|
There was a problem hiding this comment.
Added a new check to ensure that the saved object has been imported successfully:
https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-saved-objects-import
success: Indicates when the import was successfully completed. When set to false, some objects may not have been created.
| // Not mandatory to get the package name here, but it would be helpful for users | ||
| // to select by default the package where they are located if any. | ||
| defaultPackage := "" | ||
| packageRoot, err := packages.MustFindPackageRoot() | ||
| if err == nil { | ||
| m, err := packages.ReadPackageManifestFromPackageRoot(packageRoot) | ||
| if err != nil { | ||
| return fmt.Errorf("reading package manifest failed (path: %s): %w", packageRoot, err) | ||
| } | ||
| defaultPackage = m.Name | ||
| } |
There was a problem hiding this comment.
I think it could be helpful for the user to select the package where they are located if any. But this should not raise an error if the command does not run from a package.
|
test integrations |
|
Created or updated PR in integrations repository to test this version. Check elastic/integrations#15710 |
jsoriano
left a comment
There was a problem hiding this comment.
Nice, works great. Thanks!
Added some comments but mostly nitpicking and suggestions, so they could be ignored 🙂 so approving by now.
| dashboardTitle, ok := attributes["title"].(string) | ||
| if !ok { | ||
| return DashboardSavedObject{}, fmt.Errorf("dashboard object does not contain attributes.title field") | ||
| } |
There was a problem hiding this comment.
Nit. Maybe it would be easier to use unmarshal? Though for that exportAllData would need to return the raw responses.
Co-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>
Co-authored-by: Jaime Soriano Pastor <jaime.soriano@elastic.co>
💚 Build Succeeded
History
cc @mrodm |
Closes #2949
This PR allows to export dashboards in Serverless environments (
elastic-package export dashboardscommand).For Serverless environments, a new set of APIs from Elastic Package Manager have been used:
If this command is used in local stacks, the same behavior is kept. Given that, all dashboards are shown to select which ones to export.
Same changes are applied to the
elastic-package edit dashboardscommand.This new UX is also applied to Elastic stacks
>= 9.0.0.Author's checklist
elastic-package export dashboardsin Serverlesselastic-package export dashboardsin local stacks (same behavior).elastic-package edit dashboardsin Serverlesselastic-package edit dashboardsin local stacks (same behavior).Both commands require the same changes to list dashboards.
Example of usage
First step all installed packages are shown:
If the user selects a package, it will be shown all the dashboards related to that package (e.g. nginx):
If the user is developing a new dashboard (and therefore not related to any package), they should choose
New dashboardoption, and all the dashboards available in the Serverless instance will be shown:How to test this PR locally