Why isn't DISCOVERY_URL configurable? about classicswarm

[vieux]

It should definitely be configurable.

Although I'm not sure the discovery service will always stay that simple.

Instead of a ENV var I think we should go toward a new flag with multiple backends like etcd:// zk:// and discovery://

What do you think ?

[ibuildthecloud]

I understand that the API for the service will definitely change.

Only an ENV var would be bad, some something on par with -H and DOCKER_HOST. So --discovery-url and SWARM_DISCOVERY_URL seems appropriate. I agree that etcd://, etc would be better but the current code has no hooks for plugability of the discovery back-end. Should one be added? Should I do this?

[vieux]

I would love to see discovery back-end "plugins"

I think the most difficult is to agree on the UI, here what I have in mind:

1

swarm join/manage --discovery token=XXXXXXXXX
                              etcd=URL
                              zk=URL
                              file=/path/to/file

2

swarm join/manage --discovery-token=XXXXXXXXX
                  --discovery-etcd=URL
                  --discovery-zk=URL
                  --discovery-file=/path/to/file

3

swarm join/manage --token=XXXXXXXXX
                  --etcd=URL
                  --zk=URL
                  --file=/path/to/file

4

swarm join/manage --discovery token://XXXXXXXXX #or hub://
                              etcd://URL
                              zk://URL
                              file://path/to/file

@aluzzardi @ibuildthecloud what do you think ?

[fermayo]

+1 to discovery plugins

I like option 4 above

[thaJeztah]

Option 2 would make it easier/more logical to relate/translate env-vars to options (e.g. SWARM_DISCOVERY_TOKEN <===> discovery-token etc.)

Other options may have their advantages though, so if those outweigh ^^, don't let my comment stop you.

[robhaswell]

I came here to raise this issue, so 👍

My only input would be that this is important enough that we should start with a simple ENV/flag for now, and work towards discovery plugins in the long-term.

[aluzzardi]

I like options 1 and 4 better as they don't require adding "static" flags to swarm every time we add a discovery backend, thus making plugins later down the road easier to implement.

I guess the discovery interface could expose a few functions:

• Scheme() (or Type) returning the discovery scheme (e.g. token, zk, ...). That way we can load a bunch of discovery interfaces and dynamically figure out what service they handle.
• Callback() (or something else) that gets called every time there's a change in the list of nodes. I believe it has to be a callback system rather than a periodic fetch as we have right now since some discovery services work in a push model (etcd, zookeeper).

[ibuildthecloud]

I like option 4. I took the liberty of programming the implementation just for fun, but then realized I did it a bit different.. The PR is #163

What I did was

swarm manage/join --discovery-url hub:// --token XXXX
swarm manage/join --discovery-url hub://customdomain/path --token XXXX
swarm manage/join --discovery-url hub://http://customdomain/path --token XXXX

or

swarm manage/join --discovery-url etcd:// --token XXXX

So the main difference is that every discovery implementation would have some concept of a token. The reason I did this was because of swarm create. Imagine you do swarm create --discovery-url etcd://blah. You would imagine that it returns a new "cluster ID", or token. Then on the next command line you can do swarm manage --discovery-url etcd://blah --token foo. So the discovery url never changes.