I think this is intended for 1.9, so adding it to the milestone :)

We're in code freeze, I let @tiborvass decide but we should only be accepting bugfixes.

@icecrime i understand. This is one of the requests that pretty much all the network plugin devs requested for. Its infact discussed in various libnetwork PRs. We couldnt get it in before because of various UX uncertainties. This also brings the network create ux inline with volume create for all the drivers. Since this is a very small patch but have a huge upside for the external plugins, I request you to consider getting this useful patch in. btw, the risk is very low because, we have been using the driver-opts backend from 1.7 release onwards for the default docker0 bridge.

👍 for having this in 1.9
Those affected - or at least those that I remember having asked for this are: @tomdee, @thockin, @shettyg, @squaremo, @erikh and @FlorianOtel
As we've missed code freeze on this one I'd appreciate if you could let us know the impact to your projects, if any, of this slipping to 1.10

@dave-tucker

Labels support is very important for my plugin. Unfortunately, just the label support passed to network create does not add a lot of value for me (others may have a different requirement). I would really like labels support for both network create as well as endpoint create.

I think not supporting options in 1.9 is pretty much a bug, otherwise people won't be able to configure networks.

On a higher level, most of us would really love to have libnetwork used for all our docker networking needs. It so happens that most of us (plugin writers) have our own networking backend with our own special needs. A little bit of extra help via labels lets us have a good integration of docker with the underlying infrastructure.

@shettyg I realized very late that the primary reason for the confusion is the word label. Though it carries the same map[string]string such as the -opt, it has a different meaning altogether.
Hence, we must be calling these driver-opts in order to differentiate itself clearly from labels.

Infact the reason this PR was split from #16910 because of that confusion.

By having this PR in, users can configure flexible driver options while creating the network. It is a first step towards future enhancements..

@mavenugo
Driver options for network create will be a welcome iniital addition.

@mavenugo any way we can have a test case?

@calavera i added a simple test in integration-cli/docker_api_network_test.go.
Since these are driver specific options, the functionality is entirely driver specific and we cannot add a test case for that. All we can make sure is that the options configured by the user is properly processed at the libnetwork level and returned back correctly in the inspect (which is covered in the above test).

@calavera i can possibly add a dummy remote plugin and make sure the passed options infact reach the dummy remote plugin. Do you think that works ?

@mavenugo I would think so yeah 👍

A dummy remote plugin would really help with testing. During libnetwork development, remote plugins have been broken too many times because of a lack of automated testing.

And as I said in #16910 (comment) , network labels would be nice to have.

@tomdee Thankfully that's not true anymore. We do have automated testing in libnetwork which employs a dummy remote plugin in many of our tests to make sure there are no regressions in remote plugin protocol.

👍 That's good to hear!

@mavenugo @mrjana if we already have a dummy plugin in libnetwork, we can probably port it to use it here easily if we add it to the testutils package in libnetwork, we don't need to duplicate it 😸

https://github.com/docker/libnetwork/tree/master/testutils

@calavera @vdemeester udpated with comments addressed.
Yes, I already had a dummy network plugin added in the existing tests and am reusing it for this -opts case.

awesome, thanks.

LGTM

LGTM

I'll be cherrypicking this to 1.9 because it was originally bundled in another PR that was later merged but we were the ones who asked to move it to a separate PR.

thanks @tiborvass @calavera @icecrime you made network plugin devs very happy.

Just asked @moxiegirl and docs-changes for this will also be in a separate PR that brings in all changes related to networking, so

docs LGTM

@mavenugo yay cool 😻 👍

@mavenugo sorry needs a rebase :(

nooooooo!!!!!!!!!! 😿

oh noooeeesss 🙀

:) done. checker PR(s), pls show some mercy.

@mavenugo conflict was only in tests?

@mavenugo @tiborvass yeah, only integration tests, my bad 😱

It's green 🎉