Ability to set custom directory path for *.alloy config files

[M4jx]

Details

There is currently an issue with the behavior of alloy_config and alloy_env_file_vars. According to the docs, the alloy_config is required and cannot be empty. However, the service crashes when attempting to set a custom directory path using CUSTOM_ARGS in alloy_env_file_vars to load multiple *.alloy configuartion files due to a conflict (i think) because of the presence of alloy_config:

Scenario 1 (Working)

Ansible play with alloy_config only:

alloy_version: "1.5.0"
alloy_config: "<config here>"

Checking the executed command in systemctl service shows the following (service running successfully):
/usr/bin/alloy run --storage.path=/var/lib/alloy/data /etc/alloy/config.alloy.

Scenario 2 (Crashing)

Ansible play with alloy_config (can't remove it because it is required) and alloy_env_file_vars with directory path:

alloy_version: "1.5.0"
alloy_config: "<config here>"
alloy_env_file_vars:
  CUSTOM_ARGS: "/opt/alloy/conf.d"

Checking the executed command in systemctl service shows the following (service crashing):
/usr/bin/alloy run $CUSTOM_ARGS --storage.path=/var/lib/alloy/data $CONFIG_FILE.

Crash log:

Nov 16 03:44:48 docker alloy[1162610]: Error: accepts 1 arg(s), received 2
Nov 16 03:44:48 docker systemd[1]: alloy.service: Main process exited, code=exited, status=1/FAILURE
Nov 16 03:44:48 docker systemd[1]: alloy.service: Failed with result 'exit-code'.
Nov 16 03:44:49 docker systemd[1]: alloy.service: Scheduled restart job, restart counter is at 3.
Nov 16 03:44:49 docker systemd[1]: Stopped Vendor-agnostic OpenTelemetry Collector distribution with programmable pipelines.
Nov 16 03:44:49 docker systemd[1]: Started Vendor-agnostic OpenTelemetry Collector distribution with programmable pipelines.

[chunk64]

Can we make a new alloy_config_dir as a first-class option in this role? Then we can update this role to allow either alloy_config or alloy_config_dir?

The directory option would be a little more composable for ansible installations, because users could more easily add/remove alloy configs for different hosts

[voidquark]

First of all, thank you for reporting this issue.

To prevent this failure, I think it makes sense to modify the preflight check for configuration requirements. We could skip that precheck only if alloy_env_file_vars is being used.

I’m not in favor of adding extra variables for directory configuration because the installation is managed via rpm/deb packages, which already handle directory creation and related logic.

I’ll test this and raise a PR.