Should it be the interface, or an abstract network interface type? Are interfaces better represented by "internal, external, fast, private" or by "eth3" which might be different on every minion? Is it reasonable to expect all minions to have the same named interface?

There's a natural tension between people who want to schedule with some
understanding of the underlying hardware and people who want to schedule
abstractly.

IMO we should encourage the latter and discourage the former, but provide
escape hatches to do more "advanced" stuff. I don't think it will be the
normal case for people to want to bind to specific interfaces of the
machine. It should be possible, but I don't think it is the path with the
smoothest surface.

I acknowledge that this note was not helpful in deciding how to do it. :)

On Wed, Jun 25, 2014 at 8:12 AM, Clayton Coleman notifications@github.com
wrote:

Should it be the interface, or an abstract network interface type? Are
interfaces better represented by "internal, external, fast, private" or by
"eth3" which might be different on every minion? Is it reasonable to expect
all minions to have the same named interface?

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

:) I strongly agree on the "encourage abstraction, allow escape hatch" duality here.

Some concrete use cases we've discussed in relation to selecting interfaces

• Deploy a replicated service that wants to use a separate, "internal/private" network interface to route cluster traffic. I.e. mongodb in replica set mode, where the containers in the replica set want to communicate over a private network configured on a specific interface
• As an app deployer, allow choosing to expose ports on an interface that is internal to the network/security group that minions are on, or alternatively expose it on an interface that is reachable by a larger network (other Kube clusters, intranet, internet)
• As a Kube cluster admin, configure a loadbalancer/proxy (Kube proxy, HAProxy functioning in the same role) that is on a specific, reserved device on a set of machines. If the interface isn't available, that's likely to be an error condition (an input to scheduling)

It's also worth distinguishing between the cluster-owner and tenant-user roles - the former has access to make cluster wide decisions and configure minions in very specific ways, the latter only has access to options exposed by the Kubernetes API

This should be resolved with the new chooseHostInterface