Transition to flag based configuration

[tsenart]

Replaces #97

[tsenart]

We'll follow the deprecation cycle mechanism of Mesos itself. Let's not forget to notify the community and users, notably the Mesosphere DCOS team.

[tsenart]

This pretty much summarizes my choice of flags: http://peter.bourgon.org/go-in-production/#configuration

[karlkfi]

I'm ok with flags as long as the docker image comes with a wrapper script to translate env vars to flags.

[sttts]

quoting @spacejam's Dockerfile for etcd:

CMD sh -xc '/work/bin/etcd-mesos-scheduler -alsologtostderr=true \
    -cluster-name=${CLUSTER_NAME} \
    -cluster-size=${CLUSTER_SIZE} \
    -master=${MESOS_MASTER}'

One can do pretty advanced logic with some bash magic there.

[karlkfi]

Sure, but having to run a shell has some serious drawbacks, namely signal handling, verbosity, and having to include a shell in the image in the first place.

For the record, the images currently produced by mesos-dns-pkg have no shell in them. It's just the statically compiled binary and some /etc files.

[sttts]

Even the busybox containers have a shell. If signals are an issue, will `sh -c 'exec ....'`` help?

[karlkfi]

I'm not saying we can't put a shell in the image. I'm just saying that the current packaging doesn't. I'm pretty sure the reason it doesn't is to minimize image size, but it also make debugging harder, because you can't docker exec into the container. I'd probably recommend using alpine instead of busybox, just because it has a package manager which can be very useful for debugging, like if you need to install dig.

As for exec... that should work to propagate signals to a single command.

Tho if you need to do multiple commands for setup beforehand, you wont be able to handle signals before the exec without a trap & wait.

[jdef]

@koziraki was a pretty staunch advocate of the current file-based config. he had concerns about the "command runner" (who executes mesos-dns) having to know the configuration details of mesos-dns at the time the binary was executed, vs just pointing mesos-dns at a location that someone else deals with (the config file).

That said, I'm generally not a fan of having tons of flags for a binary, but I understand the arguments for flags and/or envvar in the context of containerization. I'd actually lean towards envvar to either override, or provide fallback values for, values set in an optional config file (and don't implement the flags approach)-- that keeps about the same distance between configuration and the execution of the binary (at least, more distance than flags) and also allows for easier containerization.

[karlkfi]

Personally, I like how mesos handles flags. I think it's great to have the flexibility to use flags if you want (great discoverability), or use a mix of env-vars and flags (useful in docker-compose, because env-vars can be populated by host env-vars, and cmd args can be shell evaluated after the IP is known), or make a "config file" of env-vars you can manage externally and source easily (useful with upstart).

[micahhausler]

Is this issue just waiting on a PR? I'd be glad to make one, but would like to know if someone is working on this first.

[jdef]

I think the strategy that we tentatively agreed to was flags that default
to the value of the envvar (if defined) otherwise default to the config
file (which has its own defaults) -- and yes, I believe this is just
waiting on a PR, I'm not aware of anyone working on it.

On Wed, May 4, 2016 at 11:20 AM, Micah Hausler [email protected]
wrote:

Is this issue just waiting on a PR? I'd be glad to make one, but would
like to know if someone is working on this first.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#257 (comment)