This patch introduces a new experimental engine-level plugin management
with a new API and command line. Plugins can be distributed via a Docker
registry, and their lifecycle is managed by the engine.
This makes plugins a first-class construct.
For more background, have a look at issue #20363.
Documentation is in a separate commit. If you want to understand how the
new plugin system works, you can start by reading the documentation.
Note: backwards compatibility with existing plugins is maintained,
albeit they won't benefit from the advantages of the new system.
Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: f37117045c5398fd3dca8016ea8ca0cb47e7312b
Component: engine
- do use use log pkg
- do not t.Fatal in goroutine
- cleanups
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Upstream-commit: 6a96684442a7e9d6e2d00e9b11d23ea6caa88a2a
Component: engine
Small refactor to be able to use custom transports
to call remote plugins.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 1a630234508bdb12d55425ceebdb0b6523a38578
Component: engine
Based on the discussion, we have changed the following:
1. Send body only if content-type is application/json (based on the
Docker official daemon REST specification, this is the provided for all
APIs that requires authorization.
2. Correctly verify that the msg body is smaller than max cap (this was
the actual bug). Fix includes UT.
3. Minor: Check content length > 0 (it was -1 for load, altough an
attacker can still modify this)
Signed-off-by: Liron Levin <liron@twistlock.com>
Upstream-commit: ca5c2abecfd12ad22b75c69e0debde7b625c2735
Component: engine
