Add docker run --net=network:<net-name>

[thockin]

As per networking BoF, add the missing UI to have a container join an
extant network. There is a wart whereby a service is actually created and
published with the same name as the container. Before committing this,
I would argue to fix that and hide that detail of the implementation.

Signed-off-by: Tim Hockin thockin@google.com

@squaremo @mavenugo @mrjana @lxpollitt @ibuildthecloud @errordeveloper @vbatts @bfirsh @mrunalp @rajatchopra

[FlorianOtel]

+1 based on today's discussion. Adding @abhat

[rajatchopra]

Doesn't the networkDriver need be recalculated or am I missing something.

[thockin]

Rajat,

I don't think so - this invocation path will never create a network - it
just references an existing one. If you refer to a network that does not
exist, this will fail (which is what we want, right?)

On Tue, Jun 23, 2015 at 7:49 PM, Rajat Chopra notifications@github.com
wrote:

In daemon/container_linux.go
#14143 (comment):

@@ -803,6 +803,11 @@ func (container *Container) AllocateNetwork() error {
return fmt.Errorf("conflicting options: publishing a service and network mode")
}

• if mode.IsNetwork() {

•   parts := strings.SplitN(string(mode), ":", 2)
  

•   networkName = parts[1]
  

Doesn't the networkDriver need be recalculated or am I missing something.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/14143/files#r33113600.

[rajatchopra]

Yes. You are right. I didn't follow the code path correctly.

[lxpollitt]

+1 based on the feature based on our discussions today and the feedback we have from our users. +1 on fixing the wart before committing if possible. (Happy to consider alternative syntax if people have strong views so long as the syntax are the same.)

[squaremo]

Also a +1, and thanks to Tim, from me.

[spikecurtis]

+1

[erikh]

+1!

[abhat]

Thanks Tim! +1.

[tomdee]

+1

[shykes]

Not sure I understand the difference with --publish-service, is it simply that the service name is not specified by the user, but defaults to the container name or id instead?

[thockin]

The argument is that the concept of "service" should not be part of the UX
at all when you are just running a container that is a consumer of services
but not a provider. Joining a network is a facet of the container.
Service is a layer on top of that.

There was some ... let's call it "strong" sentiment about this at the
networking BoF.

The fact that this PR still implies a service and that the implied service
is actually VISIBLE is the aforementioned wart. We should do something
like decree "services that start with _ are hidden and can not be created
by users" and then generate an _${RANDOM} name for this. It's an
implementation detail.

On Fri, Jun 26, 2015 at 9:47 PM, Solomon Hykes notifications@github.com
wrote:

Not sure I understand the difference with --publish-service, is it simply
that the service name is not specified by the user, but defaults to the
container name or id instead?

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

[shykes]

Service discovery is a fundamental aspect of this design, and has been for 6 months now. I remember clearly explaining it at the dockercon eu ecosystem meeting. The reason is simple: if we don't define a standard interface for service discovery, we allow for fragmentation and incompatibility between certain plugins and certain apps. Anything that breaks "every plugin works with every app" is a non-starter.

This design is popular with users. To my knowledge it does not introduce any new problems for users, and it solves many. If you have arguments to the contrary I am happy to hear them.

[shykes]

Your explanation of "container that consumes services but does not expose them" is a good argument for finding a word other than "service". My favorite other candidate is "endpoint" since it works for bi-directional connectivity.

I think it makes sense to have an "invisible" setting for consume-only endpoints, which removes them from discovery. They should still be endpoints, since certain properties are useful for both directions (for example port redirect rules). It's also useful for endpoints to have names even if they are not discoverable: if only to designate them for management.

how about:

docker run --connect-as db.myapp
docker endpoint set db.myapp invisible=1

Note that invisibility of endpoints is a nice to have. Even if a db can discover the web node that consumes it, there is no security consequence since only exposed ports are allowed through anyway. This maps the reality of the system where usually on a given network every node can resolve the hostame of every other node, even if they can't reach them.

[lxpollitt]

One use case I've heard come up multiple times with our users is for short lived containers that may have a lifetime of <100ms. (e.g. Spark containers.) Forcing each of these to be available via service discovery is likely to impact scalability for large deployments. I think this is a reasonable real world example, and backs the idea that having an "invisible only endpoint" option to get a container onto a network without publishing as a service has value.

[shykes]

Yeah that makes sense to me.

Note that you can run containers without connecting them to a shared network at all, which would solve that particular problem.

[errordeveloper]

Note that you can run containers without connecting them to a shared network at all, which would solve that particular problem.

Only if the container is completely self-sufficient and isn't expected to consume any services.

[errordeveloper]

On separate note, if the intent of consuming a service has to be expressed explicitly, there has to be some kind of wildcard approach as well. Moreover, what is there to consumers advantage that such explicit expression of dependencies will bring?

Also, @shykes, you said:

docker run --connect-as db.myapp
docker endpoint set db.myapp invisible=1

Do you mean connect as a client to db in myapp? If so, it would make much more sense to say --requires-service db.myapp, as all I can see this can sensibly express is the dependency on given service. May be access control can be somehow implied too, but that widens the scope too far, making it nearly inconceivable, I'd find.

That said, there probably exists some grand idea of service discovery semantics, but before climbing that high, a whole bunch of folks here are in need of a simple low-level solution that provides a way of associating containers with new networking subsystem, which is meant to be pluggable and extendible... However, at the moment it looks like one needs to go indirectly through this discovery subsystem that is anything but mature.

[thockin]

@shykes:

Service discovery is a fundamental aspect of this design

I'm not arguing that service discovery is not important, I'm arguing that not every endpoint is a service. You've conflated two (important, good) ideas into one franken-concept. There is a cost to participating in service discovery - that cost should be optionally borne by only those things that actually want to offer service (not getting into what that means here).

It's fine to make the implementation of both discoverable and non-discoverable endpoints use the same basic mehcanism, as long as the publish part of it is an extra step. An "invisible" endpoint that bypasses publishing is what I was proposing, and it sounds like that is basically acceptable to you?

docker run --connect-as db.myapp
docker endpoint set db.myapp invisible=1

Maybe I misunderstand - why make this two operations? The invisibility isn't really something users want on its own, it's an implementation detail. I think the default could go the other way - assume private unless explicitly published. The layering is much simpler to comprehend if "publish service" is
an extension of "join network".

As it is today, every container is on a network, right? If you don't say otherwise you get put on the default network with a made-up name (which by the
way is insufficient as a primary key across nodes). This PR just grants the user control over that decision by the mechanism they already know: --net.

