Configuration

[jtolio]

Filing an issue so we consider unified configuration of some kind.

Motivating example (though definitely not the only case): let's say a gokit process does want to do Dapper/Zipkin style tracing. The process will need to know where to forward the tracing information to, which won't be known at compile time.

It would be nice if all of the gokit packages were configured in the same or similar way, so that as they are used modularly, configuration of subpackages happens automatically, with little programmer assistance.

[jtolio]

Suggestion: at Space Monkey we just use the flag package everywhere, which is nice, but there's a few drawbacks:

• can't configure through files
• we need to be very careful to limit the scope of flags wrt imports, otherwise if there are flags defined in packages for dead codepaths, that clutters --help and other documentation

The solution we've found for the first problem is https://github.com/spacemonkeygo/flagfile

For the second, we do something like our logging package does: define a configuration struct that the library needs to be set up with, and then optionally register that struct with flagfile.

Concretely, even though we ultimately use flags for configuration, our logging package (spacemonkeygo/spacelog) does not define any flags itself, thereby not cluttering the flag namespace if the user doesn't want to use flags. Instead it defines a configuration struct (https://github.com/spacemonkeygo/spacelog/blob/master/setup.go#L33) that is meant to be used by a utility the flagfile package provides that adds flags based on a configuration struct. For example usage see https://github.com/spacemonkeygo/spacelog/blob/master/setup/setup.go#L40

I think since the flag package is part of the standard library, it makes a lot of sense to expect it to be used by others for configuration, and so we should continue to support it. That said, not every binary wants to use it, and there are useful features to be added.

[peterbourgon]

Specifically re: your motivating example, the problem of "what's the URL for my Finagle server" is solved by service discovery.

More generally, I appreciate the desire for conventions here. But I wonder if this is something that's actually in the domain of "a standard library for distributed systems". Is it necessary that a gokit service have a single mechanism of passing configuration from runtime? Or, further, is it actually possible, given that organizations may have strict conventions on that already?

[jtolio]

It would be best if gokit was as flexible as possible for deployment concerns, yeah, or else it won't take off in existing environments. I don't think it's necessary for there to be a single way, but it would be a shame if the whole collection of gokit packages all used different mechanisms.

As for another motivating example, the gokit log package probably needs to know if the ops person wants logging to go to a file, or syslog, and at what syslog level, etc.

Also, I just filed three issues of stuff I've been thinking about, I don't know if that's the right approach, please tell me to stop if there's something better.

[peterbourgon]

the gokit log package probably needs to know if the ops person wants logging to go to a file, or syslog, and at what syslog level, etc.

Absolutely. The log package will need to allow composition on the input side (what levels you want, what schemas you want to enforce) as well as output (where you want the logs to go: stdout, syslog, rotating files, etc.) But I think the translation of runtime configuration to the structural composition of your log pipeline can be made however you see fit. If your organization uses flags, you can easily do e.g.

var dst io.Writer
switch *log {
case "file":
    dst = makeFileWriter(args)
case "syslog":
    dst = getSyslogWriter(otherArgs)
default:
    dst = os.Stdout
}

It's not obvious to me that gokit should have an opinion on process-level stuff like how to pass configuration.

Also, I just filed three issues of stuff I've been thinking about, I don't know if that's the right approach, please tell me to stop if there's something better.

It's totally fine! There's also a mailing list and #gokit on Freenode. Just depends on your preferred mode of communication.

[freeformz]

How about environment variables following a specific set of prefixes? IMO and generally speaking config files are an anti-pattern.

[peterbourgon]

Some organizations use env vars directly, others use flags, others use config files, others get configuration information from consistent data stores like ZooKeeper... Go kit shouldn't have or enforce opinions about that.

[mreiferson]

these are all process-level concerns... 👍 to gokit not having opinions about this

[freeformz]

@mreiferson that makes sense, up until the point it doesn't. ;-)

[tj]

Agreed that it's not a core concern, you could easily have a suite of configuration packages that tie things together. Ours are all separate components that we just tie together in a Company-specific "context" that all our apps use:

import "github.com/segmentio/apex/reporter"
import "github.com/segmentio/apex/logger"
import "github.com/segmentio/apex/stats"
import "github.com/segmentio/apex/nsq"
import "github.com/segmentio/apex"

Log-derived metrics, stats tickers, publishing to nsq etc are all pluggable and configured from Consul in this ad-hoc layer

[jtolio]

I'm all for having gokit be configured by however the gokit user wants it to be -- I don't mean to specifically prescribe anything about commandline args or env vars or files or whatever, but I do think whatever the configuration system inside the process is it should be consistent.

If a user decides environment variable configuration, that should allow them to configure whatever we choose in gokit that needs configuring, not some subset. Similarly if a user decides commandline args the process should also not be weirdly restrained about what parts of gokit can be configured.

The only reason I mentioned flags in particular is that some libraries already use flags for configuration, being in the stdlib and all.

Out of curiosity, would most prefer GoKit have lots of initial main() function config required? I guess I'm envisioning some kind of gokit.MustStart() call users put in their main() function that does the right thing by default.

[peterbourgon]

The configurable parameters of gokit packages will be first-order language concepts, like choosing between implementations of an interface, or passing specific parameters to constructors, or functional options. There shouldn't be deep integration with any specific configuration mechanism; users should expect to wire up the object graph at program start.

For example, if we use flags to pass runtime config, and if gokit uses functional options, I imagine a simple setup procedure would look something like this:

import (
    "flag"
    "log"
    "time"

    "github.com/gokit/server"    
)

func main() {
    var (
        poolSize     = flag.Int("pool.size", 10, "request connection pool size")
        backoffDelay = flag.Duration("backoff.delay", 100*time.Millisecond, "retry backoff delay")
    )
    flag.Parse()

    s, err := server.New(
        server.PoolSize(*poolSize), 
        server.BackoffDelay(*backoffDelay),
        server.HealthCheck(someFunction),
    )
    if err != nil {
        log.Fatal(err)
    }

    log.Fatal(s.Run())
}

Does it make sense to you?

[jtolio]

Yep, totally. You're advocating against some kind of gokit.MustStart helper function that does all the wiring up for you.

We have something similar to a MustStart helper at Space Monkey which has made creating processes that conform to our consistency needs very easy, but I can see how that wouldn't be particularly useful for a library trying to fit in with lots of different environments.

Configuration through constructors, main() does a lot of manual wiring.

On board.

[peterbourgon]

Great! I think it's totally possible to provide a suite of MustStart wrappers, each one extracting runtime config from different places and according to different conventions. And organizations can implement their own NewOrgServer wrappers, which can set required parameters.

[jtolio]

Yeah, I think I was envisioning that gokit would be an import you could pull into any Go program with very little changes (some startup call in Main, an additional import or two) which was definitely an unstated assumption.

Having a shim that does all the default wiring and config be separate seems like a great separation of concerns, so +1

Would it be worth considering providing a default setup/config/wiring shim that libraries could register with? Much like how you can add drivers to the database/sql package by importing them (import _ "github.com/lib/pq"), perhaps if you're using the default setup/config/wiring shim you get features for free by just using imports?

Example: you are using lots of gokit features, but you haven't pulled in the gokit http server (#2). If you were using a default setup/config system, adding it could be as simple as import _ gokit.io/debug or something.

I guess that's what this issue boils down to. I'm happy if we decide that's out of scope.