Proposal: Allow user to set own service defaults

[olljanat]

Description
Currently service defaults are set on:
https://github.com/docker/swarmkit/blob/b6a4260bcd2c3e8550d6535c787fb7395f73af9c/api/defaults/service.go#L11-L41

but it would be very useful to be able set own Swarm wide defaults for placement, failure action, restart condition, etc...

[thaJeztah]

I recall there have been some discussions around this. While I can see this being useful, there's also quite some things that should be taken into account, and a proper design would be needed to outweigh all the pros and cons, e.g.

• pro: can be easier to deploy
• con: the client currently has no way to know what the defaults are (this is a recurring issue. Also see add cli integration for masked and readonly paths docker/cli#1347 (comment), dockerd -h does not display some default value for options  moby#27663, Docker help isn't as helpful anymore w.r.t. options moby#18797, CpuShares default value in docker inspect is 0 moby#35452 (comment))
• con: if the defaults are dependent on the environment, we could get into situations where "it works on my swarm". I think this is a big concern. Having a way for the client to know the defaults would help, but may not resolve that entirely
• related to the above; if we do have a way to communicate defaults, the CLI / client could generate the full specification for the service (1. fetch the defaults; 2. apply configuration as specified by the user; 3. send the spec to the daemon).
• question: should defaults be applied at the initial deploy of a service only? What do we want to happen if the defaults change, and a service gets re-scheduled? What if the service is updated ? (This issue has come up for docker run, where changing the default dns, logging driver, and/or its configuration and that configuration not being applied to existing containers)

[olljanat]

Good points

• con: the client currently has no way to know what the defaults are (this is a recurring issue. Also see [add cli integration for masked and readonly paths docker/cli#1347 (comment)]

IMO, something like fake service where defaults are set would work and they would be visible with command like docker service inspect defaults

• con: if the defaults are dependent on the environment, we could get into situations where "it works on my swarm". I think this is a big concern. Having a way for the client to know the defaults would help, but may not resolve that entirely

This can be avoided by clearly decide which settings are configurable like this. On DevOps working model it is many time these OPS guys who want to have control which nodes services are actually running. DEVs are just interested that they works 😉

• related to the above; if we do have a way to communicate defaults, the CLI / client could generate the full specification for the service (1. fetch the defaults; 2. apply configuration as specified by the user; 3. send the spec to the daemon).

IMO, client should see full spec.

• question: should defaults be applied at the initial deploy of a service only? What do we want to happen if the defaults change, and a service gets re-scheduled? What if the service is updated ? (This issue has come up for docker run, where changing the default dns, logging driver, and/or its configuration and that configuration not being applied to existing containers)

If I have understood current logic correctly these would be changed on when services are updated next time. Need to bit think about if that is good enough.

[thaJeztah]

IMO, something like fake service where defaults are set would work and they would be visible with command like docker service inspect defaults

Actually; I just recall this conversation docker/cli#291 (comment). Also moby/moby#32284, so there's some options already

This can be avoided by clearly decide which settings are configurable like this. On DevOps working model it is many time these OPS guys who want to have control which nodes services are actually running. DEVs are just interested that they works 😉

Agreed; possibly not the same options as you were thinking, but (this one was a long time ago, before swarm); one of the examples that came up in that discussion; e.g. having a default volume-driver, default logging-driver, default networking-driver. (For those we also discussed having "aliases" for certain class of drivers (a default could be defined for certain classes; a volume driver suitable for "temp", "local", "shared" use e.g.)

If I have understood current logic correctly these would be changed on when services are updated next time. Need to bit think about if that is good enough.

Yes, this is a tricky one, because either could make sense, depending on the use-case. In some use-cases you'd definitely not want service-definitions to be updated, unless asked for explicitly.

Perhaps a --update-defaults could work, but that would add additional complexity (how to determin if a value was explicitly set in the original deploy (but matched the default), or was left "undefined", causing the default to be applied).

For the above; if we want the defaults to be updated (instead of "baked in"), one approach would be to leave "defaults" empty in the definition, and merge the defaults when presenting the information (docker service inspect); moby/moby#32284