Remove configuration flags

[tmrts]

I've been inspecting the use of flags throughout the code to find a better solution. Storing configurations in etcd seems like a good solution(that's what etcd does after all) as discussed in #1627. Is there anyone working on this? I would like to give it a shot.

[tmrts]

@smarterclayton @thockin @bgrant0607

[eparis]

To the best of my knowledge no one is working on this. However, a lot of work has been done so that etcd is not exposed to the nodes. The nodes only talk to the api server (which obviously in turn stores in etcd, so yes, the node config could live indirectly in etcd).

As to master config, again, only part of it talks to etcd (the apiserver, the scheduler and controller-manager both can/should be insulated from etcd).

So this is a great goal, but most configs will need to be exposed by the apiserver, not directly by etcd.

[tmrts]

So, creating a configuration object and exposing it through the API is a prerequisite. I'll start with the configuration objects then.

[thockin]

Yeah that issue should be updated to say "in API"

On Tue, Mar 17, 2015 at 8:45 PM, Eric Paris notifications@github.com
wrote:

To the best of my knowledge no one is working on this. However, a lot of
work has been done so that etcd is not exposed to the nodes. The nodes only
talk to the api server (which obviously in turn stores in etcd, so yes, the
node config could live indirectly in etcd).

As to master config, again, only part of it talks to etcd (the apiserver,
the scheduler and controller-manager both can/should be insulated from
etcd).

So this is a great goal, but most configs will need to be exposed by the
apiserver, not directly by etcd.

—
Reply to this email directly or view it on GitHub
#5582 (comment)
.

[bgrant0607]

As per:
#1627 (comment)

Take a look at the secret API:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/api/v1beta3/types.go#L1292

It makes a key-value map available via a volume to containers. A slight tweak on this plus tooling in kubectl could be used for general configuration.

[tmrts]

I've done the initial implementation. But, before proceeding any further with tests and the kubectl integration, I wanted to ask if this is the direction we want to take.

@bgrant0607 @thockin @eparis Please take a look at #6245

[bgrant0607]

Another example problem: #10489

Flags are a horrible configuration mechanism:

• They are neither versioned nor scoped.
• They are not friendly to version skew (e.g., flags that don't exist in a particular version).
• They can't be changed dynamically.
• We don't really control the mechanism(s) by which they are specified on the command line: shell scripts, init scripts, unit files, ..
• We don't control the mechanism(s) by which they are distributed: Salt, Ansible, Chef, Puppet, rsync, ...
• Alternative values generally have poor test coverage.

We need to treat component configuration as a versioned API with a well defined schema, similarly to kubeconfig and the scheduler config. As with API fields, removal of fields or changing their semantics are non-backwards-compatible changes, which will break turnup scripts/configurations. Some fields might be more properly actual API fields.

We should also just remove as many knobs as possible. We're copying bad internal practices by proliferating flags. Not only do flags dilute code coverage, but requiring elaborate configurations for reasonable behavior is just asking for a high support burden. Alternatives include internal constants, receiver/interface parameters, plugins, dependency injection, factories, heuristics, and self-configuration/self-tuning.

[roberthbailey]

/cc @mikedanese

Closing as a dupe of #12245.