[WIP] make start.config non-mutating

[deads2k]

In an attempt to unravel start.go, I started by preventing the mutation of the start.config object. Once it is set by the command, nothing else mutates it and every method built upon it is a distinct call that does all the reparsing necessary to allow getters to be called in any order. I recognize this as inefficient, but it makes for straightforward to answer the question "how do I get this value?" That was the first problem I hit.

I still need to add unit tests and rebase.

@liggitt Comments on the approach before I sink more time into it? You may want to begin in start.go's start() method and imagine yourself tracing through to figure out how to add a parameter or figure out why MasterPublicAddr is wrong.

[liggitt]

node

[liggitt]

Wondering if addresses and certs should be sliced by server. Feels a little weird to have multiple config structs spanning the same servers.

[liggitt]

make these local vars to make sure things just look at the individual start flags?

[deads2k]

make these local vars to make sure things just look at the individual start flags?

turns out they are needed elsewhere. See the comment commit

[liggitt]

doesn't update etcdaddr any longer

[liggitt]

use net.SplitHostPort, and handle an error condition by just returning theUrl.Host. same below for hostofhost and getport

[liggitt]

shouldn't this be using cfg.BindAddr.Host still? (or a cfg.GetNodeBindHost() which would do the same thing, but is more testable)

[liggitt]

could keep using cfg.BindAddr.Host (which holds host separate from port), and drop the getHostOfHost() (or call cfg.GetEtcdBindAddr() which does the same, yadda, yadda, yadda)

[liggitt]

Actually, it looks like we're counting on etcd defaulting to binding on 4001 when we don't specify a port. Should probably have GetEtcdBindAddress() which does net.JoinHostPort(cfg.BindAddr.Host, strconv.Itoa(cfg.EtcdAddr.DefaultPort))

[deads2k]

@smarterclayton I think it's a lot safer than you'd expect. Turns out that once it's more reasonably factored, it's possible to write unit tests that cover the edge cases that gave us fits before.

Unit tests cover the defaulting and computation behavior of getters. They also cover the bindings of the command to the config itself.

I'm working on an integration test to demonstrate a method for launching an all-in-one for integration tests.

[liggitt]

@deads2k the last bit I want to adjust/test is the --kubeconfig / --master interactions in all-in-one and node modes. After that I'll be comfortable with this. I'm working on those tests tonight.

[liggitt]

@deads2k finished --kubeconfig stuff, added tests, restored some current behaviors (running with --kubernetes without --kubeconfig is currently allowed, etc). I squashed your commits into one and my commits into one, and spawned a new PR at #1156... wasn't sure what your schedule was.

[deads2k]

replace by #1156