allow env variables for numa settings

[koomie]

No description provided.

[jordap]

This is minor, but we use victoria_corebinding and OMNISTAT_VICSERVER_COREBINDING, and internally we use vm for the variables. It would be nice to settle on one name for Victoria Metrics.

Victoria Metrics itself uses either victoria-metrics, victoriametrics, or vm. I understand victoriametrics is long, and vm can be confused with virtual machine.

Any thoughts? Even if vm makes me think of virtual machine, there's enough context and it could work. We could also use vmserver: OMNISTAT_VMSERVER_COREBINDING and vmserver_corebinding.

[koomie]

I'm a bit hesitant to change the existing nomenclature in the runtime config file which goes beyond a core binding setting, e.g.

victoria_binary = /path-to-victoria-metrics-install/victoria-metrics-prod
victoria_datadir = data_prom
victoria_logfile = vic_server.log

I'm all for consistency but we have also advertised OMNISTAT_VICSERVER_DATADIR to override the datadir setting so there are multiple things that would need to change for consistency if we were to do it.

Seems we have the following options:

1. continue to have a slightly different convention in env variable name vs runtime file setting
2. update all environment variable override name options to match runtime file counterparts exactly with an OMNISTAT prefix
3. change runtime variable names and environment variable names to some new, consistent schema

Options 2. and 3. would introduce a version incompatibility for the runtime file and environment variable settings. Granted, most folks are using the supplied runtime file, so now would be the time to do it but I confess to wondering if it's that useful to change things now.

Thoughts?

[koomie]

I'm a bit hesitant to change the existing nomenclature in the runtime config file which goes beyond a core binding setting, e.g.

victoria_binary = /path-to-victoria-metrics-install/victoria-metrics-prod
victoria_datadir = data_prom
victoria_logfile = vic_server.log

I'm all for consistency but we have also advertised OMNISTAT_VICSERVER_DATADIR to override the datadir setting so there are multiple things that would need to change for consistency if we were to do it.

Seems we have the following options:

1. continue to have a slightly different convention in env variable name vs runtime file setting
2. update all environment variable override name options to match runtime file counterparts exactly with an OMNISTAT prefix
3. change runtime variable names and environment variable names to some new, consistent schema

Options 2. and 3. would introduce a version incompatibility for the runtime file and environment variable settings. Granted, most folks are using the supplied runtime file, so now would be the time to do it but I confess to wondering if it's that useful to change things now.

Thoughts?

Option 4 (assuming we don't care about env variable name consistency with prometheus settings in user mode which are likely to get deprecated at some point)

4. change OMNISTAT_VICSERVER_DATADIR and OMNISTAT_VICSERVER_COREBINDING to

• OMNISTAT_VICTORIA_DATADIR
• OMNISTAT_VICTORIA_COREBINDING

This would make them consistent with the runtime variable names. Since the corebinding variable is new, that won't affect anyone and we could continue to support OMNISTAT_VICSERVER_DATADIR with a warning to phase out in future release.

[koomie]

Via direct comms, Option 4 above is the preference.