I also get that we're arguing TIMTOWDI vs YAGNI. So, I want to take a beat to say that I think your take is absolutely valid, but I'm coming at this from a place where flexibility isn't my primary concern. I'm usually more interested in tools that will reliably save me time, and that's a quality typically in opposition to flexibility.
For me, any tool that requires or permits multiple configuration planes to get off the ground threatens to be a time sink and a tax for an already packed schedule. This complexity usually requires the operator to absorb a lot of nuance, quirks, and idioms, which is something that's difficult to do quickly. Troubleshooting also grows in scope , again due to the complex design and multiple ways to set things up. Meanwhile, the most inflexible tools in my stack cause me the least trouble due to their simplicity: there's one way to do it, and if it's a common mistake, the answer is easily searched online.
In practice, looking to the Traefik community for support required decoding everyone's different take with varying degrees of CLI and config file involvement, sometimes fragmented across entire discussion threads (not to mention the v1/v2 problem). It made for a very time consuming troubleshooting run - something that would have been avoided by a more simple design like other tools use.
- Having documentation split between v1 and v2, that is similar yet different enough to yield half-baked configurations before you realize what you did wrong. The website itself provides the barest of subtle changes to distinguish the two. Edit: I learned all this prior to v3.
- Supporting multiple config formats (TOML and YAML) which makes it that much harder to hunt down relevant forum posts for support. That wouldn't be a huge problem if it weren't for things that you need that aren't in the documentation (above)
- Multiple configuration _modes_. You can set options on the CLI, or in config files, and they are not 100% reflected between the two; some things must be in config files no matter what. Config files themselves are split between "dynamic" and "static" configs, and you must place the correct options in the right file.
- The one thing that Traefik does well is routing traffic to/from containers. Container labels are used to drive this. How to map those label namespaces to various internal and user provided aspects of Traefik is unclear in the docs, at best.
- Traefik exposes a dashboard web GUI by default. Yet much of the useful diagnostic and troubleshooting information is only found in the container logs.
Retiring v1 completely, picking a single configuration language/mode, and providing a rich library of example docker-compose configs, would go a very long way to securing this project's future.