Config file ordering seems confusing about aktualizr

[ricardosalveti]

It's normal for software to have default configs at /usr/lib/foo and user defined ones at /etc/foo (and usually they are parsed while loaded, so you know a certain config option set in a fragment in /etc will always have higher priority over one set in /usr).

[pattivacek]

Unfortunately, the behavior you are seeing is what I would expect based on https://docs.ota.here.com/ota-client/latest/aktualizr-config-options.html#_how_toml_files_are_processed. It is intentional that the files are sorted lexicographically before parsing. We expect the config files to be prefixed with a numeric priority, but your sota.toml doesn't have that, and it gets processed last. /var/sota/sota.toml is a relic of the past for us, and we don't treat it specially.

[ricardosalveti]

But even without var/sota/sota.toml we might experience a few issues from the way I see:
1 - Files under /usr/lib/sota/conf.d and /etc/sota/conf.d/ with the same filename but different content might result in configs not being parsed at all (and the user would have to know that it is not creating a file in etc that is conflicting with one present at usr).
2 - Configs at /etc/sota/conf.d/ might end up being ignored if it has a lower number index prepending the file name with a similar one available at /usr/lib/sota/conf.d, since what matters in the end is the order of the file names, and not the original location.

[pattivacek]

Perhaps it is worth restating that this config parsing system was intended to match the way systemd's configuration is handled. It's not exact, since the use case is slightly different, but the principles are similar. I think what is most confusing, though, is that you can manually pass in config directories and paths and it's not entirely obvious how they are treated.

I think this isn't the most straightforward system, but it is quite flexible, which was the goal. I'm hesitant to change it, though, because it could be a subtle change that might break things for people in unexpected ways without them noticing.

1 - Files under /usr/lib/sota/conf.d and /etc/sota/conf.d/ with the same filename but different content might result in configs not being parsed at all (and the user would have to know that it is not creating a file in etc that is conflicting with one present at usr).

Yes, that is correct and intended. The point is that /usr/lib is provided by the image while /etc can be manually edited.

2 - Configs at /etc/sota/conf.d/ might end up being ignored if it has a lower number index prepending the file name with a similar one available at /usr/lib/sota/conf.d

Yes, that is correct and intended.

since what matters in the end is the order of the file names, and not the original location.

Both aspects matter. The directories are searched in order of preference for files, with can result in some files being ignored in favor of later ones found with the same name, and the resulting list is parsed in alphabetic order, meaning settings in some can be overruled by others.

[ricardosalveti]

I think this isn't the most straightforward system, but it is quite flexible, which was the goal. I'm hesitant to change it, though, because it could be a subtle change that might break things for people in unexpected ways without them noticing.

Right, while confusing in a way, changing this behavior will indeed cause unexpected side effects.