agent: support ZINCATI_AGENT_IDENTITY_GROUP env value

[zyclonite]

Feature Request

Desired Feature

would be nice to support environment variables to override things like group
this would make it much easier to simply extending the unit file than writing an additional toml

Example Usage

ZINCATI_GROUP as override for identity.group
ZINCATI_VERBOSITY to set the verbosity level

Other Information

this would as well solve the "handover" for log verbosity in the current zincati.service example

[lucab]

Thanks for the report.

Environment flags (and CLI flags as well) do not support the full semantics allowed by TOML fragments, so in general I'm not planning a 1:1 match.
For some of them (i.e. the simplest, like identity.group) it may make sense, but then we spiral down into a journey of env+cli+toml matching which worries me a bit.
Plus I'm not sure that extending a unit with an Environment fragment is very different from writing a TOML fragment. Care to elaborate about your specific flow?

Regarding verbosity, the main reason for having it as a CLI flags is in order have logging set up before the rest of the logic (including configuration parsing). That's the only exception I can think of. Everything else really goes into structured config files.

[zyclonite]

my current use-case is to use an ignition file as template, having some placeholders in unit files works but for example inlining files in the filesystem section does encode a lot of characters, so replacing them there is not possible.

for sure there is other ways to do that, a quick an dirty way is to have a pre start command creating the toml fragment - a cleaner approach would be to get already the toml file from an external service which does the replacement

hope this explains it a bit...

[lucab]

So, circling back to this:

• the general request is too far fetched, I'm not going down pursuing a 1:1 mapping between config and env flags (same for CLI flags)
• as general rule, we prefer directing users towards towards customizing Zincati via TOML fragment (instead of overriding bits of the service unit)
• a request for env/CLI flags in specific cases may make sense, see the verbosity level explanation above
• this ticket is specifically about having something like $ZINCATI_AGENT_IDENTITY_GROUP, but it doesn't seem to cover cases which can't be covered by the usual TOML config. I'm pretty unconvinced here.

Specifically, this ticket seems to be stemming from a deeper problem (which should probably be covered in a forum post):

my current use-case is to use an ignition file as template, having some placeholders in unit files works but for example inlining files in the filesystem section does encode a lot of characters, so replacing them there is not possible.

Templating Ignition JSON is fine, but should be done with a capable tool.
The shortcoming you describe should be already covered by relevant templating tools (FCCT, Terraform, jsonnet, etc.).
For an example of advanced templating/matching in action, see https://github.com/poseidon/matchbox.

[zyclonite]

thank you for the feedback, i use fcct for pre-transpiling the files because i need to package them and would like to prevent running the tool in the fly. i like the matchbox approach but it does not solve my problem either so i tried now exposing fcct as a service that enables me to roll the configs with it's placeholders replaced before transpiling them on the fly.

similar to your fcct-online approach but embedding the tool directly, see fcct-service

[lucab]

@zyclonite that sounds interesting, though I think I'm missing some higher-level details on the overall scenario. As we are going a bit off-track here, would you mind posting a short summary of your provisioning flow in the discussion forum (linked above)?

[ashcrow]

cc'ing @zonggen too for visibility

[zyclonite]

@lucab was not easy to sum it up in a way to get you a glimpse how the setup looks like. see https://discussion.fedoraproject.org/t/fcct-and-configuring-or-templating-other-fcos-components-and-services/19778

[lucab]

Revisiting this with all the information at hand, my final stance is that the underlying problem is due to an improper third-party Ignition config transpiling/templating pipeline. We are not going to introduce environment variables in the mix to workaround that.
Before closing this ticket though, I need to add a short FAQ entry on the rationale behind the split between env variables, TOML configuration, and CLI flags.