Config service server side

[rashidkpc]

Currently the config service is not available from the server, plugins need that

[spalger]

Related to #5312

[Bargs]

I just ran into a need for this as well when doing the refactoring for #6498

Based on the references to this ticket, it seems like there are a few different wants:

• Access currently frontend only config on the server
• Access config from plugins
• Modify config via an API from other applications

If that's accurate, I'd propose moving all of the config to the server and exposing it as a rest api. We could roll everything into server.config which plugins can access on the server side, and any front end clients could leverage the API.

Does that seem like a reasonable solution?

[rashidkpc]

Yeah, I'm with Matt, REST API-ify this thing. And let's do it sooner than later

[spalger]

How it that going to work with the config file? Are there going to be certain settings that are read from kibana.yml and some from elasticsearch? Do we persist changes to both places?

[bevacqua]

See #6849

[Bargs]

Good questions @spalger. Perhaps we shouldn't mix the two configs. What if we created a separate Hapi plugin specifically for handling the config in ES (what's a good name for that config? Application config? User config?). Then it would be available to all the other server side plugins, it would be responsible for providing the "settings REST api", it would be separate from server.config and it would provide other plugins with a mechanism for storing config in ES without reinventing the wheel.

[bevacqua]

I wasn't planning on merging "advanced settings" with application-specific configuration. These are two entirely different types of configuration. The former is user-provided while the latter is admin-provided. The PR I'm working on addresses advanced settings, application-specific configuration as an API is something I would advise against.

[Bargs]

@bevacqua I was referring more to the way server-side components will access both types of config, I assumed the API would only expose the advanced settings.

BTW I would actually build the API last, there are a few more important building blocks we need first:

1. Access to advanced settings on the server (required by Tail a File Wizard #5974)
2. Access to and ability to extend advanced settings from other plugins (Plugins need a way to extend the advanced config settings #5312). My thought is that this could be achieved with a Hapi "settings plugin" that all the other plugins can access, much in the same way all the plugins share the same elasticsearch client provided by the elasticsearch plugin. Open to other suggestions though.
3. A REST API wrapper around the new server side advanced settings code (nice to have since we're trying to remove all proxied ES queries from the front end, but not actually a hard requirement for any issues at the moment).

[spalger]

I agree that we should not merge the two configs. There are things that are more appropriate for a config file (things that shouldn't be editable by end users, or that need to be kept secret) and there are things that should be easy to change from the UI. For this the current system works well enough, we just need to move the schema/document management to the server so that plugins can extend the configuration, server code and other plugins can access that configuration, and so the configuration can be modified with an API.

[Bargs]

@bevacqua how's this coming along? Do we think it'll make alpha2?

[bevacqua]

@Bargs Implemented in master @ 5df51d5

[Bargs]

@bevacqua 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

so how do I use it? Could you add some descriptive text on the PR maybe?

[bevacqua]

See #6849 (comment)

[Bargs]

@bevacqua cool! How do I access config values in server side code?

[bevacqua]

Via server.uiSettings() API

[Bargs]

Sweet. Looks good!

[epixa]

Closed by #6849