Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add API support for PidsLimit on services #39882

Merged
merged 1 commit into from
Apr 16, 2020

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Sep 9, 2019

continues the work started in moby/swarmkit#2415 (vendored through #35326)

addresses the API side of #28618

@@ -2870,6 +2870,14 @@ definitions:
description: "Run an init inside the container that forwards signals and reaps processes. This field is omitted if empty, and the default (as configured on the daemon) is used."
type: "boolean"
x-nullable: true
PidsLimit:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, this is the only thing I'm not sure about; PidsLimit is directly in TaskTemplate.ContainerSpec (which is similar to how it's for container create), but other limits are in TaskTemplate.Resources.Limits / TaskTemplate.Resources.Reservation.

moby/swarmkit#2415 was merged a long time ago, and implemented it like this on the SwarmKit side, so I wasn't sure if we should change it?

api/swagger.yaml Outdated
Tune a container's PIDs limit. Set `0` or `null` for unlimited.
type: "integer"
format: "int64"
x-nullable: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be nullable?
For services we do not support partial updates (e.g. the client must send the entire service spec), this is different than the containers API.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, good point; but actually thinking of a scenario now that I'm not sure we're taking into account right now (also for other options)

  • create service with API v1.x, using features of API v1.x
  • use an older client (v1.x - 1) to update the service
  • the older client doesn't know about features of v1.x, and will strip those fields
  • the daemon detects the older API version, thus resets those fields

I'll have to check our logic, and make sure that on update, we restore the previous value of any field that was in the service spec, but that's not supported by the API version used to update.

Otherwise (for this particular feature), the PID limit will be removed when updating the service with an older client, which ain't nice

@thaJeztah thaJeztah added this to In progress in 20.10 planning via automation Mar 17, 2020
@thaJeztah thaJeztah force-pushed the swarm_pids_limit branch 4 times, most recently from 753d412 to 0efb966 Compare April 15, 2020 10:59
@thaJeztah
Copy link
Member Author

@cpuguy83 updated; added a second commit to change it from a pointer; let me know if that looks ok then I'll squash the commits

@thaJeztah
Copy link
Member Author

(this currently includes #40816, I'll rebase once that's merged)

20.10 planning automation moved this from In progress to Reviewer approved Apr 15, 2020
Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Support for PidsLimit was added to SwarmKit in moby/swarmkit/pull/2415,
but never exposed through the Docker remove API.

This patch exposes the feature in the repote API.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah
Copy link
Member Author

rebased and squashed

@thaJeztah thaJeztah merged commit c8e31dc into moby:master Apr 16, 2020
20.10 planning automation moved this from Reviewer approved to Done Apr 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

5 participants