Rolling out this app has the following effect regarding HEC:
btool shows that the [http] config from this file is in runtime config
HEC is NOT enabled
In the GUI, HEC will show as not enabled, opening the settings shows that the "enabled" button is "clicked", it is however required to click it again and confirm, to get HEC enabled.
If I roll out the [http] part of this config using the splunk_httpinput app as deployment-app, HEC works just fine as desired.
Only way i now see to enable HEC on Heavy Forwarders via Deploymentserver is rolling out splunk_httpinput, however this has the downside, that i need to checkin the default folder of the app in version control without making any changes to it, because it will otherwise be deleted and Splunk will throw warnings for failed File integrity check as a result.
I am also not looking to handle HEC centrally from Deploymentserver, since it reduces the modularity of my deployment.
In my opinion, this behaviour is a bug solely based on the fact that btool check does not reflect state of the system, but before I raise it as a bug report, I want to ask whether anyone else has encountered similar issues and knows a better workaround than what I can come up with.
Finally it would probably be worth noting that my app has lower precedence than splunk_httpinput lexicographically in my case but 'local' should of course still take precedence over 'default'.
I see similar behavior. I added an app that creates a new index, and defines HEC token and added the app to a fresh install (8.0.2) with no other changes. For me. the HEC is enabled (I can curl a request and see the data ingested to the new index). Btool shows the app's effect in the runtime config.
As far as I can tell it's a UI bug more than a issue with the config not taking effect. The UI only seems to remove the red ! warning and stop showing "disabled' tokens if the splunk_httpinput/local/inputs.conf file exists with a [http] stanza and disabled=0 exists.