POC: watch config files to load/unload maps

[jchamberlain]

This is a first draft to demonstrate an approach to solving for #944 (Dynamic loading of maps). This is not meant to be ready for merge, but I've run it locally and it works well so far. This is now ready for review. Please give it a spin, and I'd love your feedback on the acceptability of the overall approach. Thanks!

New Abstraction

The central new idea/concept/abstraction is the "App". (I'm sure there's a better term for this, but bear with me.) An App is a collection of providers and maps which share a lifecycle. They are loaded into a Tegola instance as a unit and, when no longer needed, unloaded from Tegola as a unit.

The base TOML configuration file may contain an initial App which will never be unloaded. (Which is to say, the [[providers]] and [[maps]] section of the TOML file still work exactly as expected.)

Configuring Tegola to load Apps dynamically

A new, optional section is added to the base config, [app_config_source]. It includes a type plus any options required for that source type. The only option for the "file" type is dir which sets a directory from which to load apps.

[app_config_source]
type = "file"  # could also be "s3" or "redis" or any other source type someone wants to implement
dir = "./apps" # if relative, this path is relative to the location of the regular config file

Add any TOML file to that directory and its [[providers]] and [[maps]] will be registered immediately. Delete the file, and they'll be removed.

Key Implementation Details

The config/source package has been added providing ConfigSource and ConfigWatcher (implemented only by FileConfigSource so far):

type ConfigSource interface {
	Type() string
	LoadAndWatch(ctx context.Context) (ConfigWatcher, error)
}

type ConfigWatcher struct {
	Updates   chan App
	Deletions chan string
}

The initConfig process of Tegola's root command has been augmented with initAppConfigSource(), which starts a goroutine to receive updates and deletions from the ConfigWatcher channels.

To ensure that apps are loaded and unloaded as a unit, Atlas has been given two new methods, AddMaps() and RemoveMaps(). Name collisions are checked before adding any maps to Atlas, so that we don't quit partway through having added some maps but not others.

[gdey]

Not the direction I was initially thinking, but it seems workable. Things I'm worried about:

Leaking resources, especially database connections. I don't see providers being unregistered when shutting down. I've left a few comments. I will need to build this branch and play with it with a sample dataset.

[jchamberlain]

I don't see providers being unregistered when shutting down....

Good catch, @gdey. My impression was that providers lived only as pointers on each map, but I didn't realize each driver/provider type is keeping track of its instantiated providers. This causes a couple problems with my approach:

1. There's no master list of all providers, so we can't check for name uniqueness. (This PR is ok with that—names must be unique only within an "app" because only maps in the app can use its providers, so there's no ambiguity.)
2. Without unique names, drivers/provider types don't have a way of unloading individual providers.

How important is it for the Driver/provider type to keep track of its instances? What if we instead kept a master list of all providers, and added a Cleanup() method to Tiler and MVTTiler?

Actually, if we add a Cleanup() method to each provider, we don't need a master list. We can grab the provider from the map(s) as we unload the maps.

[jchamberlain]

Actually, if we add a Cleanup() method to each provider, we don't need a master list. We can grab the provider from the map(s) as we unload the maps.

Despite my previous comment, I ended up creating a global list of provider instances in provider/provider.go. However, I prefix their names with a namespace (in the case of app config files, the file name) so uniqueness is required only per "app".

[gdey]

Just a quick review since the code review changes. I will look at this again once the other two PRs ( #949 and #952 ) have been merged.

[jchamberlain]

I have not forgotten this. My work has been focused on integrating our other systems with Tegola since Tegola is working well enough already, but I'll have some time later this month to get back to working on Tegola itself. I'll add the experimental guard to this PR as per @ARolek's request.