[epic] add more options to `service create` / `service update` #25303

Open
thaJeztah opened this Issue Aug 1, 2016 · 88 comments

Projects

None yet
@thaJeztah
Member
thaJeztah commented Aug 1, 2016 edited

The service create and service update commands do not support all options that docker run / docker create supports. Some options are not implemented yet, whereas other options may either not be implemented (because they don't make sense in the context of a service, or are not portable / cross platform).

We should add more options for services, however instead of blindly copying every option, we should make sure the options are implemented properly, which may require using different names for the options and/or different kind of values.

I tried to create an overview of all options on docker run, and to match them with the docker service create options we currently have; I may have missed some, or made the wrong "translation", so input is welcome here

Status Issue docker run docker service Notes
#27902 --add-host
? #27552 (for exec) -a, --attach n/a does not apply to services, as there are multiple containers backing it There may be usecases for this, but design/implementation needs discussion
--blkio-weight
--blkio-weight-device
#25885 --cap-add
--cap-drop
--cgroup-parent
--cidfile does not apply to services, as there are multiple containers backing it
? --cpu-percent
--cpu-period --limit-cpu --limit-cpu sets a combination of "cpu period" and "cpu quota" see #27958 for the docker run implementation
--cpu-quota --limit-cpu --limit-cpu sets a combination of "cpu period" and "cpu quota" see #27958 for the docker run implementation
? -c, --cpu-shares
? #30477 --cpuset-cpus
? --cpuset-mems
-d, --detach -d is the default
--detach-keys No interactive services, so not needed
#24865 / swarmkit #1244 --device
--device-read-bps devices are host specific, so may not make sense?
--device-read-iops devices are host specific, so may not make sense?
--device-write-bps devices are host specific, so may not make sense?
--device-write-iops devices are host specific, so may not make sense?
--disable-content-trust
#24391 --dns PR #27567
#24391 --dns-opt --dns-options, --dns-options-add, --dns-options-rm PR #27567
#24391 --dns-search PR #27567
? #29171 --entrypoint
-e, --env -e, --env
#24712 --env-file PR #24844
--expose
#25317 --group-add --group
#27369 --health-cmd
#27369 --health-interval duration
#27369 --health-retries
#27369 --health-timeout duration
#24877 -h, --hostname
--init
? -i, --interactive does not apply to services, as there are multiple containers backing it There may be usecases for this, but design/implementation needs discussion
--io-maxbandwidth
--io-maxiops uint
#24170 / #29816 --ip does not apply to services, as there are multiple containers backing it. Update: possibly useful to set the VIP
#24170 / #29816 --ip6 does not apply to services, as there are multiple containers backing it. Update: possibly useful to set the VIP
--ipc
--isolation
--kernel-memory
-l, --label --container-label
--label-file
--link will be resolved through --network-alias?
--link-local-ip does not apply to services, as there are multiple containers backing it
--log-driver --log-driver
--log-opt --log-opt
--mac-address does not apply to services, as there are multiple containers backing it
-m, --memory --limit-memory
--memory-reservation
--memory-swap
--memory-swappiness
🔳 --name NOTE: --name sets the service name, not the container's name
🔳 #28573 --network --network Does not support host networking (see #28573), Considering model in swarmkit #1645.
🔳 #28247 -- --network-add/--network-rm are not implemented #28247 docker/swarmkit#1029
#24787 --network-alias
--no-healthcheck
--oom-kill-disable
--oom-score-adj
swarmkit #1605 --pid
#28618 --pids-limit
#24862 / swarmkit #1030 --privileged swarmkit#1722
-p, --publish -p, --publish NOTE: does not support <ip-address> (#26696)
-P, --publish-all when defining a service; explicitly define ports to publish
#30162 --read-only #29972
--restart --restart-condition, --restart-delay, --restart-max-attempts, --restart-window
--rm SwarmKit keeps old tasks (containers) around, but removes them, based on --task-history-limit
--runtime
#25209 --security-opt
#26714 --shm-size
--sig-proxy
🔳 #25696 --stop-signal PR #30754
--stop-timeout New in 1.13 (see #22566)
#28619 --storage-opt
#25209 --sysctl
--tmpfs
#25644 -t, --tty Implemented in SwarmKit docker/swarmkit#1370. Docker PR is #28076
#25209 --ulimit
#25304 -u, --user -u, --user Does not support group / gid (see #25304 (comment))
--userns
--uts
-v, --volume --mount UX improvement needed (add -v flag?)
--volume-driver --mount UX improvement needed (add -v flag?)
--volumes-from does not apply to services, as there are multiple containers backing it
-w, --workdir -w, --workdir
@yongtang
Contributor
yongtang commented Aug 1, 2016

@thaJeztah I saw on #25276 and the above list that --net=host is not supported. That could be a very useful option in some deployment scenarios. I am wondering if there are any technical challenges that prevent the usage of --net=host?

@yongtang
Contributor
yongtang commented Aug 1, 2016

@thaJeztah For --mount there is an open issue related: #25253

@thaJeztah
Member

@yongtang I know that for some options there's additional discussion needed; e.g. --network=host can have some side effects (how does it work in combination with load-balancing? also --network=host can be considered insecure)

@yongtang
Contributor
yongtang commented Aug 1, 2016

Thanks @thaJeztah for the explanation.

@justincormack
Member
justincormack commented Aug 3, 2016 edited

@thaJeztah --ip and --ip6 don't make sense either as there are multiple containers.

@thaJeztah
Member

Good call, I'll edit

@stevvooe
Contributor
stevvooe commented Aug 3, 2016
  • -i is not necessary.
  • --groud-add will be --group.
  • --link and --link-local-ip are never going to be implemented for services.
  • --publish-all doesn't make sense.
  • --cidfile doesn't make sense
  • --volumes-from is never going to happen
@thaJeztah
Member

@stevvooe agreed on most; in doubt on --publish-all, although I can see it possibly being difficult to implement (ports aren't known until the image was pulled / inspected, perhaps that's more difficult in Swarm mode networking)

@thaJeztah
Member

Thinking about --link - providing that may allow for container/service scoped aliasing; but we should analyze use-cases and see if it makes sense

@stevvooe
Contributor
stevvooe commented Aug 3, 2016

@stevvooe agreed on most; in doubt on --publish-all, although I can see it possibly being difficult to implement (ports aren't known until the image was pulled / inspected, perhaps that's more difficult in Swarm mode networking)

This just doesn't make sense. For the most part, ports are already exported on the container's IP. In swarm services, this would bind all ports across the cluster, which isn't useful. The other issue is that the manager has no idea what these ports actually are, without inspecting the image. Exported cluster ports should be considered individually and carefully.

Thinking about --link - providing that may allow for container/service scoped aliasing; but we should analyze use-cases and see if it makes sense

This is provided by overlay networking and network aliasing. In general, --link should be considered deprecated. Interdependent containers don't yield reliable architectures. Dependencies should be resolved before creation (based on a rendevouz value or service name/alias).

@thaJeztah
Member

Yes, implementing --network-alias will probably solve most use cases; we need to think of a UX for that, perhaps that may require a syntax similar to --mount to provide per-network options (see #24787 (comment))

@hvpareja
hvpareja commented Aug 4, 2016

I've also seen the options --env-add and --env-rm in docker service update. They replace --env flag. They seems to be missing in your table.

@thaJeztah
Member

@hvpareja hm, yes, service update has different flags to add/remove options for flags that can be provided multiple times, not sure if we need to include that here, but thanks for the suggestion

@kyhavlov
kyhavlov commented Aug 5, 2016

+1 for being able to set net=host for services, that would be very useful for high performance things that don't want the docker network overhead

@tzz
tzz commented Aug 8, 2016

In our environment we'd like to use --add-host, is that a possibility? Thank you!

@stevvooe
Contributor
stevvooe commented Aug 8, 2016

@tzz How do you use --add-host in your environment? Do you use it to route to external services or internal services?

The reason I ask is we are curious if this belongs on the network, as part of a service or requires a separate abstraction to manager to external service discovery. @mrjana

@tzz
tzz commented Aug 9, 2016

@stevvooe internal services with external visibility. Our problem is that service.wanted resolves in DNS to an external IP address, which is appropriate for some connections, but other connections need the internal IP address for the same service to avoid NAT and routing. Other possibilities for us are dnsmasq and keeping both addresses in DNS, but either way that's a lot more work than --add-host and less dynamic at service creation time. I hope that's helpful.

@stevvooe
Contributor

@tzz Thanks for the explanation!

Would it be correct to say that you want this at the cluster, network or service-level? For example, will have different values for service.wanted depending if you are in different services?

@tzz
tzz commented Aug 10, 2016

@stevvooe for stable environments (production) the lookup can be stable at the cluster or network level. That's our most important use case. For unstable (dev and QA) environments we may need to change the lookup at the service level more dynamically, but that's a less important use case for us.

@drajen
drajen commented Aug 12, 2016

I'm pulling my hair that docker service won't allow -t. Certain apps can't live without a TTY.

@stevvooe
Contributor

@drajen Could you file a bug on SwarmKit?

Out of curiosity, what applications are you running as services that require a TTY?

@drajen
drajen commented Aug 12, 2016

@stevvooe I was running Samba in foreground mode which apparently requires a tty. Check the samba-publicshare image on docker hub. You may easily write a wrapper around it but there might be more breakage out there.

@stevvooe
Contributor

@drajen That is a bummer. I'm really sorry we missed that. I wish someone spoke up in the RC period.

I've submitted docker/swarmkit#1370 and docker/engine-api#364 for service support. We'll have to follow that up with the analogous flags in docker service.

@drajen
drajen commented Aug 13, 2016

@stevvooe thanks for giving this attention!

@vikstrous
Member

I'm so confused "command" for service doesn't override "entrypoint". What does [COMMAND] is the "entrypoint" of the container mean? If I have a container I want to run as a service that already has an entrypoint set in the image, I don't see a way to override it.

@sm0svx
sm0svx commented Aug 15, 2016 edited

+1 on network=host. The lack of this option is basically a showstopper for me since my application connect out to a specific hardware unit using TCP. The unit then send data back using UDP to the originating IP address for the TCP connection. This works well in docker run with net=host but of course fail using the docker0 bridge in swarm mode.

Is there another standard way to solve this without using network=host? New network bridge directly bridged to the physical network interface and using valid external IP-addresses for the containers maybe?

EDIT: macvlan may be a better solution instead of host networking in this case but it's not supported by services. Also, a macvlan network need to be setup on each host in the cluster as it is implemented right now. Maybe some cluster wide setup may be possible to achieve by giving the "docker network" command an interface match condition, like IP-network address or interface name. Then a macvlan network may be setup on all hosts matching the condition in just one command. For the "docker service" command the network specification can be handled as a constraint so that containers are not scheduled on a host that does not have the specified network defined.

However, host networking is much more straightforward to implement but of course less secure. But as long as admins know it's insecure it's their choice to use it or not. It may be just fine in some cases. Kubernetes implement host networking so I guess Docker swarm mode could do it quite easily too.

@stevvooe
Contributor

@vikstrous I'm not sure where you read this, but the statement "[COMMAND] is the "entrypoint" of the container" very confusing and technically wrong. Where did you read this? Let's file a bug to add some clarification there.

This is a long time confusion over a poor choice of wording in the context of Unix history. First off, we have the concept of a command, which is simply an array of strings passed to an executable. This is how we execute a process. All of this language is in the context of assembling a command.

For the purposes of docker, Entrypoint is the default command for an image. It also has a field Cmd, which are the default arguments to Entrypoint. So, without any arguments, the command is Entrypoint + Cmd from the image. The standard invocation of a docker container or service is simply to pass a Cmd to the engine and that will be used as the full command or be appended to the Entrypoint in the image, if it exit to assemble the full command.

COMMAND for a service should be ARGS. The reason it is [COMMAND] in the help output, is that it may be the first entry of the command if Entrypoint is no defined for the image. This cannot be parsed at service creation, since we don't know anything about the image, so we don't know if it can be overridden.

It sounds like your question is asking about why --entrypoint is not provided. The reasoning behind that is it makes less sense in the context of services to run arbitrary commands inside of a container. Typically, --entrypoint is used for interactive debugging, which is the domain of running individual containers, not services. If there is a solid case for a use case to override Entrypoint, we may allow it, as well.

@vikstrous
Member

@stevvooe My quote is from this the description of this issue. It's in the table. I wasn't sure what the story around the omission of --entrypoint was. This makes sense now. I can work around this limitation for our services for now, but my opinion is that --entrypoint should be added to the CLI because it exists in the API (with a different name, but still with the ability to override the entrypoint).

@fanux
fanux commented Aug 19, 2016

We need --net=host , the overlay model will drop our network speed and consume more CPU. We have two network interface, the overlay model will bing a lots of problems to us. If swarm not support the --net=host , we can't use it at all....

@thaJeztah
Member

@fanux can you open a separate issue, and ping me there? Then I'll link the issue from here. --net=host may need some discussion, and probably better to do that on a separate issue. If possible, please include some more details on your use case

@alexellis
Contributor

Hi, there @thaJeztah please can you update the grid with issue #25885 for --add-cap ?

@dhiltgen
Contributor

It sounds like your question is asking about why --entrypoint is not provided. The reasoning behind that is it makes less sense in the context of services to run arbitrary commands inside of a container. Typically, --entrypoint is used for interactive debugging, which is the domain of running individual containers, not services. If there is a solid case for a use case to override Entrypoint, we may allow it, as well.

I can think of a number of images that have multiple tools within them that are all related, and the "default" one is wired up as the entrypoint for ease-of-use. One example is https://hub.docker.com/_/docker/ Perhaps this isn't generally the best practice, but I'm +1 with @vikstrous that lacking the ability to override on service definition forces people to re-generate images that would otherwise be usable as services.

@thaJeztah
Member
thaJeztah commented Aug 19, 2016 edited

@vikstrous @stevvooe sorry, the faulty description is my mistake; I think at some point in the design discussions, we talked about if both ENTRYPOINT and CMD are present in an image, that basically ENTRYPOINT is command, and CMD is args. Following that, docker service create foo -bar would lead to foo being the entrypoint and -bar being an arg, but it's not the case

(I just removed the faulty description)

@dhiltgen
Contributor

@vikstrous @stevvooe sorry, the faulty description is my mistake; I think at some point in the design discussions, we talked about if both ENTRYPOINT and CMD are present in an image, that basically ENTRYPOINT is command, and CMD is args. Following that, docker service create foo -bar would lead to foo being the entrypoint and -bar being an arg, but it's not the case

Actually, I take back what I said... it looks like maybe this is just a doc confusion... The entrypoint of the image is actually overwritten based on the CMD fed to the service definition.

@fanux
fanux commented Aug 21, 2016

Hi @thaJeztah #25873 is a new issue for --net=host.

@cmingxu
cmingxu commented Aug 24, 2016

IMHO, --net=host options should be available only for service with global mode

@cmingxu
cmingxu commented Aug 24, 2016

--add-host, --network-alias, --link need more clarification on how are they functioned and how to use them.

@cmingxu
cmingxu commented Aug 24, 2016

--env-file on which side the file stay, manager? node? or where the command was issued?

@stascode

How about --network=bridge/my_custom_bridge network. Consider a scenario where you need run a bunch of containers in the global mode being able to communicate with each other within the worker host. This option would be somewhat similar to the experimental bundles and stacks.

@gittycat

@dhiltgen I'm not seeing that. With docker service create myimage COMMAND, COMMAND doesn't override the ENTRYPOINT, which is an issue with some images as you've noted.

@stevvooe Thanks for your many comments in multiple issues about this. This whole ENTRYPOINT/CMD/COMMAND is so inanely confusing. I was really hoping that specifying a command at service creation would overwrite ENTRYPOINT. That doesn't seem to be the case unfortunately.

@stevvooe
Contributor

@stascode @cmingxu Adding those isn't as simple as adding the flags. I'd recommend taking that discussion to another issue. They need to be thought through in detail.

@dhiltgen Many images have tools embedded, but do they make sense to run as services?

@gittycat I hope my comments have helped. All the COMMAND fields (from help output) are simply passed as args to ENTRYPOINT. This is the way docker run has always worked. There is a flag --entrypoint on docker run that allows one to override it. If you build an image without an entrypoint, COMMAND will be used as the effective entrypoint.

@gittycat

@stevvooe I understand that. The problem as you know is that there isn't a way to override entrypoint when creating a service. The only work around is create our own custom images to reset ENTRYPOINT:[] when it's already defined in the base image.

@stevvooe
Contributor

@gittycat Ok, great. We are on the same page.

It sounds like you want --entrypoint similar to what is in docker run.

@gittycat
gittycat commented Aug 31, 2016 edited

@stevvooe My preferences are (in that order)

  1. Make the service command overwrite the image ENTRYPOINT and CMD.
    Eg: docker service create someimage echo "hello" should always echo "hello" independent of what's in the image ENTRYPROINT and CMD.
  2. Add --entrypoint to the docker service create|update api. That's still confusing but at least we can overwrite the entrypoint, which isn't the case now.
@hervenicol

Hey all,

I'd rather like second choice from @gittycat , as it's the way it has always been with either docker standalone or classic swarm.

I, as well as lots of people, have already created images that take advantage of this entrypoint / command logic. If the «command» arguments to «service create» override the entrypoint, that's going to be a mess !

@gittycat

@hervenicol As @stevvooe mentioned in some other post, this is a chance to get things right by removing the confusing mess that is entrypoint/cmd. Once entrypoint is added as an option to docker service, we'll be stuck with it forever.

I strongly prefer the first option; override entrypoint/cmd by the service command.

@hervenicol

If docker chooses to go that way, then entrypoint should be also deprecated on standalone docker.

But I think the entrypoint / command is convenient, once you understand it.

For instance, if you look at how to run a consul image (https://github.com/gliderlabs/docker-consul/tree/legacy):
docker run progrium/consul -server -bootstrap
You don't have to care about what's the path/name of the app, all you want is to know its parameters.

And if you're looking for some help, you run
docker run progrium/consul --help
or even
docker run progrium/consul

I think it is VERY convenient, and this behaviour would be broken if entrypoint/command dissociation was removed.
I'd rather go fore some disambiguation in the documentation.

@gittycat

@hervinicol Yes, you describe the whole reason for having an entrypoint. It makes it possible to treat a container as if it were an executable. It's nice at first but I personally have stopped using this. I much prefer having things explicitly visible in docker-compose or in command line scripts. For each image that I use, I always end up having to go to the Dockerfile to see what the ENTRYPOINT/CMD are.

@stevvooe
Contributor
stevvooe commented Sep 1, 2016

@gittycat @hervenicol While we've pretty much deprecated the concept in the Service API, deprecating entrypoint in docker run and docker service create is pretty much a non-starter.

Likely, the solution will revolve around @gittycat's option 2.

@shenshouer

any idea for swarm mode support host networking ?

@Tchinmai7

A --security-opt option in service will make Checkpoint Restore easier!. so far, Trying CR with docker service always fails during the checkpoint time!

@gittycat
gittycat commented Sep 18, 2016 edited

Moved comment to related issue #25209 (comment)

@thaJeztah
Member

@gittycat #25209 is for tracking that option for services, perhaps you can add your use case there as well. One challenge will be to add a custom profile for services, as that would mean that the actual file containing the profile is present on each node (unless we store its content in the service definition @justincormack?)

@pugnascotia
Contributor

This might be a different issue, but I'd like to see an option on service create that specifies a delay before a container is consider in-service. The use case is where you're doing a rolling update to a service, and it needs some amount of warm up time before it can handle requests. If you're relying on the routing mesh for load balancing and you get an error because a container isn't ready yet, you can't tell if the service is broken or a particular upstream container isn't available because you're using a virtual IP. Hope that makes sense.

@hervenicol

@pugnascotia , today I guess you can do it with update-delay.

But for a better solution, IMO that should be handled through healthchecks. If your container says it's healthy only when it's «warm» and ready to serve requests, it should be the time when:

  • this actual container is enabled in the IPVS
  • next container starts being deployed (maybe after waiting for update-delay).
@pugnascotia
Contributor

update-delay doesn't help in this case because that (AFAICT) controls the time gap between finishing the update of one container and starting the update of the next. I agree that some kind of healthcheck mechanism is the way to go.

@stevvooe
Contributor

@pugnascotia @hervenicol This issue is about discussing the flags from docker run in the context of docker service create. For generic feature requests, I'd recommend opening up an issue. There are a number of issues regarding IPVS, so checking out some those might help you find what you're looking for.

@richardjq

@thaJeztah please add --time to this list. As in 'docker stop --time=120 foo' or in swarm-speak 'docker service rm --time=120 foo'

I'm having to run apps unclustered because 10 seconds isn't long enough for a clean shutdown.

Thanks!

@dnephin
Member
dnephin commented Sep 27, 2016

@richardjq this option already exists as --stop-grace-period

@richardjq

@dnephin Awesome! I didn't think to look on the create/update command. Thanks!

@g0nx
g0nx commented Sep 28, 2016

Whats happen with --hostname option? I think it is very important because there are a lot of scenarios in which your containers need to have hostname like example.com because the certificates. For example I need to communicate a rest service with a oauth service and it is only possible throw hostname oauth.example.com (I have a crt with *.example.com within this container).

I hope that is clear...

@thaJeztah
Member

@g0nx see #24877 for the discussion on that one (it's linked in the table at the top)

@g0nx
g0nx commented Sep 28, 2016

I have already read this thread but I can't see if this option going to implement to the next version or not... And the most important thing, when?

@thaJeztah
Member

@g0nx that decision will be made on that issue, not here (so far, no decision was made)

@g0nx
g0nx commented Sep 29, 2016

@thaJeztah ok! Thank you very much for your attention!

@cezarsa
Contributor
cezarsa commented Oct 4, 2016

Regarding healthchecks, would simply exposing --health-* and --no-healthcheck flags in docker service create be an acceptable solution? I imagine encoding them inside the swarm.ContainerSpec instance and just using them when creating new containers for the service. I could work on a PR for this if no one has started yet.

@errordeveloper
Contributor

@thaJeztah was nice meeting you in Berlin last week! Could you please add docker/swarmkit#1605 for --pid=host... Thanks 👍

@thaJeztah
Member

@errordeveloper likewise! I added it to the table

@merijnv
merijnv commented Oct 12, 2016 edited

Somewhere this was asked about--add-host:

Do you use it to route to external services or internal services?

We want to have an MQ, which is running on a native OS rather than within docker, and reach that by name. We do not control the DNS resolving, so I would like to add 'my-queuing-server' as an ip-address in /etc/hosts as seen by the container.

@BretFisher

@thaJeztah should we also add lack of affinity in services to this list?

RE: docker/swarmkit#1442

@stevvooe
Contributor

Update on host-level networking: we are discussing a simplified model in docker/swarmkit#1645. It would allow containers to be exposed on both the host-level network and any swarm overlay networks that may apply. Still need to figure out what --network=host might mean, but it could be as simple as "the network is off and the ports are exposed". Port locations would be exposed through swarm managers.

@mostolog

Hi.

Does docker services support multiples ports exposed/published for a service?
Seems docker service create --publish 8080 --publish 8888 doesn't work...
Regards

@stevvooe
Contributor

@mostolog Could you please file a separate issue? We need to keep the discussion here focused.

@kleptog
kleptog commented Nov 2, 2016

One thing I don't see on this list in docker service update --network-add and --network-rm. These are being tracked at docker/swarmkit#1029.

@adityacs
adityacs commented Dec 20, 2016 edited

Any update on providing cpu-quota and cpu-period values while creating a service in swarm mode?

@ventz
ventz commented Dec 31, 2016

@thaJeztah In regards to the:

"--ip and --ip6 don't make sense either as there are multiple containers."

It makes sense to have them set the VIP address. There are many cases where the IP needs to be statically set/available ahead of time/specially provisioned/etc.

@thaJeztah
Member

@ventz can you open a new issue for that, and describe the use case(s) there? I'll link the issue in the table then. Out of curiosity; those cases cannot use a hostname only an IP address? (include that in the use-case description as well)

@ventz
ventz commented Jan 2, 2017 edited

@thaJeztah No problem, I'll create one now - Thanks.

(edit: created #29816)

@mostolog
mostolog commented Jan 10, 2017 edited

Does name templating (https://github.com/docker/docker/blob/master/docs/reference/commandline/service_create.md#create-services-using-templates) work within compose files for docker deploy? Should it? Is documented somewhere?

Is there any doc page about what is "id, slot and all that fields"?

@stevvooe
Contributor

@mostolog It should but that is off topic for this particular issue.

@piersharding

Hi -

I am working on an HPC project that would need to achieve CPU pinning for containers so that specific tasks run on the appropriate CPU as well as speak directly to the host network adapter (a topic covered well by others above). This could be achieved by having a head node task (perhaps on the swarm manager node) that uses docker swarm to run an agent container on each compute node launched as a service and then each agent container could then launch the appropriately configured task containers locally using docker run --cpuset-cpus="1,2" etc. However, it would be much cleaner/nicer to manage the entire deployment process through docker swarm so that orchestration features would not need to be implemented in the agent nodes simplifying the entire orchestration control structure.

On this basis I would like to vote for the inclusion of the --cpuset-cpus parameter.

Thanks,
Piers Harding.

@thaJeztah
Member

@piersharding could you open a separate issue, then i'll link to that issue from the table above

@piersharding

@thaJeztah thanks - I have created issue #30477 .

Cheers,
Piers Harding.

@mrueg
mrueg commented Feb 9, 2017

Is the table missing --init? Would be interesting to have that in services as well.

@thaJeztah
Member

@mrueg good catch; it was added in 1.13, so not a thing when this table was created originally

@genki
genki commented Feb 11, 2017

I think --volumes-from could be applicable to the volumes of services that are mode=global.

@ventz
ventz commented Feb 13, 2017

@thaJeztah Referencing: #30963

This is the perfect use case for --ip for the service:

Mariadb Galera (mysql DB cluster) -- needs to exchange the nodes involved ahead of time. You can use name, but the --hostname makes it so that the node itself resolves to its second IP vs what the rest of the nodes resolve it to, which is first ip. If we can specify the IP statically, they can be pre-configured ahead of time by IP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment