(this is probably the server-side counterpart of #49691)
This ticket is to discuss with @elastic/kibana-platform the possible solutions around the issue of setup API's requiring access to start API's to register logic that should be executed after startup.
Issue
In NP, lifecycle is split in two steps: setup and start. We ask plugins to perform all configuration/registration during setup.
However in some cases, the registered objects are meant to be using start API, which are not yet accessible.
First exemple that comes to mind is the telemetry usage collector:
|
export function createCollectorFetch(server: Server) { |
|
return async function fetchUsageStats(): Promise<UsageStats> { |
|
const internalRepo = server.newPlatform.setup.core.savedObjects.createInternalRepository(); |
|
const uiSettingsClient = server.newPlatform.start.core.uiSettings.asScopedToClient( |
|
new SavedObjectsClient(internalRepo) |
|
); |
|
|
|
const user = await uiSettingsClient.getUserProvided(); |
|
const modifiedEntries = Object.keys(user) |
|
.filter((key: string) => key !== 'buildNum') |
|
.reduce((obj: any, key: string) => { |
|
obj[key] = user[key].userValue; |
|
return obj; |
|
}, {}); |
|
|
|
return modifiedEntries; |
|
}; |
|
} |
|
|
|
export function registerManagementUsageCollector( |
|
usageCollection: UsageCollectionSetup, |
|
server: any |
|
) { |
|
const collector = usageCollection.makeUsageCollector({ |
|
type: KIBANA_MANAGEMENT_STATS_TYPE, |
|
isReady: () => true, |
|
fetch: createCollectorFetch(server), |
|
}); |
|
|
|
usageCollection.registerCollector(collector); |
|
} |
The collector creation requires to access a uiSettingClient, which is only accessible via a core's start API.
const internalRepo = server.newPlatform.setup.core.savedObjects.createInternalRepository();
const uiSettingsClient = server.newPlatform.start.core.uiSettings.asScopedToClient(
new SavedObjectsClient(internalRepo)
);but the registration is then done with a usageCollection'ssetup API:
usageCollectionSetup.registerCollector(collector);
This code works in legacy, as the plugin got access to both setup and start at the same time, but cannot currently be migrated (therefor the blocker label).
Proposal
#49691 address this issue on the client-side by adding the getStartServices API, and at this time we did not see any need to do the same on server-side, but I think we now have a valid reason to do the same.
By implementing getStartServices to the server-side, the previous code could then be properly migrated to NP and be executed during setup:
export function createCollectorFetch(core: CoreSetup) {
return async function fetchUsageStats(): Promise<UsageStats> {
const internalRepo = core.savedObjects.createInternalRepository();
const uiSettingsClient = (await core.getStartService()).uiSettings.asScopedToClient(
new SavedObjectsClient(internalRepo)
);
const user = await uiSettingsClient.getUserProvided();
const modifiedEntries = Object.keys(user)
.filter((key: string) => key !== 'buildNum')
.reduce((obj: any, key: string) => {
obj[key] = user[key].userValue;
return obj;
}, {});
return modifiedEntries;
};
}
export function registerManagementUsageCollector(
core: CoreSetup,
usageCollection: UsageCollectionSetup,
) {
const collector = usageCollection.makeUsageCollector({
type: KIBANA_MANAGEMENT_STATS_TYPE,
isReady: () => true,
fetch: createCollectorFetch(core),
});
usageCollection.registerCollector(collector);
}
(this is probably the server-side counterpart of #49691)
This ticket is to discuss with @elastic/kibana-platform the possible solutions around the issue of
setupAPI's requiring access tostartAPI's to register logic that should be executed after startup.Issue
In NP, lifecycle is split in two steps:
setupandstart. We ask plugins to perform all configuration/registration during setup.However in some cases, the registered objects are meant to be using
startAPI, which are not yet accessible.First exemple that comes to mind is the telemetry usage collector:
kibana/src/legacy/core_plugins/telemetry/server/collectors/management/telemetry_management_collector.ts
Lines 33 to 63 in ebd2c21
The collector creation requires to access a
uiSettingClient, which is only accessible via a core'sstartAPI.but the registration is then done with a
usageCollection'ssetupAPI:This code works in legacy, as the plugin got access to both
setupandstartat the same time, but cannot currently be migrated (therefor the blocker label).Proposal
#49691 address this issue on the client-side by adding the
getStartServicesAPI, and at this time we did not see any need to do the same on server-side, but I think we now have a valid reason to do the same.By implementing
getStartServicesto the server-side, the previous code could then be properly migrated to NP and be executed duringsetup: