Kitematic now support Windows
Signed-off-by: Marcelo Salazar R <chelosalazar@gmail.com>
Upstream-commit: 1b3bde47ef5a7c4b178bb3d0cab6e4238e5cc124
Component: engine
- creating index which is overview of configuring logs
- linking to individual journald/fluent material
- leaving behind table and link to index in run
Signed-off-by: Mary Anthony <mary@docker.com>
Upstream-commit: 31dd97f4adb215b23504f72e7a17464bc6428419
Component: engine
The documentation is currently broken for the fedora page. This PR fixes missing the markup.
Signed-off-by: Charles Sarrazin <charles@sarraz.in>
Upstream-commit: 62213219dc97a97471f8d7813aa61a74745ec902
Component: engine
When a container is started with `--net=host` with
a particular name and it is subsequently destroyed,
then all subsequent creations of the container with
the same name will fail. This is because in `--net=host`
the namespace is shared i.e the host namespace so
trying to destroy the host namespace by calling
`LeaveAll` will fail and the endpoint is left with
the dangling state. So the fix is, for this mode, do
not attempt to destroy the namespace but just cleanup
the endpoint state and return.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Upstream-commit: 9bb69f9726e7f8cba0cdf681e5060e47b9c45298
Component: engine
The last "," should not shown up, otherwise you will get the error
back as below:
- invalid character '}' looking for beginning of object key string.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Upstream-commit: 221fa4c3d11973f6b973daf26fd962554945fc68
Component: engine
With the 1.7 release, we introduced a change to how we store registry
credentials, but the build API endpoint did not expect a change in the format
of that file. This patch fixes this problem so that you can again pull private
images during `docker build`.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Upstream-commit: 02c7bbefb8841e5e86a4b9d467defa668e3ea613
Component: engine
Thanks to @aanand for help debugging
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
Upstream-commit: fe1f210c42ba2978bd00450d2e91b23f040b8e5e
Component: engine
With publish-service and default-network support, a container could be
connected to a user-defined network that is backed by any driver/plugin.
But if the user uses port mapping or expose commands, the expectation
for that container is to behave like existing bridge network.
Thanks to the Libnetwork's CNM model, containers can be connected
to the bridge network as a secondary network in addition to the
user-specified network.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 739996c1d78976f7435c7274300b3e8f2e598b17
Component: engine
Now that the default network mode is "default" and this mode is chosen
even if the mode is empty string, it is not correct to have builder
still pointing to "bridge" as default (though this is daemon default).
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 53b0f686f7ee338819e568413fd9daf9c3811d68
Component: engine
- brings in vxlan based native multihost networking
- added a daemon flag required by libkv for dist kv operations
- moved the daemon flags to experimental
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 508065a7adc84e5e63f47b00c379dad6a79d3c5e
Component: engine
