Repository navigation
Changing amount of replicas for swarm produces more changes than expected #958
Copy link
Copy link
Closed
Description
General Information
docker-java version: 3.1.0-SNAPSHOT
docker-compose version: docker-compose version 1.17.1, build 6d101fb
docker version: Docker version 17.09.0-ce, build afdb6d4
Problem
Iterating over my services received via DockerClient#listServicesCmd() and then scaling them up with
/* some example code to explain - variable "service" is a service from the iteration and "dockerClient" is an instance of DockerClient */
ServiceSpec serviceSpec = service.getSpec();
ServiceModeConfig serviceModeConfig = service.getSpec().getMode();
ServiceReplicatedModeOptions serviceReplicatedModeOptions = service.getSpec().getMode().getReplicated().withReplicas(2);
serviceModeConfig = serviceModeConfig.withReplicated(serviceReplicatedModeOptions);
serviceSpec = serviceSpec.withMode(serviceModeConfig);
dockerClient.updateServiceCmd(service.getId(), serviceSpec).withVersion(service.getVersion().getIndex()).exec();produces an interesting diff:
"Spec": {
"Name": "<NAME>",
"Labels": {
"com.docker.stack.image": "<IMAGE_NAMESPACE>/<IMAGE_NAME>",
"com.docker.stack.namespace": "<NAMESPACE>"
},
"TaskTemplate": {
"ContainerSpec": {
"Image": "<IMAGE_NAMESPACE>/<IMAGE_NAME>:latest",
"Labels": {
"com.docker.stack.namespace": "<NAMESPACE>"
},
"Env": [],
- "Privileges": {
- "CredentialSpec": null,
- "SELinuxContext": null
- },
"TTY": true,
- "OpenStdin": true,
- "StopGracePeriod": 60000000000
+ "StopGracePeriod": 10000000000,
+ "DNSConfig": {}
},
"Resources": {
"Limits": {
"MemoryBytes": 536870912
}
},
"RestartPolicy": {
"Condition": "none",
"Delay": 5000000000,
"MaxAttempts": 3,
"Window": 20000000000
},
"Placement": {},
- "Networks": [{
- "Target": "fzmfcwseizy9l7xtbbeq8fuh8",
- "Aliases": [
- "hub"
- ]
- }],
"ForceUpdate": 0,
"Runtime": "container"
},
"Mode": {
"Replicated": {
- "Replicas": 0
+ "Replicas": 2
}
+ },
+ "UpdateConfig": {
+ "Parallelism": 1,
+ "FailureAction": "pause",
+ "Monitor": 5000000000,
+ "MaxFailureRatio": 0,
+ "Order": "stop-first"
+ },
+ "RollbackConfig": {
+ "Parallelism": 1,
+ "FailureAction": "pause",
+ "Monitor": 5000000000,
+ "MaxFailureRatio": 0,
+ "Order": "stop-first"
},
"EndpointSpec": {
"Mode": "vip"
}
}
- "Endpoint": {
- "Spec": {
- "Mode": "vip"
- }
- }I thought, just the amount of replicas ("Replicas": 0 to "Replicas": 2) would change. Why are there so many other changes? For me, especially the missing network part is a problem. Maybe someone has an idea why this is happening or has proper working code for scaling the amount of a service's replicas.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
fengxx commentedon Dec 5, 2017
I suspect the
ServiceSpec serviceSpec = service.getSpec();can you try use a clean spec for updateServiceSpec serviceSpec = new ServiceSpec();?sebastianbinder commentedon Dec 5, 2017
Just using
new ServiceSpec();as followingresults in a
com.github.dockerjava.api.exception.BadRequestException: {"message":"rpc error: code = InvalidArgument desc = TaskSpec: missing runtime"}.General question in between: How does updating a service work? Is just the data being sent updated or is it completely overriding those service setting (resulting in the need to include everything like those network settings in this
ServiceSpec)?Do you have a quick code snipped for me how to update the replica amount of a service keeping its original settings?
fengxx commentedon Dec 5, 2017
Actually it is not documented https://docs.docker.com/engine/api/v1.30/#operation/ServiceUpdate
you has to decipher it yourself.
Edit /etc/docker/daemon.json to add
"debug": true, then update service using docker cli, and monitor /var/log/message for the request body, sampleI tried
docker service update --replicate 3 workerand got below requestsebastianbinder commentedon Dec 8, 2017
I just did some further testing - especially trying to get rid of the the
com.github.dockerjava.api.exception.BadRequestException: {"message":"rpc error: code = InvalidArgument desc = TaskSpec: missing runtime"}error mentioned above to be able to use a cleanServiceSpecand found out that the"Runtime": "container"part is completely missing in the ContainerSpec model.Is one of you guys able to add this to the model?
fengxx commentedon Dec 9, 2017
it seems runtime was added in v1.30, I think it is optional, tested with below code
you need image/command/name and version for updating
sebastianbinder commentedon Dec 14, 2017
Thanks, this works for replication with a clean ServiceSpec. But still those configuration changes occur.
Seems like a lot of things are getting nulled, when using docker-java compared to CLI...
Here is the debug log output when using your code snippet… Any ideas on this?
fengxx commentedon Dec 15, 2017
I fixed the null string issue by adding Include.NON_NULL annotation (#966)
sebastianbinder commentedon Dec 15, 2017
Thanks for changing this.
I just had some closer look on the code and found out that ContainerSpec Model is missing following values:
HostnameOpenStdinReadonlyStopSignalStopGracePeriodHealthcheckHostsDNSConfigSecretsConfigsTaskSpec Model is missing
Networks(which might be the solution for my original issue)ServiceSpec Model is missing
RollbackConfigInclude.NON_NULLannotation still missing on:fengxx commentedon Dec 19, 2017
Thanks for the finding, I will update the data model when I am free, maybe next week.
sebastianbinder commentedon Dec 19, 2017
@fengxx That would be awesome 👍
sebastianbinder commentedon Jan 2, 2018
Hey @fengxx
Hope you had a nice Christmas time. Any update on this issue?
sebastianbinder commentedon Jan 9, 2018
Works perfectly, @fengxx - thanks so much!
jaschaio commentedon Apr 19, 2018
@sebastianbinder I encountered the same question as you working with the docker API. Do I have to specify everything as upon service creation or is it possible updating only a single thing of the service, for example the name?