Alertmanager: amtool: /etc/amtool.yml is never read

[filippog]

The amtool documentation states that /etc/amtool.yml will be read, though it attempts to read /etc/.amtool.yml (and many others) instead:

strace -e file -- amtool silence
execve("/usr/bin/amtool", ["amtool", "silence"], [/* 18 vars */]) = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
readlinkat(AT_FDCWD, "/proc/self/exe", "/usr/bin/amtool", 128) = 15
openat(AT_FDCWD, "/proc/sys/net/core/somaxconn", O_RDONLY|O_CLOEXEC) = 3
stat("/proc", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
openat(AT_FDCWD, "/proc/stat", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/localtime", O_RDONLY) = 3
stat("/etc/.amtool.json", 0xc42012ce08) = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.toml", 0xc42012ced8) = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.yaml", 0xc42012cfa8) = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.yml", 0xc42012d078)  = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.properties", 0xc42012d148) = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.props", 0xc42012d218) = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.prop", 0xc42012d2e8) = -1 ENOENT (No such file or directory)
stat("/etc/.amtool.hcl", 0xc42012d3b8)  = -1 ENOENT (No such file or directory)
stat("/root/.amtool.json", 0xc42012d488) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.toml", 0xc42012d558) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.yaml", 0xc42012d628) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.yml", 0xc42012d6f8) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.properties", 0xc42012d7c8) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.props", 0xc42012d898) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.prop", 0xc42012d968) = -1 ENOENT (No such file or directory)
stat("/root/.amtool.hcl", 0xc42012da38) = -1 ENOENT (No such file or directory)
Error: Invalid alertmanager url

[juliusv]

cc @Kellel

[stuartnelson3]

Looks like a typo in the documentation:

https://github.com/prometheus/alertmanager/blob/master/cli/root.go#L61-L63

EDIT:

And it seems like adding https://godoc.org/github.com/spf13/viper#SetConfigType would cover the attempts at reading additional file types.

[juliusv]

@stuartnelson3 Hm, it'd be odd to check in /etc/.amtool.yml though. Config files under /etc/ are usually not dotted / hidden, only homedir ones. So it seems to me that the expected thing to do here would be to change the behavior, not the documentation.

[Kellel]

After re-reading the viper documentation it seems I should have gone the method of putting a config file in a named directory

viper.SetConfigName("config") // name of config file (without extension)
viper.AddConfigPath("/etc/appname/")   // path to look for the config file in
viper.AddConfigPath("$HOME/.appname")  // call multiple times to add many search paths
viper.AddConfigPath(".")       

As it stands it seems I have set the config name to .amtool so it is required

I propose to change the default config file locations to be the following:

/etc/amtool/config.yaml
~/.config/amtool/config.yaml

As far as reading multiple file types that is a feature of viper. I can restrict it if we think that is needed, but perhaps I should just update the docs to notify that all these types are allowed.

[Kellel]

Also can I get a component/cli label on this issue? :smiley:

[Kellel]

842

[Kellel]

Closed my other pr. It needed a rebase. This one is clean

[filippog]

👍 thanks @fabxc @Kellel