Now being able to publish for discovery can be added purely on top of this - as a 2nd imperative step or as part of the same run command. The layering is cleaner, the concepts are additive and map to things the industry already understands.

[shykes]

Yes an invisible endpoint is totally acceptable. The only question is how do we manage their names.

I understand what you mean with the layering. We had assumed that the name is always present, and given in the same way, whether the EP is invisibleor not.

An alternative would be to give a unique ID to each endpoint, and only assign a name when it is (optionally) made visible.

Wdyt madhu @crosbymichael @icecrime ?

[shykes]

@errordeveloper no, you completely misunderstood. There is no concept of dependency. The word "connect" was meant as "connect to the network" but the fact that you didn't understand tells me that it's probably not the right word.

The "immature" system you speak of is basicay this: associate names to IPs and make them available to containers via hostname lookups. It's straightforward and useful, and is not forcing you to "work around" anything.

[thaJeztah]

An alternative would be to give a unique ID to each endpoint, and only assign a name when it is (optionally) made visible.

I like that thinking, gives a nice parallel with other parts of Docker. Would end points also be accessible/discoverable through their ID? If so, have IDs priority over names (as is the case for container ID vs name)

[ibuildthecloud]

There seems to be two (unrelated) objectives between the participants here. 1) how do we logically describe the relationships between components in an application. 2) how we expose low level networking to containers.

For "2" I have no clue what the UX should be. I understand very well the implementation details but I've yet to get many users actually ask me for this capability. So I shall punt to those more invested in the topic.

For "1" I'm very interested in the UX. All that I would like to see is that containers can publish or consume a named service in a scope. Done and done. So for each container you just say it consumes X or publishes Y in scope Z.

[ibuildthecloud]

Alright, I think I found the solution to everyone’s problems (I’m joking, I know how complex this topic is). Back to my previous comment, I feel there are two concerns here. First how do I expose low level networking concepts to containers. Second, how do I express relationships between components in an application.

Low Level Networking

