moby/api
Ian Campbell 9b001c4f5f Correct CPU usage calculation in presence of offline CPUs and newer Linux
In https://github.com/torvalds/linux/commit/5ca3726 (released in v4.7-rc1) the
content of the `cpuacct.usage_percpu` file in sysfs was changed to include both
online and offline cpus. This broke the arithmetic in the stats helpers used by
`docker stats`, since it was using the length of the PerCPUUsage array as a
proxy for the number of online CPUs.

Add current number of online CPUs to types.StatsJSON and use it in the
calculation.

Keep a fallback to `len(v.CPUStats.CPUUsage.PercpuUsage)` so this code
continues to work when talking to an older daemon. An old client talking to a
new daemon will ignore the new field and behave as before.

Fixes #28941.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>
(cherry picked from commit 115f91d757)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
2017-03-13 16:16:05 -07:00
..
errors Move errors/ to api/errors 2016-09-16 12:27:13 -04:00
fixtures Add more unit tests (thus coverage) to pkg api 2015-08-04 19:51:02 +02:00
server Merge pull request #31140 from thaJeztah/1.13.2-cherry-picks 2017-02-19 00:36:22 -08:00
templates/server Update to inline comments. 2016-10-31 11:13:41 -04:00
types Correct CPU usage calculation in presence of offline CPUs and newer Linux 2017-03-13 16:16:05 -07:00
common.go Correct CPU usage calculation in presence of offline CPUs and newer Linux 2017-03-13 16:16:05 -07:00
common_test.go Add engine-api types to docker 2016-09-07 11:05:58 -07:00
common_unix.go Windows: Require REST 1.25 or later 2016-10-31 14:33:59 -07:00
common_windows.go Windows: Allow API v1.24 2016-11-04 10:10:42 -07:00
README.md Add documentation for working on Engine API 2016-11-22 16:52:48 -08:00
swagger-gen.yaml Use a config to generate swagger api types 2016-10-31 11:13:41 -04:00
swagger.yaml Correct CPU usage calculation in presence of offline CPUs and newer Linux 2017-03-13 16:16:05 -07:00

Working on the Engine API

The Engine API is an HTTP API used by the command-line client to communicate with the daemon. It can also be used by third-party software to control the daemon.

It consists of various components in this repository:

  • api/swagger.yaml A Swagger definition of the API.
  • api/types/ Types shared by both the client and server, representing various objects, options, responses, etc. Most are written manually, but some are automatically generated from the Swagger definition. See #27919 for progress on this.
  • cli/ The command-line client.
  • client/ The Go client used by the command-line client. It can also be used by third-party Go programs.
  • daemon/ The daemon, which serves the API.

## Swagger definition

The API is defined by the Swagger definition in api/swagger.yaml. This definition can be used to:

  1. To automatically generate documentation.
  2. To automatically generate the Go server and client. (A work-in-progress.)
  3. Provide a machine readable version of the API for introspecting what it can do, automatically generating clients for other languages, etc.

Updating the API documentation

The API documentation is generated entirely from api/swagger.yaml. If you make updates to the API, you'll need to edit this file to represent the change in the documentation.

The file is split into two main sections:

  • definitions, which defines re-usable objects used in requests and responses
  • paths, which defines the API endpoints (and some inline objects which don't need to be reusable)

To make an edit, first look for the endpoint you want to edit under paths, then make the required edits. Endpoints may reference reusable objects with $ref, which can be found in the definitions section.

There is hopefully enough example material in the file for you to copy a similar pattern from elsewhere in the file (e.g. adding new fields or endpoints), but for the full reference, see the Swagger specification

swagger.yaml is validated by hack/validate/swagger to ensure it is a valid Swagger definition. This is useful for when you are making edits to ensure you are doing the right thing.

Viewing the API documentation

When you make edits to swagger.yaml, you may want to check the generated API documentation to ensure it renders correctly.

All the documentation generation is done in the documentation repository, docker/docker.github.io. The Swagger definition is vendored periodically into this repository, but you can manually copy over the Swagger definition to test changes.

Copy api/swagger.yaml in this repository to engine/api/[VERSION_NUMBER]/swagger.yaml in the documentation repository, overwriting what is already there. Then, run docker-compose up in the documentation repository and browse to http://localhost:4000/engine/api/ when it finishes rendering.