Skip to content

Add new flag to completely disable service discovery#17375

Closed
aidanhs wants to merge 1 commit intomoby:masterfrom
aidanhs:aphs-container-discovery
Closed

Add new flag to completely disable service discovery#17375
aidanhs wants to merge 1 commit intomoby:masterfrom
aidanhs:aphs-container-discovery

Conversation

@aidanhs
Copy link
Copy Markdown
Contributor

@aidanhs aidanhs commented Oct 26, 2015

This is an alternative approach to #17325.

The problem is the tension between:

  1. people who want service discovery by default and now rely on it (me)
  2. people who don't want service discovery at all (@thockin)
  3. people who want service discovery at a network granularity
  4. people who want service discovery at a container granularity

3 and 4 are not relevant in this discussion since they're not available yet.
#17325 resolved the issue with corruption (#17190) by disabling discovery on the default network. This doesn't really help if you want to use networks.

This is a blunter (granularity on the daemon level), yet more configurable (it's not hardcoded) approach. I would expect this to, in time, be extended with granularity on the network level and granularity on the container level.

It

  • doesn't break backwards compatibility
  • allows totally disabling service discovery of any kind
  • (I feel) is more aligned with "batteries included but removable".

@mavenugo @thaJeztah (not sure who else is interested)

(there will be test failures, I want feedback on design and whether this has hope in any incarnation of being merged)

@aidanhs
Copy link
Copy Markdown
Contributor Author

aidanhs commented Oct 26, 2015

A mention of a quote by @icecrime #17190 (comment)

Docker philosophy is to provide a consistent experience backed by swappable implementations. Docker 1.8 has been out for a couple months now, and users have come to expect that containers discover each other as they start: giving the option to disable it makes for very different user experiences depending on the daemon configuration.

I agree with the above, but unfortunately the current solution is "break the current expectation" which I don't think is a good solution.

@aidanhs
Copy link
Copy Markdown
Contributor Author

aidanhs commented Oct 26, 2015

I'm also considering just implementing 3 (i.e. being able to enable/disable service discovery on a network level), which seems like a better approach if this PR has no chance of ending up in 1.9.0.

@aidanhs aidanhs mentioned this pull request Nov 2, 2015
Merged
@mitar
Copy link
Copy Markdown

mitar commented Nov 2, 2015

This would be really great to have!

@LK4D4
Copy link
Copy Markdown
Contributor

LK4D4 commented Nov 13, 2015

@aidanhs seems like it didn't get to 1.9. Do you want to close it and open another PR?

@aidanhs
Copy link
Copy Markdown
Contributor Author

aidanhs commented Nov 13, 2015

I'm pursuing this via moby/libnetwork#722, which will (eventually) allow you to modify settings of networks, specifically enabling and disabling service discovery.

This will probably take a while given it needs to go PR -> review -> libnetwork merge -> docker libnetwork update, but it's the best option I can see for now.

@aidanhs aidanhs closed this Nov 13, 2015
@aidanhs aidanhs deleted the aphs-container-discovery branch November 20, 2015 17:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

status/1-design-review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@aidanhs @mitar @LK4D4 @calavera @GordonTheTurtle