I really struggle with what the UI should be for low level networking in containers. In the grand scheme of an application platform, low level networking probably shouldn’t exist. I put the configuration of low level networking more on par with namespace control. Something like --pid=host is super low level, makes no sense in an application platform, yet is really, really useful in a generic container sense. Frankly RancherOS wouldn’t be possible without --pid=host. Many of us have been through the fabulous journey that was OpenStack Neutron and know just how easy it is to create useless networking APIs. We shouldn’t attempt to do the same. We shouldn’t sugar coat or abstract low level networking for those that want to control it. Here is what I propose. We introduce a new networking mode called “advanced”. It could also be called “running-with-scissors”, “i-know-what-i’m-doing”, or “i-did-stay-at-a-holiday-inn-express-last-night”. We then introduce an --iface flag so you could do the following:

docker run --net=advanced --iface eth0,driver=foo,opt1=blah,opt2=blah2 --iface eth1,driver=bar

The --iface argument would be the format IFACE_NAME,driver=NAME,key1=value1,key2=value2 where key1/value1, key2/value2 would be passed to the driver. This style follows closely with how qemu configures networking. In this approach we do not have an other concept than an interface. If one uses advanced networking mode certain features of Docker will not work just the same as --net=host prohibits certain features.

Services

In order to express relationships between components I do believe service and scope are the correct terms. And the corresponding verbs being publish and consume. A container publishes a service to a scope and other containers can consume services from some scope. Publishing a service means that the container advertises itself by name in some scope. Discovery will most likely be DNS so that means that a DNS entry will be created for this container. Consuming a service means that the consumer can reference a service by name. If it does not consume a service that service should not be resolvable by name.

Let walk through some examples.

docker run --name foo nginx

In the default case the container is neither publishing or consuming any service. For backwards compatibility this container will publish service foo in scope default. This will make a bit more sense when I talk about linking later.

docker run --name foo --publish service_scope/service_name nginx

This container will publish service service_name in scope service_scope. It will also publish foo in scope default.

docker run --name client --consume service_scope/service_name:web nginx

This container will consume service_name in service_scope as web. The aliasing is quite important and done for the same reason as link aliasing. The intention being that there need not be an pre-agreed upon name between publisher and consumer as to avoid tight coupling. This container will also publish service client in scope default.

docker run --name client consume service_scope

In this situation the container will consume all services in the scope service_scope.

Scopes

We do not explicitly need scope operations. Scopes can dynamically come and go as they are used. If we add scope create/ls/rm they are mostly for convenience and don't add significant value. In terms of compose a compose template should by default map to a single scope. A special syntax of something like publish: /foo and consumes: /foo should be supported. This syntax means "publish as foo in my current scope" and "consume foo in my current scope". This will allow you to do something like docker-compose -p app1 up and docker-compose -p app2 up and project app1 and app2 will not conflict with each other as they have been placed in scope app1 and app2 respectively.

Link compatibility

In order to support links in a backwards compatible way all containers will by default publish a service to scope default with the name the same as their container name. Then

docker run --link foo:web

becomes shorthand for

docker run --consume default/foo:web

The only different is that in this special case we add environment variables in the container to emulate the old behavior of links.

Publishing multiple containers of the same service

What happens when two containers publish the same service? I know there will be a bit of a debate on this one. I personally don't like magic and I think the safest solution is usually the simplest. In the situation that two containers publish the same name, then when looking up a service by name, you should get two results. In the terms of DNS this means multiple A records. An alternative idea is that they should be automatically load balanced. I am not in favor of this. Instead if somebody wants 'web' to be load balanced they should publish a load balancer as web that consumes a scope and adds all services in that scope which would be containers web1, web2, web3.

But what happens if the load balancer dies. I think a separate concept should exist that gives somebody the ability to have a VIP. Something like docker vip --publish service_scope/service_name --consumes service_scope. The problem is that if we magically load balance I think we exclude use cases. I feel better exposing low level primitives. If we find it to be too verbose we can always add sugar to the UI to simplify common operations.

[mrjana]

@shykes @thaJeztah We already provide a unique ID to endpoints for every endpoint that is created. So if an endpoint needs to be created implicitly then the changes in this PR are the only ones needed to achieve that. But right now we assign the container name to such endpoints and they become discoverable using that name. The only additional thing that would be preferable is to make these endpoints entirely not discoverable and completely hidden from the service discovery layer. It's only a simple change to achieve that.

In essence I do agree with the layering that this will provide i.e container which just needs connectivity will connect to the network with implicit endpoints and the container which need to be network wide discoverable will attach to an already published service endpoint.

[mrjana]

@ibuildthecloud It seems you are proposing something very different from what is being discussed here. Let's not derail this discussion with that proposal since this discussion is getting somewhere. You could create another issue and document your proposal there so we can discuss there. WDYT?

[squaremo]

The architecture of libnetwork does not privilege the network named "bridge" above any other network created via the bridge driver, or any other driver, including plugin drivers. It seems natural to extend this into the user interface by letting a user refer to any network where they would refer to "bridge". I don't see how this represents a conflation of high-level and low-level.

In any case, let me state my interest: I think users should be able to join containers to an plugin-provided network, without reference to services. Not everyone wants or needs service discovery -- for instance people who are driving docker via other tooling -- and those who do, don't necessarily want to name every container on the network as a service. As @lxpollitt pointed out, discoverability is different to reachability.

Expanding the meaning of --net seems to me to be a simple and obvious way of achieving the above; and it will work, with little to no intervention, with existing tooling including Swarm and Compose. If it must be something other than --net, please at least let it be simple and obvious.

[erikh]

I think neither solution is mutually exclusive with each other, but it feels like we’re trying to force it in one direction instead of accepting that. I don’t see the point in that. Whether it’s a best practice or not, lots of people are going to want flat networks and direct addressability. Castrating the feature does not really serve anyone, as this discussion has indicated; nobody is really saying “this doesn’t work”, they’re saying “this isn’t right for docker” and I think that’s inaccurate simply by the number of people fighting for this feature in this thread.

I would really like to see both service discovery and direct network management in docker and I really don’t see why we can’t have both, or why the UX has to be perfect; I think in practice most of the people who will want these kind of features want config files instead of CLI arguments anyway.

I certainly understand there’s a lot of resistance to new arguments/syntax at docker because of “you have to support it forever”. I don’t think this is bad at all (hi, volume syntax), but we’re splitting hairs over a 10-line patch largely for people who will type whatever they need into bash to make docker use a specific network (I’m looking at you, pipework).

Let’s not fight the tide of desire and instead embrace it.

On Jun 29, 2015, at 3:05 AM, Michael Bridgen notifications@github.com wrote:

The architecture of libnetwork does not privilege the network named "bridge" above any other network created via the bridge driver, or any other driver, including plugin drivers. It seems natural to extend this into the user interface by letting a user refer to any network where they would refer to "bridge". I don't see how this represents a conflation of high-level and low-level.

In any case, let me state my interest: I think users should be able to join containers to an plugin-provided network, without reference to services. Not everyone wants or needs service discovery -- for instance people who are driving docker via other tooling -- and those who do, don't necessarily want to name every container on the network as a service. As @lxpollitt https://github.com/lxpollitt pointed out, discoverability is different to reachability.

Expanding the meaning of --net seems to me to be a simple and obvious way of achieving the above; and it will work, with little to no intervention, with existing tooling including Swarm and Compose. If it must be something other than --net, please at least let it be simple and obvious.

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

[ibuildthecloud]

I've heard over and over again that we should separate networking from service discovery and I agree. The problem with this PR is that it is presenting networks as a networking concept but I believe the real intention of "networks" in the UI is really a misnomer for "scope" in the context of service discovery. We should absolutely give people the ability to control the networking as an administrative function, but the current approach is going to cause problems. Let me give a more concrete example.

Imagine an enterprise has a requirement that they want all container to be placed on VLAN 42 but then production containers would be put on VLAN 43. In the DockerCon hackathon somebody already started working on a VLAN extension to libnetwork and you can expect a real VLAN driver will appear. So now that we have networks it would make sense that I would create two networks in Docker called "dev" that is VLAN 42 and is the default and another called "prod" that is VLAN 43. Depending on where your container should run the user then does --net=network:dev or --net=network:prod.

The problem with this scenario is that networks are not being exposed to the developer as a tool they can use. They are controlled by NetOps/Sysadmins. In every single exchange with @shykes regarding networks is the reoccurring topic is the we are exposing a concept to developer so that they can describe relationships between their containers. You hear ideas thrown around like "every docker compose file will create a network" and such. Those concepts can not be done if networking is controlled by an infrastructure team and not the developer.

