Migration leads to index pattern ID failure / Hardcoded ID

[t3fsx]

Scenario:

• Several filebeat agents dispatching information to Elastic
• Index Pattern created for filebeat-*

On a cluster migration, I just wanted to export my visualizations to the new cluster. Exported the visualizations and imported into the new cluster. Because the export included related files, index pattern (from the configs) was also copied.

When I visited the first visualization, it complained about the index pattern not existing. After analyses I found that the Saved Search that is feeding the visualizations was configured to:

...
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[1].meta.index",
    "id": "filebeat-*",
    "type": "index-pattern"
...

Several discussions on discuss.elastic.co mention that, the reason the visualizations and saved searches were failing was because the index pattern was created with the wrong ID. I deleted the index pattern that came with the export and created one, using the advanced options to manually set the ID to "337394b0-c419-11e9-9c68-2daf796aac2a". Even after the creation, visualizations were still failing.

What fixed my problem was going to the saved searches and visualizations that were dependent on the "filebeat-*" and HARDCODED the ID, as in:

 {
    "name": "kibanaSavedObjectMeta.searchSourceJSON.filter[1].meta.index",
      "id": "337394b0-c419-11e9-9c68-2daf796aac2a",
    "type": "index-pattern"
 }

It's important to mention that this migration was from an early 7.0 version to 7.5, however, I don't believe setting the ID hardcoded is the best way to go, so there has to be a better way of fixing this.

Any tips/help?

Thank you.

[t3fsx]

To add bit more information to this, one of the ways around it is:

• Export saved objects from "source" cluster WITHOUT exporting related objects (namely saved searches)
• Have Filebeats start dispatching information to the new cluster and create a new index pattern
• After index pattern is created, manually import in the following order: saved searches, visualizations, dashboards

When importing the saved searches and the visualizations, the following warning will appear:

I still consider this to be a bug, as you can tell by the image, it's complaining about "filebeat-" not existing and asking if we want to index in a new "filebeat-", which, again, leads me to believe there is something weird happening with index template ID's.

After confirming that change to the "new" index template, everything should work without errors.

It would be really nice to have some more information as to why the names of the templates are being ignored, and instead we're relying on hardcoded IDs.