MAX_OPEN_FILES should be configurable for Sensu Enterprise

[cwjohnston]

Description of problem

Sensu Enterprise uses the value of MAX_OPEN_FILES environment variable to configure ulimit settings prior to starting the JVM. The value of this environment variable can be configured by editing /etc/default/sensu-enterprise, but is not present in the template used by this module to render that file. As a result, users cannot configure the number of file handles Sensu Enterprise can open when using this module.

Platform and version information

• Your OS: Centos 7
• Your version of Sensu: Sensu Enterprise 2.7.0
• Your version of this module: 2.40.1

[ghoneycutt]

Thanks @cwjohnston

Could you let us know if there are any other options that should be configurable there? That way we can make this feature complete in one pass.

[alvagante]

For what I see here:
https://sensuapp.org/docs/latest/enterprise/configuration.html
There are this Sensu Enterprise only environment variables:
HEAP_SIZE
HEAP_DUMP_PATH
JAVA_OPTS
MAX_OPEN_FILES
We currently support HEAP_SIZE and with the PR for this ticket, MAX_OPEN_FILES.

[alvagante]

The variables common both to OSS and EE are, if I correctly understood:
SENSU_CLIENT_NAME
SENSU_CLIENT_ADDRESS
SENSU_CLIENT_SUBSCRIPTIONS
SENSU_TRANSPORT_NAME
RABBITMQ_URL
REDIS_URL
REDIS_SENTINEL_URLS
SENSU_API_PORT
In our /etc/default/sensu file, we we set other environment variables, we do not manage any of them (they are manaed via the normal configuration json files)

[cwjohnston]

@alvagante You're right, both HEAP_DUMP_PATH and JAVA_OPTS are honored by Sensu Enterprise only, and are not currently managed by this module. It would be ideal to support configuring these via Puppet. In conjunction with #850, I believe we'd have all the Enterprise-specific environment variables covered at that point.

FWIW, Sensu Enterprise will source both /etc/default/sensu and /etc/default/sensu-enterprise on startup, so it's probably reasonable to isolate Enterprise-only variables into their own file.

cc @ghoneycutt

[alvagante]

@cwjohnston @ghoneycutt currently we use the same template for both /etc/default/sensu (https://github.com/sensu/sensu-puppet/blob/master/manifests/package.pp#L180) and /etc/default/sensu-enterprise (https://github.com/sensu/sensu-puppet/blob/master/manifests/enterprise.pp#L54).

We might use a different template for sensu-enterprise and place there all the ee-only settings we need (so avoiding the need to have them as params duplicated in the main init.pp).

[cwjohnston]

@alvagante to circle back to your prior comment about vars shared by Core and Enterprise, I believe the following env vars should not be managed by this module:

SENSU_CLIENT_NAME
SENSU_CLIENT_ADDRESS
SENSU_CLIENT_SUBSCRIPTIONS
SENSU_TRANSPORT_NAME
RABBITMQ_URL
REDIS_URL
REDIS_SENTINEL_URLS
SENSU_API_PORT

The values for these env vars are overridden by JSON configuration on disk, and the module manages JSON configuration for each of these settings. I think having values set for these in both environment variables and in JSON on disk is likely to create confusion.

From my perspective, env vars like MAX_OPEN_FILES, JAVA_OPTS, CONFD_DIR and CONFIG_FILE are different because they are used by service management (sysv init scripts, sensu-service wrapper script) to influence the runtime environment of Sensu processes in a way that can't be achieved via JSON configs on disk.

[alvagante]

@cwjohnston ok, understand and agree with such division. Actually that was also my concern.
Still for management of the MAX_OPEN_FILES, JAVA_OPTS, CONFD_DIR and CONFIG_FILE (and all the others that will eventually come) we could still use a single hash param and make it honours the current settings. As discussing in #851

[alvagante]

@ghoneycutt this can be closed, I suppose, since relevant PR has been merged.