@shykes has asserted that networks is a concept that makes sense to developers. I would tend to agree with @shykes as really most developers don't understand networking, so their concept of a network is something logical like "dev", "prod", "the internet." The problem though with the term "network" is that it confuses the hell out of networking and infrastructure folks. They immediately think of VLANs, subnets, etc.

I propose the current UI should be services and scopes. This more correctly describes the real intent of the current UI. Now this does leave real networking folks without a solution though. I think we should pursue a low level simpler approach that just exposes all the knobs. I like @erikh idea of maybe something that is config file based. We have a lot more flexibility in the config file because that is not really a developer facing interface.

[spikecurtis]

@ibuildthecloud I agree that your VLAN example is problematic, but my view is that VLAN as a technology is simply a poor choice for implementing different reachability domains for precisely the reason you mentioned: NetOps and sysadmins control it. VLAN IDs are a scarce resource and already have meanings within the enterprise network. VLAN is just a bad technology for this requirement. People being what they are, some people might use it.

And yet, developers still need a tool that controls what containers can talk to what other containers, not just what names resolve to. There exist network technologies (not based on VLAN) that can provide those arbitrary reachability domains ("network" in the current CNM) for the developer, c.f. Calico, Weave, the new Overlay driver, etc.

I'm fine with the service name "scope" being the same as network reachability "scope." But we do need a way to connect a container to networking and select the reachability without insisting it publish a service name.

[FlorianOtel]

+1 @erikh @thockin @ibuildthecloud @squaremo et. al.

Saying that "developers don't understand networking" and forcing the exposure of low level networking primitives via a "service" -- which is as vague as a concept as you can get, as we all agreed at the round table at DockerCon-- is prescriptive at best, condescending at worst (fine line there...)

(As a side note, I'd rather point out to the fact that in @erikh original CNM proposal -- #9983 -- concept of "service" was not included, and rightfully so)

Please keep separate "network" (==collection of endpoints able to communicate with each others e.g. via a "flat network") and "service" (whatever that means). To yours truly (and several above) they are fundamentally different as layers of abstraction -- very useful in their own respect, but different. So please do not conflate them in the name of "simplicity" and "avoid fragmentation and incompatibility".

Afterall, the mantra always was " batteries included but removable "

Thanks.

[kelseyhightower]

This PR makes sense to me mainly because it's the expected behavior I had in mind when I heard about Docker gaining support for advanced networking features. I always imagined Docker supporting both the low level case where I want a container to join a specific network, and the high level case that would improve the UX around Docker links and service discovery. I feel this PR is a step in the right direction where Docker continues to offer "power" users and "platform" builders the flexibility to try new ideas without working around the Docker APIs (http and cli).

[jainvipin]

+1 for this PR
To me, network is not a low level construct, it is a collection of endpoints that represent a logical group. Therefore providing a construct to allow grouping of endpoints will permit network functions to apply policies across those logical group of applications - a high level construct for networking functions.

[dave-tucker]

I've had some discussions with a number of libnetwork contributors and we've created #14593 to cover the immediate changes we'd like to see to the UI to handle a number of use cases with both Docker and Docker Compose. This includes using --net=NETWORK in favour of --net=network:NETWORK which I would imagine would only be a minor update to this PR - if there are strong arguments either way I would also be happy to update/change the issue I linked earlier.

To all those who have already commented here, it would be fantastic to get your feedback on the issue that we raised as we move towards stabilising the UI!

[lxpollitt]

+1 for #14593 and removing the "network:" prefix. The only restriction this puts on users is that they cannot create networks using names that conflict with the existing built in names (such as "bridge"). That seems reasonably to me.

[icecrime]

@dave-tucker Does it mean that the subject will continue being discussed on docker/libnetwork side? Do we still need this PR against docker?

@thockin Is it ok with you?

[thockin]

I have been away for a while, I was literally just reading this and
responding. Is it subsumed by other work?

On Thu, Jul 23, 2015 at 11:12 AM, Arnaud Porterie notifications@github.com
wrote:

@dave-tucker https://github.com/dave-tucker Does it mean that the
subject will continue being discussed on docker/libnetwork side? Do we
still need this PR against docker?

@thockin https://github.com/thockin Is it ok with you?

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

[thockin]

I was pretty busy the last few, weeks, I am going to comment as I catch up
on the thread all in one post.

@ibuildthecloud said

We introduce a new networking mode called “advanced”

I am in favor of more control BUT I think that's a different topic than
what this PR originally was aiming for. Given the extant networking model,
all this PR advocates is that joining a network not use the words "publish"
or "service".

If it does not consume a service that service should not be resolvable by
name.

I am not sure I agree with this. There are reasons to have "global"
services that nobody declares consumption of, but many people consume.
Monitoring services, Logging services, cluster master interfaces, etc.
Likewise, there is a need for some global services to reverse the flow and
connect to ~every endpoint, again think monitoring or logging.
Pre-declared services might be the norm, but they shouldn't be the only.

The examples you provided omit all mention of the network CLI, which is OK
for demonstration, but sort of apropos to this PR and the idea therein.

But what happens if the load balancer dies. I think a separate concept
should exist that gives somebody the ability to have a VIP.

If I want an HA service, and that is pretty much expected these days, I
need a turtle at the bottom of my stack that is so unlikely to fail that is
it effectively guaranteed. A random app container is not that turtle. A
set of N replicas can be. How do you provide HA across N replicas? You
can use multi-A DNS as you suggest, but let's remind ourselves that, to a
first approximation, every single DNS client in the world is broken. They
all cache things they should not cache and they do not respect TTL.
Providing DNS to a set of IPs that might change over time should be the
exception, not the rule.

The other alternative is a load-balancer which fronts backends. A large
fraction of workloads today are load-balancerable - their backends are
fungible. You suggest having users run their own LB, but then you ask the
right question: what if ti dies. Well, SPoF is bad, so you need N
load-balancers. You have reduced the problem to a previously unsolved
problem - how do I publish a set of N IPs? DNS is still bad for all the
same reasons as 30 seconds ago.

So you introduce VIP. But it has to be multi-endpoint VIP. Which is a
load-balancer (of sorts). The other alternative is to VIP every container
IP, which gets expensive and complex pretty fast.

If you accept that lots of apps want HA and that load-balancers are the
best/easiest way to get HA, and that you have to implement some form of VIP
anayway, why would you thrust that work upon your users? Are you angry at
them? :) Take it with a grain of salt, because I am obviously biased, but
the Kubernetes answer is much more user-friendly. We'll set up a simple
LB for you. Our LB is intrinsically HA because it is offered by the host
the client is running on. Je pense donc je suis. If the host is not alive
to load-balance, the client isn't either.

