elastic-package export search

[ltflb-bgdi]

While it is possible to export dashboards with elastic-package export dashboards and make them editable by elastic-package edit dashboards it is not possible to do that for saved searches.

As a workaround I have created a dashboard with references to all required searches. This works but leads to the following problems:

• elastic-package lint fails since it does not like dashboards with references (for what reasons I don't know since referencing objects in dashboards is a supported feature and works if done in kibana gui) - SVR00004
• Once exported and added to the package, they can not be edited anymore, since the corresponding elastic-package command is missing.

Adding support for exporting and editing searches would greatly simplify the management of searches.
Ideally the command would be like this elastic-package export|edit search.

Or even elastic-package export|edit saved_object for any kind of saved objects.

[jsoriano]

Hey @ltflb-bgdi, thanks for opening this feature request.

What is your use case for it?

There are many kinds of Kibana objects that we could support in elastic-package. In principle we only have first-level support for dashboards because we consider them as the minimum usable component in the context of packages. Any other visualization is referenced from a dashboard and then can be exported or edited as part of the dashboard.
This premise could change though if there are valid use cases for other objects.

what reasons I don't know since referencing objects in dashboards is a supported feature and works if done in kibana gui

The reasons to prefer dashboards that contain panels by value and not by reference can be found in the original request in elastic/package-spec#316. They are mainly faster installation times, and avoid bloating the visualizations search UI.

Also we found out that there were little benefits on keeping visualizations per value, as they were hardly ever reused.

We keep though the escape hatch of allowing to disable this linting rule, by adding the SVR00004 code to the validation.yml file, as is done in some packages: https://github.com/search?q=repo%3Aelastic%2Fintegrations%20SVR00004&type=code

[ltflb-bgdi]

Hey @jsoriano, thanks for your response.

The use case is to provide predefined, managed, non-editable searches for each of the data-streams of our custom integration-package. The same way dashboards can be managed. Without this feature, the default searches could be accidently saved, e.g. after a debugging session.

Thanks for clarification on the referenced object. This makes absolutely sense. But still, as mentioned in elastic/package-spec#316, not all assets can be added as references, i.e. searches can only added as reference IMO. As far as I understand the spec, reference errors and warnings should only be thrown by using lens and visualizations, not on other assets like data-views and searches.
Please note that we only use referenced objects to workaround the missing elastic-package support. Once searches could be exported, we would not have to reference the searches anymore.

Thanks for the hint to the escape hatch. I am already using it in the meantime and elastic-package check works properly.

[jsoriano]

The use case is to provide predefined, managed, non-editable searches for each of the data-streams of our custom integration-package. The same way dashboards can be managed. Without this feature, the default searches could be accidently saved, e.g. after a debugging session.

Yeah, this can be a good idea in some cases. I guess you are using these searches in the Discover view?

Thanks for clarification on the referenced object. This makes absolutely sense. But still, as mentioned in elastic/package-spec#316, not all assets can be added as references, i.e. searches can only added as reference IMO.

In principle searches can be used by value since 8.10 (elastic/kibana#148995). Though maybe we should then skip this validation for packages supporting older versions.