please provide a way to split config settings into static and dynamic ones

[shoggeh]

Feature Description

Currently all of the "config =>" settings are ending up as entries in elasticsearch.yml which seems to be suboptimal as they are either never applied or require node/cluster restart to take real effect.

Elasticsearch docs say that kind of configuration should be avoided https://www.elastic.co/guide/en/elasticsearch/reference/5.4/cluster-update-settings.html

For this reason it is preferrable to use the elasticsearch.yml file only for local configurations, and set all cluster-wider settings with the settings API.

Hence it would be great if puppet-elasticsearch would allow to split config sections into two pieces

• static one, still stored in elasticsearch.yml - with all node parameters, local settings and static settings that can't be updated dynamically (like threadpools). User would still have a freedom to decide whether they want to enable node restarts to apply/update those.
• dynamic, applied over settings API (/_cluster/settings) and seamlessly updated upon every puppet run

In overall this approach would seem to improve flexibility a lot and also would greatly limit impact from very costly restarts/recoveries caused by applying new settings.

[tylerjl]

That's an interesting proposal, I could certainly see it being useful for people. Exposing an additional config_dynamic top-level parameter that simply uses a REST provider to talk to the API endpoint specified in the $api_* parameters in init.pp would probably work.

I'd note here for anyone following the development of the module that in its strictest sense, we're kind of pushing the limits of what Puppet should manage, since Puppet is really designed to manage host state and not really the contents of document stores/databases. However, it's generally been useful enough (see resources like index templates in this module) that we've just done it anyway. Doing things like this introduces weird possibilities such as running Puppet across your fleet and all nodes trying to manage an elasticsearch_template resource at once even though that resource exists only in one place (the Elasticsearch API).

However, all that being said, I'd be open to this since it still falls into the "configuration" bucket of the Elasticsearch APIs. I don't know when I can get a PR together for this, but for the sake of a design document in case someone wants to pick it up in the meantime:

• The design should follow the rest of the native REST providers the module uses, in the module these can be found for elasticsearch_index, elasticsearch_pipeline, and elasticsearch_template.
• Following those aforementioned existing providers/types includes writing a new type, provider, defined type (to wrap the provider for convenience so that things like a connection validator can be used), and some tests in spec/.

Note that writing these native types and providers over REST APIs can be kind of tricky but the existing examples I've noted should be flexible enough that it isn't as difficult as it used to be (the provider has lots of tools to make things like the choosing the API endpoint, munging the JSON response, etc. easier).