There are cases for which LB is not right, but they appear to be the
minority.

@mavenugo said

conflating both the low-level networking concept and the high-level
service scope into the --net run option seems incorrect

I'm confused - I am trying to UN-conflate those layers. What in this PR
makes you think I am conflating them?

@ibuildthecloud said

Now this does leave real networking folks without a solution

It's worse than that it's a half-solution because all of the other network
related commands are now either useless (I can define a network but not
join it) or misnamed (rename it all to 'scope' so I have an "overlay scope"
and a "bridge" scope - yeeick). The ability to define overlays makes
networking in Docker finally useful. But the current UX is only 2/3 baked.

If you want developers to talk in terms of scopes, make scopes imply
networks. But don't take away my ability to ignore scopes and instead talk
about networks.

@dave-tucker said

This includes using --net=NETWORK in favour of --net=network:NETWORK

How do you disambiguate a network named "container" from --net=container:id
? The reason I did it this way is that it is 100% unambiguous and follows
current convention.

I'll go look at #14593 now

On Mon, Jul 13, 2015 at 10:31 AM, Alex Pollitt notifications@github.com
wrote:

+1 for #14593 #14593 and
removing the "network:" prefix. The only restriction this puts on users is
that they cannot create networks using names that conflict with the
existing built in names (such as "bridge"). That seems reasonably to me.

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

[tiborvass]

Ping @mavenugo @dave-tucker @mrjana

[vbatts]

@thockin said

If you want developers to talk in terms of scopes, make scopes imply
networks. But don't take away my ability to ignore scopes and instead talk
about networks.

+1 here. This was the consensus of everyone at the table @ dockercon in June. Allowing for this will enable more external usage of the libnetworking rather than having folks work around it.

[cpuguy83]

This looks like it is happening as part of #16645

[tiborvass]

@thockin I'm closing this PR for now since it seems you are in contact with the networking team and they opened #16645. Let us know if this is incorrect.