Currently, the es-archiver is creating a KibanaMigrator to migrate the kibana index after a load
|
// If we affected the Kibana index, we need to ensure it's migrated... |
|
if (Object.keys(result).some(k => k.startsWith('.kibana'))) { |
|
await migrateKibanaIndex({ client, log, kibanaPluginIds }); |
|
|
|
if (kibanaPluginIds.includes('spaces')) { |
|
await createDefaultSpace({ client, index: '.kibana' }); |
|
} |
|
} |
However to do that, it manually gathers the uiExports from the legacy plugins to get the SO schemas/mappings/migrations
|
const getUiExports = async kibanaPluginIds => { |
|
const xpackEnabled = kibanaPluginIds.includes('xpack_main'); |
|
|
|
const { spec$ } = await findPluginSpecs({ |
|
plugins: { |
|
scanDirs: [path.resolve(__dirname, '../../../legacy/core_plugins')], |
|
paths: xpackEnabled ? [path.resolve(__dirname, '../../../../x-pack')] : [], |
|
}, |
|
}); |
|
|
|
const specs = await spec$.pipe(toArray()).toPromise(); |
|
return collectUiExports(specs); |
|
}; |
|
export async function migrateKibanaIndex({ client, log, kibanaPluginIds }) { |
|
const uiExports = await getUiExports(kibanaPluginIds); |
|
savedObjectSchemas: new SavedObjectsSchema(uiExports.savedObjectSchemas), |
|
savedObjectMappings: convertLegacyMappings(uiExports.savedObjectMappings), |
|
savedObjectMigrations: uiExports.savedObjectMigrations, |
|
savedObjectValidations: uiExports.savedObjectValidations, |
|
callCluster: (path, ...args) => _.get(client, path).call(client, ...args), |
|
}; |
|
|
|
return await new KibanaMigrator(migratorOptions).runMigrations(); |
After #55825 and the other SO types related issues are done, the SO types will be created from the new platform, and the archiver will not be able to be aware of them for the migration.
We need to find a way to have the archiver be aware of the NP-declared types. However, as the types registration is now done programmatically from the plugins setup phase, I'm really not seeing anything obvious to address this.
Currently, the es-archiver is creating a KibanaMigrator to migrate the kibana index after a load
kibana/src/es_archiver/actions/load.js
Lines 90 to 97 in 8e9a8a8
However to do that, it manually gathers the uiExports from the legacy plugins to get the SO schemas/mappings/migrations
kibana/src/es_archiver/lib/indices/kibana_index.js
Lines 37 to 49 in c65c28a
kibana/src/es_archiver/lib/indices/kibana_index.js
Lines 80 to 81 in c65c28a
kibana/src/es_archiver/lib/indices/kibana_index.js
Lines 106 to 113 in c65c28a
After #55825 and the other SO types related issues are done, the SO types will be created from the new platform, and the archiver will not be able to be aware of them for the migration.
We need to find a way to have the archiver be aware of the NP-declared types. However, as the types registration is now done programmatically from the plugins
setupphase, I'm really not seeing anything obvious to address this.