Ability to export the index pattern along with saved objects

[tbragin]

Right now, when we export a dashboard, the index pattern(s) does not get exported along with it. So the import process requires the user to create the correct index patterns(s) manually and then re-import.

[jimmyjones2]

Plus all the field format config!

[jccq]

• 1
  how about the advanced settings as well.
  On 19 Jun 2015 8:34 pm, "jimmyjones2" [email protected] wrote:

Plus all the field format config!

—
Reply to this email directly or view it on GitHub
#4288 (comment).

[marcuslacerda]

+1

[azhurbilo]

+1

[markwalkom]

+1

Having to do the DB then the visualisations and then do this is a PITA

[driegel]

+1

Actually, I feel that this is an important feature. If possible, please rate with higher priority than 'enhancement'. Right now it is only possible with external tools to fully transfer dashboards to a new setup.

[ppf2]

++ This is a common request from the field to be able to export/import dashboards and visualizations between different clusters (and sometimes across data centers that will have indices named differently - a requirement for the tribe node). With the export's visualization including the index pattern reference, but no actual index settings for the pattern, the user will have to first create dummy index patterns in the target environment just to be able to even import these objects into the target cluster. Obviously these dummy index patterns are of no actual use for querying in the target cluster, so the user will also have to go through a process to update each visualization from the advanced editing screen to change the visualization reference - also tedious because you can't batch change these today (#3668) with each visualization tied to an actual index pattern. Alternatively, the user will have to hack the exported .json to make changes to all the index references to map to existing indices in the target cluster - easier way, but more risky with the potential to corrupt the export while performing direct modification of the export file.

[Bargs]

Folks who are following this issue might also be interested in the Index Pattern API #5199 and my PR for it #5213. It won't provide a GUI for exporting index patterns, but some of your use cases might overlap.

[driegel]

@Bargs Well, it's possible to import and export objects in Kibana4. These files need to contain the index patterns, and I do not know if I need an Index Pattern API for that. Until this feature is available, I use 'es-export-bulk' and 'es-import-bulk' from https://github.com/skratchdot/elasticsearch-tools

[Chadwiki]

+1

[sporokh]

+1

[rv-gava]

+1, really needed feature

[alugovoi]

+1

[talkerbox]

+1

[sqpdln]

+1

[maxvu]

+1

[raulvc]

+1, currently working with elasticdump workaround (which isn't pretty to mantain!)

[tsullivan]

I ran into this issue today, and in my case, the index pattern included a scripted field. Even after re-creating the index pattern with a scripted field that had the same name, the visualization I imported that worked with the original scripted field didn't work out of the box with the re-created scripted field.

I took a screenshot of the visualization with the error shown in a Dashboard, where the scripted field is called "image"

[obudiman]

+1

[nfarrell]

+1

[ekkinox]

+1

[mohclips]

+1

[mrjameshamilton]

+1

[gmoskovicz]

Very useful for doing upgrades.

[ghost]

+1

[GrahamHannington]

+1

The Export Everything button in Kibana doesn't export everything. Some of my Kibana visualizations rely on scripted fields that are defined in index patterns.

[randude]

+1 This is really needed and to me seems very basic.
I dont understand why this hasnt been solved for the past 2+ years.

[driegel]

Well, one problem is that index pattern fields may disappear on refresh, if there is no data; that is why we need full JSON files if we want to transfer dashboards to customers.

curl -XGET 'http://localhost:9200/.kiban*/index-pattern/_search?size=10000&pretty' -o idx-pattern.json
curl -XGET 'http://localhost:9200/.kiban*/search/_search?size=10000&pretty' -o searches.json
curl -XGET 'http://localhost:9200/.kiban*/visualization/_search?size=10000&pretty' -o vis.json
curl -XGET 'http://localhost:9200/.kiban*/dashboard/_search?size=10000&pretty' -o dashboard.json

Then there is some need to edit:

{

    hits: [
-- 8< -----
+ [

....

       ]
-- 8< -----
   }
}

[cgspohn]

+1

[marcelloromani]

+1

[batytskyy]

+1

[onetroll]

+1

[rhautefeuille]

+1

[jccq]

+1

[jccq]

@epixa almost a year ago the P1 priority was removed, is there a specific reason why this seems less important?

[epixa]

@jccq No, this is still as important as before. We deleted all of the P labels entirely as we weren't using them consistently, which is why it was removed from this issue.

[jccq]

thanks @epixa how about replacing some of the "reactify" in some of the next sprint with this :) just saying. thanks for all

[epixa]

@jccq We don't do sprints, but the react work we're doing across Kibana doesn't really impact when we work on this particular issue. There are hundreds of things in flight at the moment, and a few hundred more things on deck. We are anxious to get to this issue as soon as we can, though.

[jccq]

great to hear. It opens the road to storing more metadata into index patterns e.g. comments or hints for the users, things that make all nicer. Best

[jinleileiking]

+1

[bferg314]

+1

[markwalkom]

Please use the reaction picker on the initial post to +1 this :)

[gmoskovicz]

Thank you very much everyone for adding the +1!

However, best is to add a thumbs-up reaction in the initial post if you would like to participate on this. Extra +1 will not help, and we are aware that this is a very nice feature to have. Thanks for the understanding!

[alexfrancoeur]

@chrisronline does #17426 close this issue?

[chrisronline]

Yes, good call!