[Centralized Management] Accept xpack.management.kibana.* settings

[elasticmachine]

Original comment by @ycombinator:

Based on elastic/kibana#18185

Currently, if users want to programatically use Logstash Centralized Configuration Management, they must directly read/write from the .logstash index in Elasticsearch. This is obviously not ideal for at least a couple of reasons:

• Such users end up getting tied to the exact structure of the .logstash index, so any changes we might make to it will break such users.

• As the .logstash index grows in structure to accommodate different aspects of centralized configuration management, users could easily misuse it and cause unintended side effects / breakages in their Logstash deployments.

A safer alternative is to provide an HTTP API instead as a more abstract and constrained programmatic interface. Chatting with @epixa, since the .logstash index doesn't actually get used by any processes within Elasticsearch itself (unlike, say, the Watcher or Security indices), it makes sense for the Logstash Centralized Configuration HTTP API to be exposed from Kibana.

One major change will be required from existing (and new) users of Logstash Centralized Management: Instead of setting xpack.management.elasticsearch.* in their logstash.yml, we'd want them to setup the analogous xpack.management.kibana.* settings instead. Obviously, the Logstash code working off these settings will need to change as well.

We should introduce this API soon, in a 6.x release, and support either family of settings, deprecating the xpack.management.elasticsearch.* ones and warning about them. Then in 7.0 we can fail hard if those settings are found.

[elasticmachine]

Original comment by @ycombinator:

@andrewvc In order to make this change, Logstash will need a notion of a Kibana client in the code. I noticed that we already have one for modules here:

https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/modules/kibana_client.rb

So my plan (via a PR to OSS Logstash) is to:

• extract this client from the logstash-core/lib/logstash/modules folder and into the logstash-core/lib/logstash folder,
• update the corresponding Ruby module namespacing to module LogStash,
• make the settings taken as argument by the initialize method agnostic of module setting naming such as var.kibana.host. Instead I was thinking of simply dropping the var.kibana prefix. Obviously, the calling module code will need to be updated as well.

This refactoring would then make it easy for the modules code and the xpack management code to both share the same Kibana client.

Does this plan seem sane to you? Am I missing anything?

[EDIT] In addition to the Kibana client refactoring proposal above, I also plan (via a PR in X-Pack Logstash) to write code that actually uses the new Kibana settings to talk to Kibana APIs, of course.

[elasticmachine]

Original comment by @ycombinator:

@andrewvc In my previous comment I mentioned a PR to OSS Logstash. I've created that here now: #9396