kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity
moby--moby/plugin/manager_windows.go

29 lines
666 B
Go
Raw Normal View History

Add canonical import comment Signed-off-by: Daniel Nephin <dnephin@docker.com>
2018-02-05 16:05:59 -05:00
package plugin // import "github.com/docker/docker/plugin"
plugins: experimental support for new plugin management 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>
2016-05-16 11:50:55 -04:00
import (
"fmt"
Reorganize plugin package into sub packages. Split plugin package into `store` and `v2/plugin`. Now the functionality is clearly delineated: - Manager: Manages the global state of the plugin sub-system. - PluginStore: Manages a collection of plugins (in memory and on-disk) - Plugin: Manages the single plugin unit. This also facilitates splitting the global PluginManager lock into: - PluginManager lock to protect global states. - PluginStore lock to protect store states. - Plugin lock to protect individual plugin states. Importing "github.com/docker/docker/plugin/store" will provide access to plugins and has lesser dependencies when compared to importing the original monolithic `plugin package`. Signed-off-by: Anusha Ragunathan <anusha@docker.com>
2016-08-26 13:02:38 -04:00
"github.com/docker/docker/plugin/v2"
Make experimental a runtime flag Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
2016-10-06 10:09:54 -04:00
specs "github.com/opencontainers/runtime-spec/specs-go"
plugins: experimental support for new plugin management 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>
2016-05-16 11:50:55 -04:00
)
Make v2/Plugin accesses safe. v2/Plugin struct had fields that were - purely used by the manager. - unsafely exposed without proper locking. This change fixes this, by moving relevant fields to the manager as well as making remaining fields as private and providing proper accessors for them. Signed-off-by: Anusha Ragunathan <anusha@docker.com>
2016-12-01 14:36:56 -05:00
func (pm *Manager) enable(p *v2.Plugin, c *controller, force bool) error {
plugins: experimental support for new plugin management 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>
2016-05-16 11:50:55 -04:00
return fmt.Errorf("Not implemented")
}
Reorganize plugin package into sub packages. Split plugin package into `store` and `v2/plugin`. Now the functionality is clearly delineated: - Manager: Manages the global state of the plugin sub-system. - PluginStore: Manages a collection of plugins (in memory and on-disk) - Plugin: Manages the single plugin unit. This also facilitates splitting the global PluginManager lock into: - PluginManager lock to protect global states. - PluginStore lock to protect store states. - Plugin lock to protect individual plugin states. Importing "github.com/docker/docker/plugin/store" will provide access to plugins and has lesser dependencies when compared to importing the original monolithic `plugin package`. Signed-off-by: Anusha Ragunathan <anusha@docker.com>
2016-08-26 13:02:38 -04:00
func (pm *Manager) initSpec(p *v2.Plugin) (*specs.Spec, error) {
plugins: experimental support for new plugin management 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>
2016-05-16 11:50:55 -04:00
return nil, fmt.Errorf("Not implemented")
}
Make v2/Plugin accesses safe. v2/Plugin struct had fields that were - purely used by the manager. - unsafely exposed without proper locking. This change fixes this, by moving relevant fields to the manager as well as making remaining fields as private and providing proper accessors for them. Signed-off-by: Anusha Ragunathan <anusha@docker.com>
2016-12-01 14:36:56 -05:00
func (pm *Manager) disable(p *v2.Plugin, c *controller) error {
plugins: experimental support for new plugin management 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>
2016-05-16 11:50:55 -04:00
return fmt.Errorf("Not implemented")
}
Implement plugin restore after daemon restart This ensures that: - The in-memory plugin store is populated with all the plugins - Plugins which were active before daemon restart are active after. This utilizes the liverestore feature when available, otherwise it manually starts the plugin. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2016-06-15 13:39:33 -04:00
Fix panic on daemon restart with running plugin Scenario: Daemon is ungracefully shutdown and leaves plugins running (no live-restore). Daemon comes back up. The next time a container tries to use that plugin it will cause a daemon panic because the plugin client is not set. This fixes that by ensuring that the plugin does get shutdown. Note, I do not think there would be any harm in just re-attaching to the running plugin instead of shutting it down, however historically we shut down plugins and containers when live-restore is not enabled. [kir@: consolidate code to deleteTaskAndContainer, a few minor nits] Signed-off-by: Brian Goff <cpuguy83@gmail.com> Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
2018-04-20 10:48:54 -04:00
func (pm *Manager) restore(p *v2.Plugin, c *controller) error {
Implement plugin restore after daemon restart This ensures that: - The in-memory plugin store is populated with all the plugins - Plugins which were active before daemon restart are active after. This utilizes the liverestore feature when available, otherwise it manually starts the plugin. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2016-06-15 13:39:33 -04:00
return fmt.Errorf("Not implemented")
}
Shutdown plugins during daemon shutdown. Signed-off-by: Anusha Ragunathan <anusha@docker.com>
2016-07-01 14:36:11 -04:00
// Shutdown plugins
func (pm *Manager) Shutdown() {
}
Copy permalink