On daemon restart the local volume driver will read options that it
persisted to disk, however it was reading an incorrect path, causing
volume options to be silently ignored after a daemon restart.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: c560dd968600ebc9c1ff78f256ee93a6ded9a728
Component: engine
these values were changed to lowercase in
690cb2d08c,
but not changed accordingly in docker/docker.
this changes the mounttypes to lowercase
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 8f93128cd619e1d11be1bc0ae21f1362b1e3f9ad
Component: engine
Legacy plugin model maintained a map of plugins. This is
not used by the new model. Using this map in the new model
causes incorrect lookup of plugins. This change uses adds
a plugin to the map only if its legacy.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 8fd779dc28a11d8727d76e9553379b0c854f7c4c
Component: engine
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
As described in our ROADMAP.md, introduce new Swarm management API
endpoints relying on swarmkit to deploy services. It currently vendors
docker/engine-api changes.
This PR is fully backward compatible (joining a Swarm is an optional
feature of the Engine, and existing commands are not impacted).
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Victor Vieux <vieux@docker.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 534a90a99367af6f6bba1ddcc7eb07506e41f774
Component: engine
This is similar to network scopes where a volume can either be `local`
or `global`. A `global` volume is one that exists across the entire
cluster where as a `local` volume exists on a single engine.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2f40b1b281a3be8f34d82a5170988ee46ea1f442
Component: engine
Now handles `package.Type` and `*package.Type`
Fixes parsing issues with slice and map types.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 79ff6eaf21dfebad0f8131a1ede235249cd6638f
Component: engine
In order to be consistent on creation of volumes for bind mounts
we need to create the source directory if it does not exist and the
user specified he wants it relabeled.
Can not do this lower down the stack, since we are not passing in the
mode fields.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 322cc99c6962ecb56be3107061eb7f61364d05f8
Component: engine
Auto-creation of host-paths has been un-deprecated,
so to have feature-parity between Linux and Windows,
this feature should also be present on Windows.
This enables auto-creation on Windows.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 4e080347af657ca3a0c103c6bc6cd6a8157d20d8
Component: engine
This generates an ID string for calls to Mount/Unmount, allowing drivers
to differentiate between two callers of `Mount` and `Unmount`.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2b6bc294fc7f9e08a9091833b021b7d2a01ad2a6
Component: engine
The `Status` field is a `map[string]interface{}` which allows the driver to pass
back low-level details about the underlying volume.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 36a1c56cf555f8fe9ceabeebb8fc956e05863fc7
Component: engine
Auto-creation of non-existing host directories
is no longer deprecated (9d5c26bed2ac287542e176d9149250927876e3f5),
so this warning is no longer relevant.
This removes the deprecation warning.
Also removes the "system" package here, because it's only used
on non-Windows, so basically just called os.MkdirAll()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 1d02ad2a519765179480e0ae113bcf510a2713af
Component: engine
Implements a `CachedPath` function on the volume plugin adapter that we
call from the volume list function instead of `Path.
If a driver does not implement `CachedPath` it will just call `Path`.
Also makes sure we store the path on Mount and remove the path on
Unmount.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 9e6b1852a78eda6ed2cb255d6be8a0d0e5a5ca40
Component: engine
This was done by making List not populate the cache.
fixes#21403
Signed-off-by: Viktor Stanchev <me@viktorstanchev.com>
Upstream-commit: 800b9c5a2698aae5c43f42d4c9c1a41280b556a6
Component: engine
This allows a user to specify explicitly to enable
automatic copying of data from the container path to the volume path.
This does not change the default behavior of automatically copying, but
does allow a user to disable it at runtime.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b0ac69b67ef79c6c937f84bee3df20a1924ad334
Component: engine
Allows users to submit options similar to the `mount` command when
creating a volume with the `local` volume driver.
For example:
```go
$ docker volume create -d local --opt type=nfs --opt device=myNfsServer:/data --opt o=noatime,nosuid
```
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b05b2370757d7143d761e5e6abb8c0f9b009f737
Component: engine
As drivername maybe "" in hostconfig, so we should not
directly print dirvername with var drivername,
instead, we use the real driver name property to print it.
Fixes: #20900
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: 6c78edaf7f22bfe3bd731855f767b9fa3c7d8549
Component: engine
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: a793564b2591035aec5412fbcbcccf220c773a4c
Component: engine
In cases where the a plugin responds with both a null or empty volume
and a null or empty Err, the daemon would panic.
This is because we assumed the idiom if `err` is nil, then `v` must not
be but in reality the plugin may return whatever it wants and we want to
make sure it doesn't harm the daemon.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 96c79a1934dd52d2a6f648e519b5d4ac60ac8ca1
Component: engine
Hacks were added as interim support for 1.10 but should not be needed
for 1.11.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 3403a01b07a73defe9f15c30e16ec8dfcab50439
Component: engine
This fixes an issue where `docker run -v foo:/bar --volume-driver
<remote driver>` -> daemon restart -> `docker run -v foo:/bar` would
make a `local` volume after the restart instead of using the existing
volume from the remote driver.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 00ec6102d993a752bd8dfb4ee393a4e58e59a4fe
Component: engine
Make volume dangling filter return only used volumes with `dangling=false`.
Upstream-commit: 146e49b039c59107cc31de734f0bf5d4604c04d9
Component: engine
