-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Management Saved Objects overhaul #13329
Comments
Notes:
|
@tbragin - can you shed some light to why the edit object form exists and the role it currently provides? Dave and I assumed it was created due to limited editing capabilities in Dashboard, Visualize, and Discover but not sure if those reasons still exist. |
@tylersmalley It is meant as an advanced tool for examining and fixing object definitions. You are right that most of the times I've used it have been when something was not possible in another way. For instance, you might use it to update the index pattern or saved search on which a visualization is based, so you don't have to recreate it from scratch. Does that help? |
@epixa - when we built saved workspaces for Graph, I recall that you had originally requested that we not use the saved object infrastructure, because you felt like large parts of it would change - is this the change you were thinking about, or are there bigger changes in the works that we should be aware of? @uboness - also on Graph, I believe you had requested that we not allow exporting of saved Graph Workspaces, so we did some work to exclude them from the Saved Object Editor, but I can't recall why. Are you comfortable with adding the ability to export all saved object types? |
@skearns64 I believe it was because we actually didn't want to add any new functionality to this page at all. In fact we were planning to take all object CRUD operations out of the general settings page and instead have each app provide CRUD operations for its own objects... basically manage the objects where they belong (e.g. CRUD dashboards in the Dashboard app). Beyond that I can't think of any other reason for not adding it.. @markharwood do you recall something beyond that? If we really need to keep the import/export feature, I'm fine for it to be under the management app... but for CRUD I still prefer to move it away from there.... in that respect, if we're going create dedicated forms for the different objects, I rather have that work be done within the design of the appropriate app. |
Original comments are here As an end user I would personally value export/import of Graph saved objects - I think the concern you raised was possible overhead of maintaining BWC import parsing code. Maybe the general unease about the (lack of) security markings on any data saved in a Graph workspace was an added incentive to make exports hard too. |
@skearns64 I think the bulk of those changes are done at this point, with the overhaul of the saved object apis and such. There are still some legacy aspects around UI componentization (or lack thereof), but I don't think those should stop us from embracing the infra if it makes sense. |
+1 We've started using Kibana 6 (from Kibana 4) and have to recreate all indexes and then change the visualizations, etc. When we used Grafana, we could import-export everything and it worked as a charm. |
Pinging @elastic/kibana-platform |
We need a single spot to do config/dashboard/saved search/timelione/etc backups and restores. Either by recreating the cluster or by disaster recovery, having proper backup and restore calls are a must have. Right now its snake oil, kibana silently only exports part of the needed data. |
When creating the saved objects API, I played around with directly using the Saved Objects Client within the Management Saved Objects page instead of using Courier. While this turned out to be a larger undertaking than we had time for, I feel there are advantages to overhaul this page now that the API exists.
Here are some goals which I believe we should solve:
Ability to import/export all Saved Object types
Currently, one is only able to export Dashboards, Searches, and Visualizations. This limited ability can give the illusion that it's all which is required to backup the Kibana state. There have been issues raised to export remaining objects under the Kibana index including but not limited to advanced settings, Timelion sheets, and Index Patterns.
Per-object type editing form
When editing a saved object, we currently use a generalized form which determines the input to use for each field. If we were to instead create a form per type, it would allow us to improve this UI. For example, when editing a dashboard we could provide a dropdown of saved searches instead of a text input for the saved search id.
True paginated results
We currently fetch 100 objects for each type, in parallel and provide an in-browser pagination. We now have the ability to easily manage pagination through the API and should take advantage of this.
Implement a batch download in favor of using a scroll from the client
In #13000 we moved the remaining use of the scroll API to a legacy endpoint. We should either add a query parameter to the Saved Objects find method to stream the entire contents, or create a new endpoint.
The text was updated successfully, but these errors were encountered: