Expose elasticsearch config schema

[mshustov]

Summary

Closes #56872, #56618
Required to unblock Monitoring plugin migration.

Plugins are allowed to create a custom elasticsearch config that will be used for custom elasticsearch clients. Although I only found that monitoring allows to re-define elasticsearch config values.

// monitoring_config
import { elasticsearchSchema } from 'src/core/server';
const schema = elasticsearchSchema;
// monitoring_plugin
const config$ = config.create().pipe(map(rawConfig => new ElasticsearchConfig(rawConfig)));
// note all this logic belongs to elasticsearch service so far
const client$ = config$.pipe(map(config => elasticsearch.createClient('monitoring', config));

The current implementation is the most straightforward and there are several things that I don't like:

• exporting elasticsearch schema and ElasticsearchConfig class increases API surface
• elasticsearch schema and ElasticsearchConfig are tightly coupled and could not be used separately, which is not obvious.
• it's easy to misuse config$ and ignore config updates.
• @kbn/config-schema doesn't allow to re-write validation rules locally. YAGNI, but I can imagine such a requirement in the future.

I think we can live with it for some time, but I assume we may want to refactor this part. To get rid of ElasticsearchConfig class of to move elasticsearch config validation to the platform, for example. Should I open a discussion about it or we are okay with the current approach?

// elasticsearch config
const elasticsearchSchema = schema.object({
   //...
  clients: schema.recordOf(schema.string(), elasticsearchSchema);
});
// kibana.yml
elasticsearch.clients.monitoring.requestTimeout: 30000
// monitoring_plugin
const client$ = elasticsearch.getClient('monitoring'));

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[joshdover]

We could expose an Observable interface that consumes the raw config and produces clients:

// on ElasticsearchSetup
// This would automatically swap out client instances under-the-hood just like
// dataClient
createClusterClient(config$: Observable<ElasticsearchConfigType>): ClusterClient;

// in plugin code

export const config = {
  schema: schema.object({
    monitoringCluster: coreConfig.elasticsearch.schema
  })
}

class Plugin {
  setup(core) {
    const monitoringCluster = core.elasticsearch.createClusterClient$(
      this.config$.pipe(map(c => c.monitoringCluster))
    );
  }
}

[rudolf]

I like the suggestion of a createClusterClient method.

[mshustov]

@joshdover @rudolf any actionable comments to merge this PR?

[mshustov]

@elasticmachine merge upstream

[joshdover]

Don't have any reason to block on this, but one suggestion might be to mark these exports as @alpha since we may (will?) change these later.

[joshdover]

Wow api-extractor, this is ugly 🙁

[mshustov]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 82e1d4e

History

• 💚 Build #27900 succeeded 5c0193c255a94daa7d784934e859d9f053c2d514
• 💛 Build #26757 was flaky 42cc892

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream