Maps has three highly-overlapping functionalities that should be partitioned/combined better:
- Kartotherian serves tiles via a public endpoint. It simply gets the tiles from the predefined set of tile sources, without much processing.
- Tilerator generates tiles and stores them. It takes jobs from the Redis que, gets tiles from the tile source (e.g. SQL tile generator), and puts them into a different tile source (e.g. Cassandra). Tilerator does not really need a UI/endpoint access, especially due to the fact that service runner runs multiple instances on the same port, thus making it impossible to control each instance individually.
- Admin UI is a tool to do job scheduling and que manipulation, but it does not process jobs. Multiple instances of Admin UI should not run on the same port because an admin may change its internal configuration during runtime, and subsequent requests might go to a different instance, causing confusion. Currently, Admin UI is implemented as a special setting in Tilerator -- runs it in a non-tile-processing mode.
Additionally, we need Admin UI to generate and serve tiles, just like Tilerator+Kartotherian, so that admins can preview the results of the tile generation before running expensive or complicated jobs. Currently we do it by setting up a private Kartotherian instance in production, manually configuring it with the new settings, and using it via an SSH tunnel - an error-prone process.
- Config-based: Most of the functionality in the 3 components is highly intertwined, so we could merge it all into one repository, and control which functionality is enabled via a config parameters. There will be 3 puppet modules, but they will all point to the same gerrit deploy repository. The repo will contain two different tile source files - one for production and one for tile generation/admin. The puppet-created config will specify which tile source file to use, and will also enable admin interface and job processing functionality. On tin, we will have 3 deploy dirs, but all of them will point to the same git repository.
- PROS: code consistency, no dups, easier to maintain and manage, fewer repositories.
- CONS: have to be a bit more careful not to expose admin functionality publicly
- Create 3 separate repositories, one for each "service", and rely on a common lib to do everything. The common lib in turn will rely on all the tile source libs (cassandra, generator, styling, layer mixers, etc), plus the core (utils) lib. This approach is almost the same as first, except that it brings a lot of code duplication (duplicate of the service template and service initialization), and will differ just in the endpoint setup.
- PROS: Easier to fork services, more hardcoded separation with the admin interface
- CONS: Harder to maintain and deploy, significant code duplication, possible bugs due to dups, repository proliferation.