During a `docker load` there are times when nothing is printed
to the screen, leaving the user with no idea whether something happened.
When something *is* printed, often its just something like:
```
1834950e52ce: Loading layer 1.311 MB/1.311 MB
5f70bf18a086: Loading layer 1.024 kB/1.024 kB
```
which isn't necessarily the same as the image IDs.
This PR will either show:
- all of the tags for the image, or
- all of the image IDs if there are no tags
Sample output:
```
$ docker load -i busybox.tar
Loaded image: busybox:latest
$ docker load -i a.tar
Loaded image ID: sha256:47bcc53f74dc94b1920f0b34f6036096526296767650f223433fe65c35f149eb
```
IOW, show the human-friendly stuff first and then only if there are no tags
default back to the image IDs, so they have something to work with.
For me this this is needed because I have lots of images and after a
recent `docker load` I had no idea what image I just imported and had a
hard time figuring it out. This should fix that by telling the user
which images they just imported.
I'll add tests once there's agreement that we want this change.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 6986a3220fe59146eeddeaa865561472abc7baeb
Component: engine
As map reference, if all networks use same, it could cause strange
results.
Closes: #23304
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: 1cac7e6cbd3d1501d0fc29fc55b7ada981974998
Component: engine
This adds support for filtering by network ID, to be
consistent with other filter options.
Note that only *full* matches are returned; this is
consistent with other filters (e.g. volume), that
also return full matches only.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 7c46ba02e694ae540866b29ebf0dab76e556cc13
Component: engine
Change the test back to what it was before
e83dad090a1e890ac870808d776fa584276bf7ab
And added an extra test-case to check the
output if an incorrect number of arguments
is passed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 085f41b6a5764cba33fb5bda387f8ebe165d5828
Component: engine
Any command that expects extra flags after positional args needs to set flags.SetInterspersed(false).
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: aa00520fc8bb4e04c37c2eb41f3bc3558deab533
Component: engine
This fix is part of the effort to convert commands to spf13/cobra #23211.
Thif fix coverted command `docker rename` to use spf13/cobra
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 70f7ccb304f9246bc9c2bfe0e30d3a2bd8fd42f8
Component: engine
To implement seccomp for s390x the following changes are required:
1) seccomp_default: Add s390 compat mode
On s390x (64 bit) we can run s390 (32 bit) programs in 32 bit
compat mode. Therefore add this information to arches().
2) seccomp_default: Use correct flags parameter for sys_clone on s390x
On s390x the second parameter for the clone system call is the flags
parameter. On all other architectures it is the first one.
See kernel code kernel/fork.c:
#elif defined(CONFIG_CLONE_BACKWARDS2)
SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned long, clone_flags,
int __user *, parent_tidptr,
So fix the docker default seccomp rule and check for the second
parameter on s390/s390x.
3) seccomp_default: Add s390 specific syscalls
For s390 we currently have three additional system calls that should
be added to the seccomp whitelist:
- Other architectures can read/write unprivileged from/to PCI MMIO memory.
On s390 the instructions are privileged and therefore we need system
calls for that purpose:
* s390_pci_mmio_write()
* s390_pci_mmio_read()
- Runtime instrumentation:
* s390_runtime_instr()
4) test_integration: Do not run seccomp default profile test on s390x
The generated profile that we check in is for amd64 and i386
architectures and does not work correctly on s390x.
See also: 75385dc216e ("Do not run the seccomp tests that use
default.json on non x86 architectures")
5) Dockerfile.s390x: Add "seccomp" to DOCKER_BUILDTAGS
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Upstream-commit: bf2a577c131d8998eb6ecac986d80e1289e6c801
Component: engine
- Migrates network command and subcommands (connect, create, disconnect,
inspect, list and remove) to spf13/cobra
- Create a RequiredExactArgs helper function for command that require an
exact number of arguments.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 4bd202b00f7859ebeb4ba87511a0618ad08d0605
Component: engine
This fix is part of the effort to convert commands to spf13/cobra #23211.
Thif fix coverted command `docker diff` to use spf13/cobra
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 5899afae52b10d2457848c6e62a7476835befef3
Component: engine
Moves image command rmi to `api/client/image/remove.go` and use cobra :)
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 60e48bd6bd24c559ed92c7217cd7798c85cbb644
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
Testing for the number of commands in `help` output doesn't seem to
contribute much to the quality of the project, and adds additional
burden for the developer to update.
Signed-off-by: Arnaud Porterie (icecrime) <arnaud.porterie@docker.com>
Upstream-commit: dd7e59a40a4c93070f71adb3ec74021241586c21
Component: engine
The error message changed from
remote error: bad certificate
To
remote error: tls: bad certificate
In Go 1.7, so just checking for "bad certificate"
to make this test work on both Go 1.6 and 1.7
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 496adadcec4ba00d230e546239ddc10e4ea41dcf
Component: engine
Return the correct status code on flag parsins errors.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 5ab24342258c70438ab8edf708ebc466b1677f38
Component: engine
This fix addresses an issue where including the `{{.Size}}` format
field in conjunction with `docker ps --format`, without the `--size`
flag, would not correctly display the size of containers.
This is done by doing a check on the custom format string, and setting
the size flag on the options struct if the field is found. This struct
gets passed to the engine API which then generates the correct query.
An integration test is included which runs `docker ps --format "table
{{.Size}}"` without `--size`, and checks that the returned output is
not `0 B`.
Fixes#21991
As suggested by @cpuguy83, a parser is implemented to process the format
string as a template, and then traverses the template tree to determine
if `.Size` was called.
This was then reworked by making use of template execution with a
pre-processor struct that will set the `--size` option if the template
calls for the field.
The pre-processor now also sets a boolean in the context passed to the
writer. There is an integration test for this that calls `docker ps
--size --format "{{.Size}}"` and then checks that `size: {{.Size}}` is
not appended, as it would with previous behavior.
Finally, a change was made to the formatter to not automatically
add a `{{.Size}}` if a custom format is provided.
Signed-off-by: Paulo Ribeiro <paigr.io@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 55cdb6dcd0f709301573ddb9f3348f9288572b91
Component: engine
