Configuration

[eirslett]

How should we configure zipkin-collector/query/web? The present way is to use Scala code with eval, @adriancole says Twitter has done a lot of refactoring in their apps later, now might be the time to use Twitter flags instead? We would lose the possibility of writing Scala code in the configuration, so it might be a little more difficult to set up backends as people wish. Another option I suggest is to use typesafe config, which has a pretty flexible setup.

Possible alternatives:

• Config as Scala, eval (like today)
• Twitter flags (runtime command-line options)
• Something else

Thoughts?

[codefromthecrypt]

At Twitter, static config that varies by environment is passed via flags or in some cases json files. These are set in pants args when running a process on laptop or in Aurora config.

The most thought in this area has been in Finatra. A part of this was spinning out a project to address config, as particularly the lack of testability has been troublesome. For example the most recent apps can be spawned safely managed by a test lifecycle (embedded).

https://github.com/twitter/finatra/blob/master/inject/README.md

Hope this helps!

[eirslett]

One thing that separates Zipkin from in-house applications is the need to replace backend technologies like Cassandra/MySQL/HBase. So simple flags might not be enough - e.g. MySQL may have other configuration options than Redis. In that regard, configuration as code is actually quite nice...

The way we configure Zipkin today (with Scala files and eval) is actually quite close to Spring XML configuration, except it's Scala, so we actually ship the Scala compiler with the Zipkin distribution (which of course increases artifact size and dependency tree quite a bit). I think we even load the Scala compiler in-memory as part of Zipkin, but I'm not quite sure how the eval module is written.

[dsyer]

My comment from #526:

Spring Boot would also provide a nice abstraction for externalized configuration (properties, YAML, command line, system properties, env vars). You wouldn't need a huge raft of dependencies just to bind to the environment - probably just a couple of extra jars. And it has support for executable jars in a nicer format than the shadow ones.

It wouldn't involve writing XML unless you really wanted to (XML is a valid, but infrequently used, format for Java Properties). The only dependencies you would need would be spring-boot and spring-context (plus a few transitive dependencies). Possibly you could even get away with just spring-boot and spring-core (very thin). (Plus the executable jar thing if we use that.)

[eirslett]

If you take a deep look at the config stuff, there's actually a lot going on besides just setting properties, like wiring in resolvers for looking up Cassandra (ZooKeeper or static), injecting custom stats integrations pr. service (statsd maybe) and so on. I'm not sure if that can be expressed in a clean way just by using properties?

[jorgheymans]

Zipkin uses spring-boot configuration mechanisms nowadays, i think this issue can be closed.