+1 I need this functionality

Well to be complete, the etcd client removed the behavior. The question is where are the boundary lines.

Also, it appears this use case is not covered by any level of integration or e2e testing, so we should probably address that as well.

The client still supports it. We adopted the etcd client config file as our own by surfacing it as an arg.

p1, since this is a regression and compatibility issue

@liggitt chatted with @xiang90 today, they are hoping to have a 2.2 update next week-ish.

This should be in 1.2... otherwise we regress function and cannot run against secured etcd, right?

@xiang90 ?

It doesn't look like the etcd folks are going to change the client, I'll get a patch together on this in the a.m.

@timothysc We have a pr at https://github.com/coreos/etcd/pull/4144/commits. We need to test it though.

@xiang90 is the proposed config file compatible with the go-etcd config file format? @timothysc if not, we'll need a release note as well, even if we pick up the config file enabled version of the client

@liggitt No. It is not compatible. I guess k8s user should not depend on the etcd file format anyway.

Too late for that now, it's in the wild... We must support until we can cleanly deprecate.

@timothysc I started a branch a while ago that would populate a new client config from an old config file. branch is at https://github.com/liggitt/etcd/commits/legacy_config (latest commit) if you want to use any of it. I assume we'd have the structs and loaders in k8s

@timothysc We do not have plan to support the old config. The reason is that in the new client, the transport is constructed outside the client and then pass into the client: https://github.com/coreos/etcd/blob/master/client/client.go#L96.

This is very different from go-etcd, which can control the life-cycle of the transport.

@adohe indicated some interest in fixing this. It seems like we would really love a fix.

@lavalamp I will send a PR today.

I am thinking about dropping this to p2, which would mean we wouldn't block the release for it, but we're still willing to take @adohe's change when it lands. How many people would be unhappy with that? We can always cherry-pick it in the future.

If this isn't included in 1.2 then I unfortunately will have to wait on upgrading. :(

Likewise, running with cleartext traffic is not an option for me, so I'd be stuck on 1.1.

@liggitt so should we add the --etcd-config flag back for backward compatibility?

the flag compatibility would be ideal, but I could live with a break there as long as we keep the ability to run against secured etcd

either way, if the flag changes (from a config file to cert/key/ca args), or the format of the config file changes, we need a release note

it's not quite fair to tag this as a breaking change, since the break happened when the flag was removed, but I want to make sure we call out what people need to do to continue running secured

PR is LGTM'd, we're just waiting for a merge.