Support for config directory as parameter

[ipasic]

Hi,

currently Tegola requires specifying a single config file using the --config parameter, which is not ideal hen managing multiple apps or tilesets with different config files. To simplify this process, it would be beneficial to allow specifying a config directory instead. This enhancement would enable Tegola to load and serve tiles based on multiple config files within the specified directory.

Proposed Solution:

Introduce a new command-line parameter, such as --config-dir, to specify a directory containing multiple config files. Tegola would then load and serve tiles based on all the config files within that directory, allowing simultaneous streaming of tiles for different apps or tilesets.

Hope you will consider this enhancement request.

Best regards,
Ivan

[iwpnd]

Hey,

I don't see how a config-dir would work. Tegola would need to read, merge and validate those different configs. If one of those configs is corrupted, you'd block the startup for every other.

If you want to use multiple configuration you're free to do so. You can start more than one tegola process each with a different configuration. No changes required.

[ipasic]

Hi,

I still think it would help in certain cases, at least for my use cases, but I'm aware that's not maybe of great use for other users so it doesn't make for you to spend time and effort on it.

In each case, thanks for the answer and wish you to keep up the good work.

Best regards,
Ivan

[iwpnd]

Can you share more detail on the use-cases you imagine?

[ipasic]

Yes, so the goal would be to run multiple Tegola instances (configurations) within one process. Like that, the config files (toml) could even be programmatically created and placed into the predefined config directoty which Tegola process would use. Ideally, Tegola would recognize when there are some file changes and auto-restart.

Like that, the users could automatize the development and the deployment pipeline of their custom apps because they would not need to setup new systemd process every time, but instead having it configured once, and then take care just of properly defining (even through the code) their toml configurations and place it at pre-defined location.

Or to put it more simple, imagine user have 10 different databases, and he needs to serve vector tiles for multiple tables from each of thos databases. It makes sense to separate it then in different configurations, but it doesn't make sense to run 10 system services for each configuration, at least in my eyes.

Maybe i'm missing something ?

[iwpnd]

From a reliability perspective I would argue, that different configurations should be separated into different deployments. If it's okay for you to use multiple configurations in the same tegola deployment, then why separate the configs in the first place? Tegola is okay with handling more than just one database connection (now) in the current HEAD.

Ideally, Tegola would recognize when there are some file changes and auto-restart.

Here im resonating with you, that would be a nice addition. You could host configuration elsewhere, any blob storage really, and Tegola would (optionally) poll for updates to the config and restart.

[ARolek]

Ideally, Tegola would recognize when there are some file changes and auto-restart.

It's technically possible, just not implemented. It might be better to send tegola a reload signal somehow instead of pooling.

You could host configuration elsewhere, any blob storage really, and Tegola would (optionally) poll for updates to the config and restart.

Tegola can remote load a config if you provide a https location to the config flag.

@ipasic can you help me understand the scale you're trying to operate at? Are you looking at 10s of configs, 100s, 1000s? I agree that the current config approach is not ideal if you're trying to manage a lot of different map configurations via the same tegola server. It's an interesting problem to think about though, and I'm sure a more robust config loader could be designed.