text:
docker strips 127.0.0.1 from resolv.conf even in --net=host mode

Is this desired behaviour?
We're running a local consul agent which is being used as a dns server locally (for dynamic service discovery). We've added 127.0.0.1 to resolv.conf on hosts so dns lookups are handled by the consul agent.
However when docker starts it strips any local resolvers from resolv.conf, which makes sense for containers in bridged mode, but shouldn't this be allowed when --net=host?

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

Or perhaps replacing 127.0.0.1 with the ip address of the docker container?

docker version: Docker version 1.7.0, build 0baf609
docker info: Containers: 3
Images: 72
Storage Driver: aufs
Root Dir: /mnt/data/docker/graph/aufs
Backing Filesystem: extfs
Dirs: 78
Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-55-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 2
Total Memory: 3.859 GiB
Name: ip-172-20-121-181
ID: AVBV:2KB4:5R7R:XQ7E:RGDS:XSSA:XMN5:5YS2:HCYV:P7VV:FPSH:SRII
WARNING: No swap limit support
uname -a: Linux ip-172-20-121-181 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

This should be fixed on master and was merged into the release branch #14264. Closing.

authors: GordonTheTurtle calavera rncry


text:
boot2docker volume resize suggests gparted livecd which is currently incompatible with the boot2docker vm

The guide here on the docker documentation (https://docs.docker.com/articles/b2d_volume_resize/) suggests using the gparted livecd iso, however, the current version does not work. Others have experienced this problem too, see: https://gist.github.com/joost/a7cfa7b741d9d39c1307
Version of gparted livecd: gparted-live-0.22.0-2-i586.iso
Version of boot2docker:
Boot2Docker-cli version: v1.6.0
Git commit: 9894ae9

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@dunk are you interested in contributing, and opening a PR to improve that documentation? The markdown file used to create that documentation can be found in this repository; https://github.com/docker/docker/blob/master/docs/articles/b2d_volume_resize.md

With the new native docker, and also the ability to resize the mv via docker-machine (albeit by creating a new one), I think that this ticket is no longer really relevant.

Thanks @dunk!

source: gharchive/issue

authors: GordonTheTurtle dunk thaJeztah

repo: docker/docker

license_type: permissive

license_source: github-api


text:
TTL for containers

Hi!
We're running Docker during CI testing. Since test process could be interrupted (i.e. restart of CI system) there will be some Docker containers which are not used anymore, but they are still running and consume memory and CPU.
What we expect is something like "TTL" (Time-to-live) option when running container, so it will be killed after specified amount of time.
Thanks!

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

With PR #15307, I think you can do this (haven't tried).
cid=$(docker run -d --stop-signal=0 foo)
docker stop -t 300 $cid &

This will stop the container after 300 seconds. The --stop-signal=0 is the part that makes this work. Signal 0 is an allowed signal, but it's a no-op usually used to check that the target process is alive.
This technique will work even if the client process running docker stop gets killed. The process sends the request off to the daemon, and it's the daemon that enforces the timeout. The client is just sitting waiting for it. Backgrounding it is just the easiest method to get it out of the way.

This is a dup of #6688

@cpuguy83 I don't believe it is. #6688 is about cleaning up stopped containers after they haven't been used for a while. This issue is about stopping containers.

I see it as a different use-case for the same feature.

I don't see how.
Use case: stopping containers which have not been attached in X minutes
Feature #6688: remove stopped containers which exited X minutes ago.
The feature does not satisfy the use case.

@phemmer I see the generic case, perform some action on a container after a given time.

But maybe I'm mis-reading?

authors: GordonTheTurtle bsideup cpuguy83 phemmer


text:
nginx cannot save file to mounted wordpress directory

Hi everyone,
I spent a few days on following issue but cannot figure out the solution, plz give me some guides to settle it :(
Environment
docker version: Docker version 1.9.0, build 76d6bc9

docker info:
Containers: 2
Images: 27
Server Version: 1.9.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 31
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.12-boot2docker
Operating System: Boot2Docker 1.9.0 (TCL 6.4); master : 16e4a2a - Tue Nov  3 19:49:22 UTC 2015
CPUs: 1
Total Memory: 1.956 GiB
Name: default
ID: WYKL:KPEW:G5HY:YOQ4:4555:YU33:UJBP:4YOB:RWFK:HQNL:OLLG:BVJD
Debug mode (server): true
 File Descriptors: 20
 Goroutines: 38
 System Time: 2015-11-18T04:05:07.548898935Z
 EventsListeners: 0
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
 provider=virtualbox

uname -a:
Darwin My-MacBook 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

Issue
1 "db" container for mysql
1 "web" container for nginx + php + /var/www/html/webapp is mounted to wordpress directory on host (/Users/www/wordpress)
Wordpress is installed normally, everything works fine (creating file from console of "web" container and save it to /var/www/html/webapp, check and find that that file exists on host too) but media upload feature of wordpress doesn't work, media files cannot be saved to /wp-content/uploads folder.
so I guessed that something wrong with permission on /var/www/html/webapp/wp-content/uploads, it could relate to www-data, then...
I checked /var/www/html/webapp on "web" container, found that owner of webapp directory is 1000 and group-owner is staff.
I tried to add www-data to staff group, but it doesn't work.
I tried to do "RUN chown -R www-data:www-data /var/www/html/webapp" in Dockerfile of "web" container but it also gives no effect because no change on owner of target folder is applied, it still is 1000:staff.
Expected
Media Upload feature of Wordpress works properly - Can save file to /var/www/html/webapp/wp-content/uploads folder
any help is much appreciated :(
regards,

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

This is a duplicate of https://github.com/boot2docker/boot2docker/issues/581 and a limitation of the way directories on the host (OS X) are shared with the boot2docker Virtual Machine using VirtualBox Sharing. Unfortunately there's no full solution for this currently, but the discussion on https://github.com/boot2docker/boot2docker/issues/581 contains a lot of workarounds / alternative approaches that may be helpful.
I'm going to close this issue here, and suggest to subscribe to https://github.com/boot2docker/boot2docker/issues/581 to follow progress.
Thanks for reporting, and I hope the linked issue helps you find a suitable workaround for your use case

authors: GordonTheTurtle projectxmaker thaJeztah


text:
docker swarm inspect and docker info inconsistencies

Both docker info and docker swarm inspect display information regarding the swarm.
They do so in a different way.
There are also other inconsistencies in swarm inspect (#23689, #24122).
/cc @stevvooe @aanand @dnephin @tonistiigi

I suggest we replace swarm inspect with swarm info because it does not expect an argument.
It should be pretty by default, and maybe add --json flag, although I would prefer not having it for 1.12 and adding it to both swarm info and info in a later release.
This means that --pretty could remain on node inspect and service inspect, even though i would expect --pretty be added in a later release to volume inspect and network inspect and inspect.

We could also add this information to docker info and remove swarm inspect altogether to stay future proof (in the case there will be multiple swarms to inspect).

Voting for removing swarm inspect as :

It's not following the conventions as docker inspect, docker-machine inspect
It's only showing the current swam info

We decided to remove swarm inspect altogether and just add swarm-specific information to docker info. We need to find a way of merging the existing swarm information in docker info, with the one in swarm inspect currently.
Any takers?

@tiborvass I can take a look at it tomorrow morning :angel: :fr:

SGTM

authors: aluzzardi minzhang28 tiborvass vdemeester


text:
[1.12.0-rc3] docker swarm mode supprt HA

Does docker swarm mode supprt high availability?  could be multi-manager in one cluster?

sure. Plz join your node into the cluster as manager role
docker swarm join --manager --listen-addr $(hostname -i):2377 $FIRST_MANAGER_IP:2377

initial docs for Swarm mode is here; https://docs.docker.com/engine/swarm/, but a section on high-availability and multiple managers is not yet there
ping @sfsmithcha

This is a dupe of https://github.com/docker/docker/issues/24109
Like all docs, this is a WIP. Docs for adding manager nodes to a swarm are specifically blocked by acceptance policy UX.
While that is being sorted out, here is a basic draft summary of running multiple managers:
If you require fault-tolerance in case of a manager failure, you should maintain
an odd number of managers. Docker recommends either three or five manager nodes
according to your organizations high-availability requirements:

* A three-manager swarm tolerates a maximum loss of one manager.
* A five-manager swarm tolerates a maximum simultaneous loss two manager nodes.
* In general, an `N` manager cluster will tolerate the loss of at most `N/2`
managers.
* Seven is the maximum possible number of manager nodes for a swarm.

authors: liuliuzi sfsmithcha thaJeztah vitan


text:
docker image spec 1.1 does not include HEALTHCHECK location

Describe the results you received:
in this twitter post @shykes mentions that docker image format now includes HEALTHCHECK information, so i expected the docker image spec to contain a reference to it, but when i looked it did not.
Describe the results you expected:
i expected to see supported docker image attributes to be specified and documented.

Thanks for the report, you're absolutely right it should be reflected in the spec.

out of curiosity, do you anticipate that this will follow a semantic versioning  approach and therefore bump the docker image version to 1.2?

ping @aaronlehmann @stevvooe could one of you have a look?

HEALTHCHECK is actually a Dockerfile command. I assume you're referring to the container.Config.Healthcheck field.
@talex5 Please update the specification with the the healthcheck fields.

therefore bump the docker image version to 1.2?

@jbayer Yes, although this will only affect the document, as this is backwards compatible change.

@stevvooe yes, i was referencing the Healthcheck field that gets set from the HEALTHCHECK in the Dockerfile. thank you for the response.

Yep, I'll update this (back from holiday now).

authors: icecrime jbayer stevvooe talex5 thaJeztah


text:
docker build error

Hi,
when i try to build this dockerfile  (docker build -t ztest .)
https://gist.github.com/ulrichSchreiner/9736988
i get a build-error:
Before install bootstrap.
Scanning installed packages
Setuptools installation detected at /usr/local/lib/python2.7/dist-packages
Non-egg installation
Moving elements out of the way...
Renaming /usr/local/lib/python2.7/dist-packages/setuptools-3.3-py2.7.egg-info to /usr/local/lib/python2.7/dist-packages/setuptools-3.3-py2.7.egg-info.OLD.1395653076.7
error: Invalid cross-device link
An error occured when trying to install distribute 0.6.36. Look above this message for any errors that were output by easy_install.
While:
  Installing.
  Checking for upgrades.
  Getting distribution for 'distribute==0.6.36'.
Error: Couldn't install: distribute 0.6.36

but when commenting out the last line of the dockerfile i can start the image with docker run -i -t ztest /bin/bash and execute the last line manually. and then it works!
the error invalid cross-device link should happen always or never. i would vote for never because it should be an implementation detail of docker if there are multiple devices while building the image.
my OS:
ubuntu 13.04
Linux dev26 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Docker version 0.9.0, build 2b3fdf2

@unclejack We have a similar issue in here: https://github.com/sjackman/docker-linuxbrew/issues/2

@saketkc Can you provide the output of docker info, docker version and uname -a, please?

$ docker info

Containers: 56
Images: 360
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 472
Execution Driver: native-0.2
Kernel Version: 3.13.0-45-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 4
Total Memory: 15.55 GiB
Name: launchpad
ID: UNHX:654V:RCYC:ASLS:IBVS:X4RH:3HP6:HEAI:UG6Y:CZRG:32YI:ZGSQ
WARNING: No swap limit support

$ docker version

Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

$ uname -a

Linux launchpad 3.13.0-45-generic #74-Ubuntu SMP Tue Jan 13 19:36:28 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

@unclejack Should I make a separate issue for this?

Ping @unclejack

@unclejack I've seen this issue now as well in a Docker Trusted Build. https://hub.docker.com/r/sjackman/linuxbrew-gcc-deps/builds/bsfyddpexgd8qevvytqv7k4/
Step 8 : RUN brew reinstall binutils
 ---> Running in ffc2b6349f65
==> Reinstalling binutils
Error: Invalid cross-device link - (/home/linuxbrew/.linuxbrew/Cellar/binutils/2.25.1, /home/linuxbrew/.linuxbrew/Cellar/binutils/2.25.1.reinstall)
Removing intermediate container ffc2b6349f65
The command '/bin/sh -c brew reinstall binutils' returned a non-zero code: 1

authors: saketkc sjackman ulrichSchreiner unclejack


text:
Make install.sh use HKPS instead of unencrypted hkp forced on Port 80

The script which should be used to install docker via get.docker.com uses unencrypted HKP to get the Key for the Debian-Repository.
It would be fairly easy to switch to HKPS. sks-keyservers.net do maintain a HKPS pool which listens on Port 443. See https://sks-keyservers.net/overview-of-pools.php.
This pull requests changes the behaviour to get the keys.
Note that I have not checked if there are other scripts which are trying to import a Key using unencrypted HKP. If Port 443 should be firewalled, it might make sense to add a note that the keys should get downloaded manually using Port 80. But if Port 443 is firewalled/unavailable, a user who wants to install/update docker should know how to get the key in a secure way.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:janaurka/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

Since the HKPS pool requires extra manual configuration to actually provide anything extra over the regular pool, I'd personally be more in favor of switching to the HA pool, which would help cut down on the number of key fetchings that fail (https://sks-keyservers.net/overview-of-pools.php).

Additionally, since we pull via the full fingerprint, the key is verified after it is pulled, so adding HKPS isn't really going to do much except add overhead to the transfer (and the full fingerprint in the script was already pulled via https, so we've got as much security out of HTTPS as we're possibly going to be able to).

Collective review with @jfrazelle @crosbymichael @calavera
Closing as-per @tianon comment above.

source: gharchive/pull-request

authors: GordonTheTurtle icecrime janaurka tianon


text:
(carry 18273) update description for restart policies

Carry of #18274, updated with suggestions by @moxiegirl
Thanks @afeld for the original PR; I kept your commit in here :+1:

ping @moxiegirl for review/merge

@thaJeztah Needs a squash but otherwise LGTM.

@moxiegirl I left the original commit in here for the carry, or is that not needed?

all squashed
LGTM

I usually leave the original comment in the commit message of the squash.  That way I still only have one commit.

yes that's roughly what I did now, thanks :+1:

authors: moxiegirl thaJeztah


text:
Clarify binaries in changelog

Signed-off-by: John Howard jhoward@microsoft.com
Clarify the platform difference with multiple binaries.

Thanks! LGTM
Not sure we can merge already, with the dynamic packages being worked on at the moment

LGTM

LGTM

merging, CI for code isn't needed

authors: icecrime jhowardmsft thaJeztah tonistiigi


text:
Create the correct directory structure for apt-ftparchive

The release-deb script wasn't creating the correct directory structure for apt-ftparchive, This change creates it, and fixes #22238
/cc @tiborvass
Signed-off-by: Ken Cochrane kencochrane@gmail.com

@tiborvass updated

ping @tiborvass PTAL

ping @tiborvass @tianon

LGTM

LGTM

Thanks!

authors: LK4D4 icecrime kencochrane thaJeztah tianon tiborvass


text:
Fix missing mount ID on volume unmount

Fixes #25331
as discussed in https://github.com/docker/docker/pull/21015#issuecomment-235764916

LGTM

also ping @e4jet @erikh FYI
LGTM

thanks @thaJeztah - LGTM as well


text:
Fix uneccessary calls to volume.Unmount()

Fixes #22564
When an error occurs on mount, there should not be any call later to
unmount. This can throw off refcounting in the underlying driver
unexpectedly.
Consider these two cases:
$ docker run -v foo:/bar busybox true

$ docker run -v foo:/bar -w /foo busybox true

In the first case, if mounting foo fails, the volume driver will
get a call to unmount (this is the incorrect behavior).
In the second case, the volume driver will not get a call to unmount
(correct behavior).
This occurs because in the first case, /bar does not exist in the
container, and as such there is no call to volume.Mount() during the
create phase. It will error out during the start phase.
In the second case /bar is created before dealing with the volume
because of the -w. Because of this, when the volume is being setup
docker will try to copy the image path contents in the volume, in which
case it will attempt to mount the volume and fail. This happens during
the create phase. This makes it so the container will not be created
(or at least fully created) and the user gets the error on create
instead of start. The error handling is different in these two phases.
Changed to only send unmount if the volume is mounted.
While investigating the cause of the reported issue I found some odd
behavior in unmount calls so I've cleaned those up a bit here as well.
Signed-off-by: Brian Goff cpuguy83@gmail.com

ping @tonistiigi @anusha-ragunathan PTAL

I'm not sure I understand this. Do I understand it correctly that this calls umount(MNT_DETACH) ignoring the volume activity count. If this is the case then how is this safe for parallel cp.

@tonistiigi This is the existing behavior.

Also yes, I'm not sure why it's doing the syscall, I just cleaned up the call path for it.

LGTM
Umount doesn't seem to specify MNT_DETACH (see here)

@mlaventure detachMounted does https://github.com/docker/docker/pull/27116/files#diff-5dfdabc4cd5100a2aee949c12d2afe6cR341

are we good on this one @mlaventure @tonistiigi ?

@cpuguy83 When you do the rebase please add a comment to volumeMount.ID != "" that this is the best way to check had been actually mounted(if I understand this fix correctly). LGTM after that, although I think detach part needs to be fixed in follow up and volumes either shouldn't be in MountPoints if they are not mounted or they should do their own internal reference counting.

Updated

LGTM

LGTM

authors: cpuguy83 mlaventure thaJeztah tonistiigi vieux


text:
Carry #339: Remove join-tokens from info

join-tokens are not needed for the endpoint
relates to docker/docker#25134

LGTM

LGTM, thanks Aaron

LGTM

authors: aaronlehmann thaJeztah tiborvass vieux

repo: docker/engine-api

license_source: bigquery


text:
[18.09 backport] Bump containerd v1.2.6, runc 029124da7af7360afa781a0234d1b083550f797

backport of https://github.com/moby/moby/pull/39016 for the 18.09 branch
the last commit (https://github.com/moby/moby/pull/39016/commits/c28171c7c4984bfd0be002d1622fab0779ff573b) was omitted, as it didn't appear to have relevant changes

ping @dmcgowan @tonistiigi PTAL

This runc commit causes a regression on selinux systems. https://github.com/moby/moby/issues/39109

This runc commit causes a regression on selinux systems. moby#39109

@seemethere FYI

@seemethere; I meant: fyi about the regression in runc 😅

Ha I realized right after I approved. 😂

https://github.com/opencontainers/selinux/pull/51#issuecomment-485950519
Dan says it's an issue container-selinux and it should be fixed.

@cpuguy83 LGTY?

Added the runc binary bump from https://github.com/moby/moby/pull/39143

@cpuguy83 LGTY?

I can't verify that container-selinux fixes this since it doesn't appear to be updated yet.

Ok, seemns the updated contaner-selinux is out and does resolve my issue with the updated runc.

let me rebase this one to trigger CI

rebased; will open a follow-up for containerd v1.2.7 separately

Seeing these a lot; oddly, here, it fails on Experimental, but succeeds on Janky https://jenkins.dockerproject.org/job/Docker-PRs-experimental/45700/console
Possibly a race condition?
20:16:51 FAIL: docker_cli_run_test.go:1792: DockerSuite.TestRunInteractiveWithRestartPolicy
20:16:51
20:16:51 assertion failed:
20:16:51 Command:  /usr/local/cli/docker run -i --name test-inter-restart --restart=always busybox sh
20:16:51 ExitCode: 0
20:16:51 Error:    <nil>
20:16:51 Stdout:
20:16:51 Stderr:
20:16:51
20:16:51 Failures:
20:16:51 ExitCode was 0 expected 11

20:21:07 FAIL: docker_cli_start_test.go:190: DockerSuite.TestStartReturnCorrectExitCode
20:21:07
20:21:07 assertion failed: expected an error, got nil

Difference in environment:
Experimental:
Building remotely on ubuntu-1604-aufs (i-003abbf80f693c1e3) (docker-edge ubuntu aufs docker-stable docker ubuntu-1604-aufs-edge x86_64 ec2 linux ubuntu-1604-aufs ubuntu-1604 amd64 ubuntu-1604-aufs-stable) in workspace /home/ubuntu/workspace/Docker-PRs-experimental

Janky:
Building remotely on ubuntu-1604-overlay2 (i-0d7dabfc735eb19f6) (x86_64 ubuntu overlay2 linux ubuntu-1604 ubuntu-1604-overlay2 ubuntu-1604-overlay2-stable amd64) in workspace /home/ubuntu/workspace/Docker-PRs

authors: cpuguy83 seemethere thaJeztah

repo: docker/engine


text:
Docker mongodb issue

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

No information provided or steps to replicate - Closing

authors: FrenchBen irandevelopers

repo: docker/kitematic


text:
Make Gordon in charge or cherry picking for releases.

Cherry picking PRs into the release branch is the most consuming part of releasing Docker. We should let Gordon do the work for us. This might imply to change the release workflow a little bit, but I think it will be worth it.
TODOs:
1 Gordon needs to have push access to the fork where we create the release branch from if we want to do this. We could add the bot as a collaborator to our repos, but in order to eliminate more human interaction, I think it would be better if we started to create the release branches in one single repo, for instance https://github.com/GordonTheTurtle/docker. We can all the docker maintainers as collaborators to that team to create the initial branches and what not, but we could also automate that if we need to.
2 We need to let Gordon know when we want to cherry pick a pull request, we have several options on how to do this, but I think these two are the most obvious:

When maintainer comments in a merged PR: @GordonTheTurtle cherry pick into bump_v1.9.0
When the PR is merged and has an impact label, like impact/v1.9.0

The second option can also be useful to keep track of changes for the changelog.
Every pull request in GitHub has a .patch url assigned, so cherry picking is as easy as these three commands in the right place:
$ curl -SsL https://github.com/docker/docker/pull/15862.patch > /tmp/15862.patch
$ git am < /tmp/15862.patch
$ git push GordonTheTurtle bump_v1.9.0

3 If the merge fails, we should notify the original author of the pull request. It should be up to them to resolve the conflicts to be merged into the release. We should ask them to open a pull request against Gordon's fork with the conflicts resolved. The bot could cherry pick from there if the patch applies and tests pass. This also implies that we should run have a jenkins build for Gordon's repo, but it doesn't sound that bad if you think about it.

Totally agree we should work on automating the release process.
Also I would add:

I kind of dream of an API / web UI to manage this (click checkbox to cherry-pick, click button to generate and advertise for an RC, ...) :innocent:
Have the bot manage the "bump PR", comment in a standard way with a link to the binaries and a link to the changelog when a new RC is issued, maybe even advertise on the newsgroups in a standard format? ;-)

Should we keep docker/leeroy reasonably project agnostic and do this in another tool?

Would it be a problem that the release captain is no longer "in charge" to decide if something actually should be cherry-picked. I know I've sometimes suggested cherry-picking PRs that the release captain didn't agree on (rightfully in many cases :smile:)
Or would the "Gordon" release branch be a "suggested" cherry-pick list, that can later be curated by the release captain?

Agree with @thajeztah, it should remain in control of the release captain.

Having a list for cherry picking would help though, so some way to have Gordon help with that would be good (perhaps just labels, and creating a checkboxed list with links to suggested PRs in a bump-PR?)

This is something I've wanted for docs.  We would most likely use it not just at release time and to automate cherry pick into docs.  I'm not sure if we could use the same mechanism.
Is there a way where we could mark a PR for a particular release and then just have the cherry pick happen automatically.  IOW, oh, this goes into vX.X so Gordon just CPs it in?

I'm totally in favor of automating, however if we're about to change things, I'd love to revisit our release logic in Docker.
Basically what I don't like is that we're cherry-picking from master to a-branch-from-which-we-release-that-is-based-on-the-release-branch, for 2 reasons:

if master and release diverge too much, resolving conflicts on release can add too much risk in introducing bugs, without review.
when we merge the release branch back into master, both branches have the same behavior but from different commits that are based on diverging branches. This can result in some weird conflicts too.

If instead of cherry-picking PRs that were open against master, we merged PRs that were open against some new branch B (the equivalent of master in http://nvie.com/posts/a-successful-git-branching-model/, where their develop branch is our master branch), then we could do the review on what's actually going to be in release without any weird unreviewed conflict resolution, and also once the release is done, we can backport to our master branch, fixing all potential conflicts. The risk of making a mistake when resolving conflicts with master is less than the risk of making a mistake when resolving conflicts with release.
In practice:

If you're hotfixing, open a PR against branch B (I don't know what to name it, it's supposed to be master, maybe stable? or just branch 1.8 ?)
Once everything is ready in branch B, open bump PR against release, it should contain only branch B + bump commit, review and merge bump PR.
Once bump PR is merged in release, open PR against master to backport all the hotfixes. Here is where we fix all the conflicts when master deviated too much.

@tiborvass does having a branch mean no more RCs?

@moxiegirl no, we could still have RCs.

I think some of this can be automated without a bot, or changing anything about the release process.
We have a set of release scripts in compose that do some of this: https://github.com/docker/compose/tree/master/script/release
Using https://gist.github.com/dnephin/d3f92cc2ab03c5b52424 to iterate over the PRs and  cherry-pick-pr (from the compose release scripts) to run the git am automation described in the OP
This uses github PR "updated" order, which is a bit naive. An improvement could be to order all the PRs based on the first commit ordering in the master branch. In practice using the github PR update order has worked for us so far in compose.
When the iteration hits a PR that can't be merged, it can either drop into a shell to allow for a manual merge, or it could abort the git am and instead track the failed PRs (maybe by opening new PRs against the release branch).

authors: calavera dnephin icecrime moxiegirl thaJeztah tiborvass

repo: docker/leeroy

license: mit


text:
Customising  DockerDesktop virtual machine

Tell us about your request
Security team force us to insert security agent and run-time vulnerabilities scanner into DockerDesktop virtual machine.
Which service(s) is this request for?
DockerDesktop
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
DockerDesktop user can lunch containers with malware and vulnerabilities. So development infrastructure could be compromised. To prevent this, we use security scanners (own).
Now we are looking for a legal solution to customise  DockerDesktop virtual machine.
Are you currently working around the issue?
We are exploring LinuxKit
Additional context
Add any other context or screenshots about the feature request here.

@Tenakh thanks for the feedback, we are currently looking at what might be good to improve the security of Desktop. Would you be interested in jumping on a call to talk through your use cases further? If so drop me an email on bengotch@docker.com

Thanks for the feedback @voliveirajr ! I will pass back the feedback on documentation to the team as well :)

Hello!
I'm looking for a way to add security components into docker vm. Like
iptables setting useful for our network or some other security packages,
with ability to configure them.
Right now, i'm working around installing DockerDesktop for Mac ovet
network.
If you have usefull techniques, please share with me.
Thx.
пт, 24 сент. 2021 г., 18:14 Ben De St Paer-Gotch @.***>:

@Tenakh https://github.com/Tenakh thanks for the feedback, we are
currently looking at what might be good to improve the security of Desktop.
Would you be interested in jumping on a call to talk through your use cases
further? If so drop me an email on @.***
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/docker/roadmap/issues/260#issuecomment-926706986, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AKNF6RNORCSFSGHS6LO6H5TUDSIUJANCNFSM5EAF6SIQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thanks for submitting your issue. We are working hard on improving the visibility and security controls that organisations have over the Docker Desktop Linux VM and will ship our first version of this in the upcoming Docker Desktop v4.13 release. As such, I'll close this issue. We won't be providing the ability to create customized VMs etc.

authors: Tenakh christophermclellan nebuk89 stephanierifai

repo: docker/roadmap


text:
Add a local docker registry

a common use case would be adding a local docker registry..
i tried but was failing..
can you please add it to the shell scripts and compose file.
thanks

docker registry v2 is like very much needed part of swarm .. looking ahead for it ..

repo: docker/swarm-frontends


text:
its possible to run more than one Docker daemon on a single host

but you don't seem to be able to docker-swarm join the second.

out of curiousity, why would one run more than one daemon per host?

I do this all the time using docker-in-docker, but I use a static discovery file, not swarm join (just because it's simpler).

@phemmer simple but not secure at all, say you loose a docker host, from a scheduling point of view  swarm will certainly try to schedule a container on the failed host ....

@david-guenault actually it won't. Swarm detects when nodes are down.

@phemmer realy ? last time i used this backend it was not working this way... gona give it a try. May be i missed something around there.

@phemmer you were right (and i was wrong) swarm with this backend do alive checking for the members. Good ! So yeah it's a good use case. Great i learned another thing today ;-)

@SvenDowideit You should be able to do two joins by specifying two different --addr

@SvenDowideit: Can you verify if that works, and if so, close this issue?
Thanks!

Closing for now - please re-open if needed.

authors: SvenDowideit aluzzardi david-guenault phemmer tnachen

repo: docker/swarm


text:
correct IRC channel

refs #395, as this bit me as well.
Signed-off-by: Matthew Fisher matthewf@opdemand.com

LGTM

thanks

authors: bacongobbler vieux


text:
17.06 won't deploy stack anymore. no suitable node (unsupported platform on 3 nodes) on armhf docker cluster

Hello,
I have an armhf cluster and since 17.06 installed, I'm getting this error and my stacks doesn't come up, it stays as pending forever. There's no constraint. This was working perfectly on 17.03.
Inspecting the task, I'm getting:
        "Status": {
            "Timestamp": "2017-07-02T12:51:00.556959128Z",
            "State": "pending",
            "Message": "no suitable node (unsupported platform on 3 nodes)",
            "ContainerStatus": {},
            "PortStatus": {}
        },

docker info:
Containers: 1
 Running: 1
 Paused: 0
 Stopped: 0
Images: 9
Server Version: 17.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local nfs
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: chzqrk30d8aph7ikg60owdbjz
 Is Manager: true
 ClusterID: 1ucdfzovu4whdawkzv8wbfeb6
 Managers: 3
 Nodes: 3
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Root Rotation In Progress: false
 Node Address: 192.168.178.6
 Manager Addresses:
  192.168.178.6:2377
  192.168.178.7:2377
  192.168.178.8:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: cfb82a876ecc11b5ca0977d1733adbe58599088a
runc version: 2d41c047c83e09a6d61d464906feb2a2f3c52aa4
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.34-45
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: armv7l
CPUs: 8
Total Memory: 1.949GiB
Name: odroid01.casaams.wsartori.com
ID: DRWB:PHMO:GCXF:GDTK:QXDF:V2WM:6ZAM:MC5G:GYID:7YOH:PBQC:BOYE
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 registry:5000
 127.0.0.0/8
Live Restore Enabled: false

probably introduced on https://github.com/docker/swarmkit/commit/8edbb9216533e3ccd41e7e0344227af87d8fd51c by @nishanttotla

@trunet can you show the output for service inspect and also what docker info on the nodes looks like?

docker info is on the first comment.
docker service inspect:
[
    {
        "ID": "n0bhpy9ibyiiv2wkux65x1dsv",
        "Version": {
            "Index": 2286
        },
        "CreatedAt": "2017-07-02T21:13:59.560944718Z",
        "UpdatedAt": "2017-07-02T21:13:59.56740151Z",
        "Spec": {
            "Name": "portal_portal",
            "Labels": {
                "com.docker.stack.image": "arm32v7/httpd:latest",
                "com.docker.stack.namespace": "portal"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "arm32v7/httpd:latest@sha256:90fb0d45f7267ac96523f2030ab842d61c77c65999024b5f67771f599ae4bfa8",
                    "Labels": {
                        "com.docker.stack.namespace": "portal"
                    },
                    "Privileges": {
                        "CredentialSpec": null,
                        "SELinuxContext": null
                    },
                    "Mounts": [
                        {
                            "Type": "bind",
                            "Source": "/mnt/glusterfs/portal",
                            "Target": "/usr/local/apache2/htdocs"
                        }
                    ],
                    "StopGracePeriod": 10000000000,
                    "DNSConfig": {}
                },
                "Resources": {},
                "RestartPolicy": {
                    "Condition": "any",
                    "Delay": 5000000000,
                    "MaxAttempts": 0
                },
                "Placement": {
                    "Platforms": [
                        {
                            "Architecture": "arm",
                            "OS": "linux"
                        }
                    ]
                },
                "Networks": [
                    {
                        "Target": "jzho3a68yjsqvakajo7b9yqv3",
                        "Aliases": [
                            "portal"
                        ]
                    }
                ],
                "ForceUpdate": 0,
                "Runtime": "container"
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 2
                }
            },
            "UpdateConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor": 5000000000,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "RollbackConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor": 5000000000,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "EndpointSpec": {
                "Mode": "vip",
                "Ports": [
                    {
                        "Protocol": "tcp",
                        "TargetPort": 80,
                        "PublishedPort": 80,
                        "PublishMode": "ingress"
                    }
                ]
            }
        },
        "Endpoint": {
            "Spec": {
                "Mode": "vip",
                "Ports": [
                    {
                        "Protocol": "tcp",
                        "TargetPort": 80,
                        "PublishedPort": 80,
                        "PublishMode": "ingress"
                    }
                ]
            },
            "Ports": [
                {
                    "Protocol": "tcp",
                    "TargetPort": 80,
                    "PublishedPort": 80,
                    "PublishMode": "ingress"
                }
            ],
            "VirtualIPs": [
                {
                    "NetworkID": "sposg3gl89sjhlhy1hdpqbwt6",
                    "Addr": "10.255.0.8/16"
                },
                {
                    "NetworkID": "jzho3a68yjsqvakajo7b9yqv3",
                    "Addr": "10.0.1.2/24"
                }
            ]
        }
    }
]

I see the issue.
It seems like the node reports
OSType: linux
Architecture: armv7l

but the image reports
OSType: linux
Architecture: arm

and that causes scheduling to fail. We will need to add more normalization for architecture names. I'll do that but it would be useful to have a full list of architecture name variations.
cc @thaJeztah @aaronlehmann currently we only do this for x86_64 and amd64: https://github.com/docker/swarmkit/blob/master/manager/scheduler/filter.go#L288

I can think of aarch64 armv7l, but they are completely different architecture, aarch64 is 64-bits, armv7l is 32-bits.

@nishanttotla Is there a way to build the image with armv7l architecture instead of only arm, I didn't find anything on commit, push on build to add this? how docker hub is handling that, I suppose all https://hub.docker.com/r/arm32v7/ should uses armv7l?

@trunet I'm not sure about that, but we'll see what's the best way to resolve this. Until then, you can get around this issue by using the --no-resolve-image flag which will not add platform information to your service spec.

@nicolaka  as I'm using stack, I didn't find the --no-resolve-image equivalent on compose 3.3 reference.

@nicolaka found it on https://docs.docker.com/engine/reference/commandline/stack_deploy/ thanks man

@trunet apologies, yes for stacks you can use --resolve-image=never for now.

We will need to add more normalization for architecture names.

Is there a list of valid architectures in the image's data? (Same for nodes)?
ARM is specifically tricky, as there's a lot of variations, and ways to express them (armhf, armv6, armv7 etc.)
If there's a list of valid values, we can decide to ignore other values

Related: https://github.com/opencontainers/image-spec/issues/661
@trunet I'm working on figuring out what the right fix is for this case.

@tianon Do you know how Config.Architecture is getting set for images in arm32v7? Are these just using GOARCH directly or is there a special build process?

@stevvooe that'd be GOARCH directly -- the builder for those actually used to be a 64bit build (and thus was setting Architecture to arm64), but I'm now using a 32bit build of Docker on a 64bit machine and using linux32 to ensure the kernel claims it's also 32bit (just to help cut down on the types of things that can go wrong when cross-building like this), so they should all be set to arm (which is as specific as an individual image manifest can get without a manifest list, as you know)
I think way back in Docker's history, someone thought it'd be helpful to include "multiarch" metadata on images, and just threw in GOOS and GOARCH as-is, and it hasn't been adjusted since.  IMO that'd be better served by having a full platform object ala manifest lists, but figured for individual non-multiarch images it really didn't make much difference either way (especially for image-spec's 1.0).

In the manifest list pushing code we've got (which again, as you know, isn't deployed to library/ just yet), arm32v7 turns into something like the following:
platform:
  os: linux
  architecture: arm
  variant: v7

Ah, see https://github.com/moby/moby/pull/3298/commits/f9359f59a88f109a7764406c33529a20098b0c7f for where those fields were first populated with GOARCH (appears it was hard-coded to x86_64 before, and no OS info).

@tianon The problem with GOARCH on images, is that we lose variant when assembling Platform from an image configuration: https://github.com/moby/moby/blob/master/api/server/router/distribution/distribution_routes.go#L120.
For the vast number of cases, I think we can assume variant is v7 but I am sure that will break.

Indeed -- I'm 100% with you on GOARCH being insufficient, which is why I wish individual non-list manifests had a full platform object so that this could be set properly. :disappointed:
To give another example that's completely broken, all the images under i386 will have Architecture set to amd64, since I don't build them on real 32bit hardware (and didn't want to compile a custom Docker binary just to do those builds).  They only exist (in my mind) as a rough sanity check for a simple way to test multiarch (since they can build on any amd64 machine as-is), but their metadata being wrong irks me a lot (it'll be correct when they're included in a manifest list, as seen under trollin, but the individual image metadata will be wrong until/unless we get additional support in Docker itself for informing it what it should be putting there).
It's even conceivable to build s390x images on an amd64 daemon, as long as they don't have any RUN lines (ie, FROM scratch, ADD tarball /, etc), or as long as appropriate qemu bits are in the right places somehow.
Here's a more concrete example:
$ manifest-tool inspect trollin/httpd:latest
Name:   trollin/httpd:latest (Type: application/vnd.docker.distribution.manifest.list.v2+json)
Digest: sha256:6f43aac63ceb4fbfee6a724f3d8aeec4366bb83cd7ef37a9905ccf2256ba8557
 * Contains 6 manifest references:
1    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
1       Digest: sha256:8f58a3ef340038615498cead8b83fa3b31e4fe5c16961c6c3635e973ac9303ed
1  Mfst Length: 1780
1     Platform:
1           -      OS: linux
1           - OS Vers:
1           - OS Feat: []
1           -    Arch: amd64
1           - Variant:
1           - Feature:
1     # Layers: 7
         layer 1: digest = sha256:9f0706ba7422412cd468804fee456786f88bed94bf9aea6dde2a47f770d19d27
         layer 2: digest = sha256:47bacf36113fe830a77280f81a8203a228fa4bb4536f145a333709b9da0f7cf7
         layer 3: digest = sha256:56798d8e5a3081371b84de38415c30c0f1ae034e4d57d82383c468a95521fc53
         layer 4: digest = sha256:94b25413538ac04aa893f729c216553d9c86b0ea69318cfe903e16eb078492b7
         layer 5: digest = sha256:97d879f4e260dd8d46a4eaf0c29f253a501fa82337840c30a6274de23227ab6e
         layer 6: digest = sha256:2a4f7e960a3e3b32308101dec9c1525b961a242dca799737d2ad0c3e19350b42
         layer 7: digest = sha256:12f5eb5312902eedee33d3b8d0f2abc7750f3ae7e32733b26547371f8eb6b034

2    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
2       Digest: sha256:90fb0d45f7267ac96523f2030ab842d61c77c65999024b5f67771f599ae4bfa8
2  Mfst Length: 1780
2     Platform:
2           -      OS: linux
2           - OS Vers:
2           - OS Feat: []
2           -    Arch: arm
2           - Variant: v7
2           - Feature:
2     # Layers: 7
         layer 1: digest = sha256:72c70f9f7d679945bc71d954dc0c7de236e0067af495d09e9bea24f497cc79b7
         layer 2: digest = sha256:c3529be5f104abaa0a6777ce5aa3d62a14d637886a4eebc1fc8ed730c4009654
         layer 3: digest = sha256:d8da62524d5de9ecb71f0046c66d3a291e6b2f81496a07d28e30b4e81f04ac51
         layer 4: digest = sha256:7d7da9871d55dac5ea74a2b5f684f5c94bb5ca9b51ff5f2a81330facfcf67122
         layer 5: digest = sha256:c2c771d498cd865c5dff06aa02340b0c859cebcbe6a88246c7e87e287ab70c48
         layer 6: digest = sha256:de5a89172d87cbecee5e7924eb3c003458ad751d51e25eaed5d8a89912ef3ccb
         layer 7: digest = sha256:a922909dfad204174854c24774fc54c9016d96d587480b6d40c0c56ae73612a7

3    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
3       Digest: sha256:21920abf229fd278a820287cb8fbe9db206ecbbb4b5bd8a34aab0af8b9c0f470
3  Mfst Length: 1780
3     Platform:
3           -      OS: linux
3           - OS Vers:
3           - OS Feat: []
3           -    Arch: arm64
3           - Variant: v8
3           - Feature:
3     # Layers: 7
         layer 1: digest = sha256:0dcb325d306f51780dbde5818f38ed8b0e8f478b56132f46bb5c30385f86eaa6
         layer 2: digest = sha256:0a2d58b6ee283f9f76e8f06d3fac65e85b9e289df29ca44dc9314586e055cecc
         layer 3: digest = sha256:eac331a2af3233030fcf1ad5300f9684767ebc08b8447e52b00783cb43de360a
         layer 4: digest = sha256:b382ea768f87d2a04cac208183cd6ee2b487748fb7fe33a9f0e6c4ab0912a029
         layer 5: digest = sha256:313fc6a3542b845ea9d51e727b1b0270de45d71e58a4cbd5e68c427761ce8107
         layer 6: digest = sha256:1a9a6cd7e8894b6345a3d83a4cefba76609c8e096d5163a67c0dee33c7927ffb
         layer 7: digest = sha256:26af40e76c32da3f9b7eac5f62d73ee6d51c30f0b257e37596da4bcbb7e34877

4    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
4       Digest: sha256:261d6c4753982e203308fc5c637a74bdcd986a2edbab7d8aac39a391cae7a683
4  Mfst Length: 1780
4     Platform:
4           -      OS: linux
4           - OS Vers:
4           - OS Feat: []
4           -    Arch: 386
4           - Variant:
4           - Feature:
4     # Layers: 7
         layer 1: digest = sha256:2fa359c89a0e952ec2fe14e3c584ee13d6ec919c73a7dcac34ba320a459e2a62
         layer 2: digest = sha256:19378a3c2be7bef3f223e1ca4a0391c966e6330d8692ed17042471f25509713b
         layer 3: digest = sha256:9e17073700efe44252f1c00a14cf28030458d929d0de85f4873189e23b218530
         layer 4: digest = sha256:38c6ce3cfa9a4835b70425932f1da52dc06e8416369192b5b2fd0768956b907d
         layer 5: digest = sha256:23815ae9a9b769433bf361d90f0654af265d56f7792633aaae368cc17d8af505
         layer 6: digest = sha256:7951cc644f4c9b2aa30c2a8653ce4d2b7ac8390fb72dab2e6f5d3f522bbe738d
         layer 7: digest = sha256:381d02ad82455287029be0a8cf1a1cae9915c26289bac3c24ed7636ba77c6795

5    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
5       Digest: sha256:343ea34611a882700bf162ad929c42259446088d9933991addc64bc90af8f17e
5  Mfst Length: 1780
5     Platform:
5           -      OS: linux
5           - OS Vers:
5           - OS Feat: []
5           -    Arch: ppc64le
5           - Variant:
5           - Feature:
5     # Layers: 7
         layer 1: digest = sha256:a5561821dba4ceb47be1d2f5f108a24b391df9d6a3a764d2c04ea8ac29410625
         layer 2: digest = sha256:39c4390b614987e9576d36928eb4d12a6d5e160fb83b5095198efd400b6b8c5b
         layer 3: digest = sha256:d14c381984db757a959e0f35eb170b4863f5c5e8570702bb7529f4f88998f73a
         layer 4: digest = sha256:90d23acf5ff39880a4a787a1d41e6bc4b204a7e01fc2e60183892c20aa60c5c4
         layer 5: digest = sha256:77e6d79cd73f74c4071006e03344deccab113906c139d8755461d4fd72604b1e
         layer 6: digest = sha256:e3649c2d25a8bf9910fe5f9f940924ef00277ca9a003c5fcaaeb487f116def62
         layer 7: digest = sha256:67e875c10908fb1f66c807700e155e51ccc053f596e93f0d0f1aff26240aa46f

6    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
6       Digest: sha256:3c121d29d5f0c2bb4fdc54fa2e206bb9d6a4b751e29de571b4ef5af7b80c20f6
6  Mfst Length: 1780
6     Platform:
6           -      OS: linux
6           - OS Vers:
6           - OS Feat: []
6           -    Arch: s390x
6           - Variant:
6           - Feature:
6     # Layers: 7
         layer 1: digest = sha256:29420dd727d39cbedfb85562111f49e24b0b96adda04de4663d2099fbbf4f993
         layer 2: digest = sha256:0eb60e029192948c200dc12526bcb19c36747de3cedae3822c3009d6250b95b9
         layer 3: digest = sha256:f2cee80bd07440bd13eb077947699252cbfba9b263af2a43bd94f31378a5c35c
         layer 4: digest = sha256:b628a0b163be3123753102d5269918189e0ff4f2cecc25b8ebb685a7e292435e
         layer 5: digest = sha256:9c67f623c538f560836daac0ea7ab1ffa883c09b87ae7b426fed7e4b828e466b
         layer 6: digest = sha256:0bf51bf880e17e555e66c3af906cd603deae0af6095d1816ffb364b9d16e426d
         layer 7: digest = sha256:16c1cb76b65df18dfffd6e1f23e843c3ddebd950f5e8ea24fd98be6c8b5997ad

(which was built by combining amd64/httpd:latest, arm32v7/httpd:latest, etc)
The info for busybox:latest is likely even better, since it'll have several arm variants:
$ manifest-tool inspect trollin/busybox:latest | grep -A7 'Platform:'
1     Platform:
1           -      OS: linux
1           - OS Vers:
1           - OS Feat: []
1           -    Arch: amd64
1           - Variant:
1           - Feature:
1     # Layers: 1
--
2     Platform:
2           -      OS: linux
2           - OS Vers:
2           - OS Feat: []
2           -    Arch: arm
2           - Variant: v5
2           - Feature:
2     # Layers: 1
--
3     Platform:
3           -      OS: linux
3           - OS Vers:
3           - OS Feat: []
3           -    Arch: arm
3           - Variant: v6
3           - Feature:
3     # Layers: 1
--
4     Platform:
4           -      OS: linux
4           - OS Vers:
4           - OS Feat: []
4           -    Arch: arm
4           - Variant: v7
4           - Feature:
4     # Layers: 1
--
5     Platform:
5           -      OS: linux
5           - OS Vers:
5           - OS Feat: []
5           -    Arch: arm64
5           - Variant: v8
5           - Feature:
5     # Layers: 1
--
6     Platform:
6           -      OS: linux
6           - OS Vers:
6           - OS Feat: []
6           -    Arch: 386
6           - Variant:
6           - Feature:
6     # Layers: 1
--
7     Platform:
7           -      OS: linux
7           - OS Vers:
7           - OS Feat: []
7           -    Arch: ppc64le
7           - Variant:
7           - Feature:
7     # Layers: 1
--
8     Platform:
8           -      OS: linux
8           - OS Vers:
8           - OS Feat: []
8           -    Arch: s390x
8           - Variant:
8           - Feature:
8     # Layers: 1

For building the individual architecture images, I'm not doing anything special or custom beyond docker build, docker tag, docker push.

Indeed -- I'm 100% with you on GOARCH being insufficient

For arm, I should have qualified. All other architectures have sufficient information.
We'll either need this on the manifest or all the way down on the config (not sure if we really want to take that on). Seems, as is, there is no way to resolve the arm properties from the config itself and that the contents of Config.Architecture is generally dubious (at least for cross-builds).
Do we need to file a bug with OCI image-spec?

@tianon ^
As far as a solution, I think we should remove the automatic constraint on architecture unless reporting on a multi-platform image. That will allow swarm to meet the image matching use case for windows/linux.

I think that makes sense, especially since if it's not a manifest list, the notion of it being "multiarch" is kind of bogus anyhow (since the arch information is likely also bogus, or at least misleading).  The OS field might be accurate, but it's hard to say in that case.  These architecture constraints can be directly added by hand, right?
As for filing a bug with the image-spec, I think that makes sense, but I didn't want to try and rock that boat pre-1.0 (since as shown by the commit I linked, it's a real old boat), and hadn't looked to see whether the image config itself was covered by the spec (but it makes sense for it to be). :innocent:

(I have to confess that I haven't tried building FROM scratch on Windows to see if I could cross-build a Linux image that way. :sweat_smile:)

@tianon The image config is covered by the spec, unfortunately. For the cases where cross builds are happening, the image will have to be modified post-build. In the case where we just want to route a workload a host that can run that image, we likely don't have enough information, as that will have to be wrapped in a manifest list (index) to provide the actual platform information in the ARM case.

I ran into the same issue today. I run a manager on amd64 and have a node which is armv6l. It's a raspberrypi model b+. I can run the image on the node itself, but when I want to run it as a swarm service it says:
"Message": "no suitable node (unsupported platform on 4 nodes)"
Btw. I also have two amd64 nodes.
It seems it can't map the arm image on armv6l in the swarm scheduler.

The Scaleway C1 machine shows armv7l, as well as Raspberry Pi 2/3
Raspberry Pi 0/1 show armv6l
Docker images have arm as architecture.
So probably the platformEqual() should have the same normalization as for x86_64 -> amd64:
	switch imgPlatform.Architecture {
	case "x86_64":
		imgPlatform.Architecture = "amd64"
	case "armv6l", "armv7l":
		imgPlatform.Architecture = "arm"
	case "aarch64":
		imgPlatform.Architecture = "arm64"
	}
	switch nodePlatform.Architecture {
	case "x86_64":
		nodePlatform.Architecture = "amd64"
	case "armv6l", "armv7l":
		nodePlatform.Architecture = "arm"
	case "aarch64":
		nodePlatform.Architecture = "arm64"
	}

Something like this?

@nishanttotla any ideas to my comment https://github.com/docker/swarmkit/issues/2294#issuecomment-313954317 to fix platformEqual() for ARM introduced in #2180?
Is this approach a good idea that will get merged having some tests for it?
I have never built swarmkit on RPi/Scaleway to have a dev environment for it, so I ask in advance :-)

@StefanScherer while your suggestion might solve this problem, it might not be the right place to fix it, especially with the large number of arm variants. There is a Docker PR to fix this until we can fix the root cause: https://github.com/moby/moby/pull/34021

@nishanttotla what is the likelihood of that Moby issue being part of the 17.07 release?
If Docker CE ships this way then Swarm and stacks are completely broken for RPi. It would be better not to ship ARM binaries than degrade the experience of anyone who upgrades. It's the issue tracker and community that will be having to explain why it's broken and any work-arounds.

@alexellis I agree. This is not a good situation and I am worried that having these constraints will create mutual incompatibilities.
Could you see if moby/moby#34021 will work?

I have all nodes with Platform: linux armv7l and have to use --no-resolve-image, otherwise swarm services are in constant pending state.
Docker: 17.06.1-ce

@stevvooe the PR by @nishanttotla fixes the issue - I've spent the whole day testing it... :-/
@Toshik I don't believe your work-around is good for stacks?

@alexellis, no, it is ugly workaround. And I had to recreate all services with just docker service create command :(

Just take this PR it fixes everything.

Closing since https://github.com/moby/moby/pull/34021 was merged. A longer term resolution of ARM variants will take time, but it is no longer the case that tasks don't run, so we can consider this issue resolved.

Same problem on 17.09, have to rollback on 17.06

@MLescaudron this should be fixed now. Can you share the output of docker info on one of your worker nodes that has ARM, and the output of docker service inspect <service name> for the service that fails to run?

Docker info (previously I was in 17.09.2-ce)
Containers: 21
 Running: 11
 Paused: 0
 Stopped: 10
Images: 14
Server Version: 17.06.2-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: vjh2cujrci6sjus9lyhjm87po
 Is Manager: true
 ClusterID: b70lb8nciap52uncs76xnfkfl
 Managers: 1
 Nodes: 4
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Root Rotation In Progress: false
 Node Address: 145.239.13.20
 Manager Addresses:
  145.239.13.20:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 6e23458c129b551d5c9871e5174f6b1b7f6d1170
runc version: 810190ceaa507aa2727d7ae6f4790c76ec150bd2
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-81-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 14.34GiB
Name: ovh-prod-1
ID: TXNV:VBKT:MFJD:4K7W:G3JH:WDB7:LZZF:3SWD:LVQO:6SFP:WOPE:AN7E
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: nelioapp
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

docker service inspect
[
    {
        "ID": "0rvq0tmowj9nfn2gjgp0hzmyd",
        "Version": {
            "Index": 69574
        },
        "CreatedAt": "2017-09-26T22:31:04.605418562Z",
        "UpdatedAt": "2017-10-02T22:13:46.09779364Z",
        "Spec": {
            "Name": "tech_blog",
            "Labels": {
                "com.docker.stack.image": "ghost:alpine",
                "com.docker.stack.namespace": "tech"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "ghost:alpine@sha256:b7c4fcb9e78518ea85fcba80969f445301b38f76833a6668eb268da7b6e7f3a4",
                    "Labels": {
                        "com.docker.stack.namespace": "tech"
                    },
                    "Privileges": {
                        "CredentialSpec": null,
                        "SELinuxContext": null
                    },
                    "Mounts": [
                        {
                            "Type": "bind",
                            "Source": "/home/nelio/tech.nelio.io/",
                            "Target": "/var/lib/ghost/content"
                        }
                    ],
                    "StopGracePeriod": 10000000000,
                    "DNSConfig": {}
                },
                "Resources": {},
                "RestartPolicy": {
                    "Condition": "any",
                    "Delay": 5000000000,
                    "MaxAttempts": 0
                },
                "Placement": {
                    "Constraints": [
                        "node.role == manager"
                    ],
                    "Platforms": [
                        {
                            "Architecture": "amd64",
                            "OS": "linux"
                        }
                    ]
                },
                "Networks": [
                    {
                        "Target": "omgpnj44fbx9y7khp6pxmptq7",
                        "Aliases": [
                            "blog"
                        ]
                    }
                ],
                "LogDriver": {
                    "Options": {
                        "max-size": "50m"
                    }
                },
                "ForceUpdate": 0,
                "Runtime": "container"
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 1
                }
            },
            "UpdateConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor": 5000000000,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "RollbackConfig": {
                "Parallelism": 1,
                "FailureAction": "pause",
                "Monitor": 5000000000,
                "MaxFailureRatio": 0,
                "Order": "stop-first"
            },
            "EndpointSpec": {
                "Mode": "vip"
            }
        },
        "PreviousSpec": {
            "Name": "tech_blog",
            "Labels": {
                "com.docker.stack.image": "ghost:alpine",
                "com.docker.stack.namespace": "tech"
            },
            "TaskTemplate": {
                "ContainerSpec": {
                    "Image": "ghost:alpine@sha256:b7c4fcb9e78518ea85fcba80969f445301b38f76833a6668eb268da7b6e7f3a4",
                    "Labels": {
                        "com.docker.stack.namespace": "tech"
                    },
                    "Privileges": {
                        "CredentialSpec": null,
                        "SELinuxContext": null
                    },
                    "Mounts": [
                        {
                            "Type": "bind",
                            "Source": "/home/nelio/tech.nelio.io/",
                            "Target": "/var/lib/ghost/content"
                        }
                    ]
                },
                "Resources": {},
                "Placement": {
                    "Constraints": [
                        "node.role == manager"
                    ],
                    "Platforms": [
                        {
                            "Architecture": "amd64",
                            "OS": "linux"
                        }
                    ]
                },
                "Networks": [
                    {
                        "Target": "omgpnj44fbx9y7khp6pxmptq7",
                        "Aliases": [
                            "blog"
                        ]
                    }
                ],
                "LogDriver": {
                    "Options": {
                        "max-size": "50m"
                    }
                },
                "ForceUpdate": 0,
                "Runtime": "container"
            },
            "Mode": {
                "Replicated": {
                    "Replicas": 1
                }
            },
            "EndpointSpec": {
                "Mode": "vip"
            }
        },
        "Endpoint": {
            "Spec": {
                "Mode": "vip"
            },
            "VirtualIPs": [
                {
                    "NetworkID": "omgpnj44fbx9y7khp6pxmptq7",
                    "Addr": "10.0.0.5/24"
                }
            ]
        }
    }
]

@MLescaudron your node reports linux/x86_64 and your service placement constraints report linux/amd64. This is a compatible combination, and your service should run. There maybe another reason why it's failing.

Ok, so I have unistall and reinstall docker-ce on each node.
When I launch a service, docker ps return an empty response and the state is on pending mode.
Same problem as @trunet

Same here with 17.09
Docker info: linux aarch64
Docker inspect task: linux arm64
Docker inspect container: linux arm64
Task status: "State": "pending", "Message": "unsupported platform on 1 node"

It seems that #34021 should have excluded more cases in addition to just "arm", like "arm64".
cc @thaJeztah @andrewhsu

This appears to be broken again on ARM64 :-( in particular I have a weird situation where it will work on Dieter's ARM64 RPi image but not on Packet's Qualcomm machine - both are "aarch64" in uname.
Packet:
docker service create --name func_prometheus  luxas/prometheus-arm64:v1.5.2
root@48-cores:~# uname -a
Linux 48-cores 4.10.0-19-generic #21ubuntu+caf.3-Ubuntu SMP Wed May 3 19:00:13 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root@48-cores:~# docker service ls
ID                  NAME                MODE                REPLICAS            IMAGE                           PORTS
8gv14xs5r0dk        func_prometheus     replicated          0/1                 luxas/prometheus-arm64:v1.5.2
root@48-cores:~# docker run -ti luxas/prometheus-arm64:v1.5.2
INFO[0001] Starting prometheus (version=1.5.2, branch=master, revision=bd1182d29f462c39544f94cc822830e1c64cf55b)  source=main.go:75
INFO[0001] Build context (go=go1.7.5, user=root@a8af9200f95d, date=20170210-15:09:12)  source=main.go:76
INFO[0001] Loading configuration file /etc/prometheus/prometheus.yml  source=main.go:248
INFO[0001] Loading series map and head chunks...         source=storage.go:373

root@48-cores:~# docker service create --name func_prometheus  luxas/prometheus-arm64:v1.5.2
DEBU[2017-10-09T20:36:21.741818950Z] Calling GET /_ping
DEBU[2017-10-09T20:36:21.742930000Z] Calling GET /_ping
DEBU[2017-10-09T20:36:21.746669250Z] Calling GET /v1.32/distribution/luxas/prometheus-arm64:v1.5.2/json
DEBU[2017-10-09T20:36:22.147220750Z] Calling POST /v1.32/services/create
DEBU[2017-10-09T20:36:22.147412700Z] form data: {"EndpointSpec":{"Mode":"vip"},"Labels":{},"Mode":{"Replicated":{}},"Name":"func_prometheus","TaskTemplate":{"ContainerSpec":{"DNSConfig":{},"Image":"luxas/prometheus-arm64:v1.5.2@sha256:7011cf4a94d350cc6719b7a87eaa2cd7cbcc19bcfcf081eae4b9b6ae5f9e00d0"},"ForceUpdate":0,"Placement":{"Platforms":[{"Architecture":"amd64","OS":"linux"}]},"Resources":{"Limits":{},"Reservations":{}}}}
DEBU[2017-10-09T20:36:22.161471000Z] Service hzxpjiytu97jfz931oduom8o8 was scaled up from 0 to 1 instances  module=node node.id=xl2vxso5gh504rosy2u9nyqkc
hzxpjiytu97jfz931oduom8o8
Since --detach=false was not specified, tasks will be created in the background.
In a future release, --detach=false will become the default.
root@48-cores:~# DEBU[2017-10-09T20:36:22.246894100Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=yj0vos4kyogoklebm3dvw50xb
DEBU[2017-10-09T20:36:22.246938550Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=syppv5tnsr77hzst6tahy0imq
DEBU[2017-10-09T20:36:22.336576750Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=syppv5tnsr77hzst6tahy0imq
DEBU[2017-10-09T20:36:22.336625100Z] no suitable node available for task           module=node node.id=xl2vxso5gh504rosy2u9nyqkc task.id=yj0vos4kyogoklebm3dvw50xb

DEBU[2017-10-09T20:36:36.378193650Z] Calling GET /v1.32/version
Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:10 2017
 OS/Arch:      linux/arm64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:38:22 2017
 OS/Arch:      linux/arm64
 Experimental: false```

@alexellis Looking at the patch that should have fixed this, it seems like this case is not covered. Although, it seems like the placement constraint clearly reads amd64, from the log message.

OK, there's something funny going on here.
ed$ docker run --rm mplatform/mquery luxas/prometheus-arm64:v1.5.2
Manifest List: No
 Supports: amd64/linux

It looks like @luxas has a prometheus-arm64 image that advertises that it supports amd64/linux.

Looking at the configuration, the architecture is reported as amd64:
$ ctr fetch-object docker.io/luxas/prometheus-arm64@sha256:7663b9e02bac80a6b5e48ffb0602c2d515261dc2afcf10cb819fc563b8bc4126 | jq .
INFO[0000] resolving                                     ref="docker.io/luxas/prometheus-arm64@sha256:7663b9e02bac80a6b5e48ffb0602c2d515261dc2afcf10cb819fc563b8bc4126"
INFO[0001] fetching                                      ref="docker.io/luxas/prometheus-arm64@sha256:7663b9e02bac80a6b5e48ffb0602c2d515261dc2afcf10cb819fc563b8bc4126"
{
  "architecture": "amd64",
...

Were these "cross-built" binaries?

Looks like @luxas has a multiarch image, cf
ed$ docker run --rm mplatform/mquery luxas/prometheus:v2.0.0-rc.0
Manifest List: Yes
Supported platforms:
 - amd64/linux
 - arm/linux (variant: undefined)
 - arm64/linux (variant: undefined)

also
ed$ docker run --rm mplatform/mquery luxas/prometheus:v1.7.1
Manifest List: Yes
Supported platforms:
 - amd64/linux
 - arm/linux (variant: undefined)
 - arm64/linux (variant: undefined)

@vielmetti @stevvooe Yes, I'm crossbuilding everything. That's by far the best way to do things IMO. Don't know if docker lets me set the os/arch (I don't think so?)

@luxas Cross-building won't work unless you re-pack into manifest list or re-write the configuration with the correct architecture.
@vielmetti There is no variant field in the base image config, so it won't be defined. We can add one there if this is a huge problem.

@luxas Cross-building won't work unless you re-pack into manifest list or re-write the configuration with the correct architecture.

@stevvooe Can you point to docs how to mutate OS/arch for a given (non-manifest-list) image? e.g. for luxas/prometheus-arm64

This patch https://github.com/docker/swarmkit/pull/2411 addresses the issue.

authors: MLescaudron StefanScherer Toshik alexellis beatkyo broersa luxas nishanttotla stevvooe thaJeztah tianon trunet vielmetti

repo: docker/swarmkit


text:
Problem with mapper

Hello!
Somehow mapper is duplicating queries on orm:schema-tool:update --dump-sql command with latest PostgreSQL.
I have repeatedly for each jsonb field queries:
ALTER TABLE table ALTER jsonb TYPE JSONB;
ALTER TABLE table ALTER jsonb DROP DEFAULT;

@tasselchof can it be somehow related to https://github.com/doctrine/dbal/pull/2782#issuecomment-322246167? If so, we should keep it only on dbal.
I haven't had the time to take a look on the options (rather than just reverting that specific commit) but if would be really nice to have some help over there.

@lcobucci this is indeed the DBAL issue.

@stof thanks! I'm in Brazil right now and am not really being able to work on this but I'll go back home in this weekend :wink:

@tasselchof being fixed on https://github.com/doctrine/dbal/pull/2855

The same thing happening with indexes with cases:
DROP INDEX si_type_unique_idx;
CREATE UNIQUE INDEX si_type_unique_idx ON storage_items (warehouse_id, sku) WHERE state IS NOT NULL AND state = 'unique';

@tasselchof https://github.com/doctrine/dbal/releases/tag/v2.6.3 has just been released, can you please check if things work fine now?

Yes, I saw this, but it didn't helped, still:
DROP INDEX si_type_unique_idx;
CREATE UNIQUE INDEX si_type_unique_idx ON storage_items (warehouse_id, sku) WHERE state IS NOT NULL AND state = 'unique';

@tasselchof humm, can you try to submit a PR on DBAL with a test that reproduces it? You can use this as example:
https://github.com/doctrine/dbal/blob/8c1e5136939311121d1e1f75d2f6bcd4ec9e5862/tests/Doctrine/Tests/DBAL/Functional/Schema/SchemaManagerFunctionalTestCase.php#L1206-L1336

I'll do it in the middle of the week.

authors: lcobucci stof tasselchof


text:
SORN spider addition

I added the Non-Scrapy one first before I remember that we are all switching over.
I can remove all of those references if that is better but it does work if you run it the old way.
This is for System of Record Notification and uses the Federal registry API (https://www.federalregister.gov/developers/documentation/api/v1)
The example output file contains 1310 records.

@meglynkau
Downloader finished with no errors, nothing in the dead_queue.json

@meglynkau any other things you would like to see addressed?

@dakotahavel Do those changes work?

repo: dod-advana/gamechanger-crawlers

license: MIT


text:
poor performance on sherlock holmes devil's daugther

Software information
Sherlock Holmes Devil's daughter
System information

GPU: amd gigabyte rx460 4gb
Driver: mesa 19.0.1
Wine version: Proton 4.2
DXVK version: 1.0.1
CPU: Ryzen 1600
Ram: 12gb ddr4 2400mhz

Apitrace file(s)
https://drive.google.com/file/d/1LjQPajXke2s8_GT5Nf92RQWwY0xajyje/view?usp=sharing
Log files

d3d11.log: https://drive.google.com/file/d/1-1VGGWcT_1_5Mcx7cwY0YT7aifkAZljz/view?usp=sharing
dxgi.log: https://drive.google.com/file/d/1kKwWEi5HGEbE7EyqUsyi8VzN6NmYRETJ/view?usp=sharing

And what exactly is "poor performance"?

steam version doesn't work cause of denuvo you need gog version.

And what exactly is "poor performance"?

freezes, lags

This is completely normal as long as new shaders are being compiled, and not a bug.

*up

This is completely normal as long as new shaders are being compiled, and not a bug.

too bad is barely playable but to be fair it happens with other games like shadow of the tomb raider with my system, maybe I need a more powerful gpu. closing.

Some games are worse than others, Shadow of the Tomb Raider is also known for being problematic due to the sheer number of different shaders it has. There's no reasonable way to fix this unfortunately.

Some games are worse than others, Shadow of the Tomb Raider is also known for being problematic due to the sheer number of different shaders it has. There's no reasonable way to fix this unfortunately.

I could try using AMDVLK driver instead, would that help?

Not really. The proprietary driver is a bit faster, but also has issues with a lot of games (including SotTR).

authors: Macribit doitsujin

repo: doitsujin/dxvk

license: Zlib


text:
Цветовая тема Github кнопки не меняется

Кнопка github в футере не меняет свою тему при смене темы на сайте ни в Chrome, ни в FireFox
Опишу с самого начала:
Цветовые параметры OC:

Цветовые параметры браузера Chrome:

Отображение кнопки во всех темах сайта:

Авто
Светлая
Тёмная 🔴

Цветовые параметры браузера FireFox:

Отображение кнопки во всех темах сайта:

Авто
Светлая 🔴
Тёмная

Таким образом кнопка не меняется при смене темы на сайте

@skorobaeus, 😭

API кнопок по умолчанию (https://buttons.github.io/) даёт только подстраивать темы под настройки системы. Надо пошаманить со стилями виджета чтобы переключалось по тогглеру

Ну значит надо сделать свою кнопку :)

authors: TatianaFokina igsekor solarrust vitya-ne

repo: doka-guide/platform


text:
🛑 introdex.io is down

In e18db78, introdex.io (https://introdex.io) was down:

HTTP code: 456
Response time: 352 ms

Resolved: introdex.io is back up in 2a33e16 after 8 minutes.

repo: dokazhi/dkz-uptime


text:
The field order for OKLCH

Hey! Thanks for the update that brings P3. I’m continuing to test it, but at first glance, it looks great!
Every time I use the plugin, I have to wrap my head around this control.

The order here is H, C, and L. This order contradicts the parameter order in the CSS notation and even the space name: LCH.
I would suggest changing the field order according to the selected color space. So it would be H, S, L for HSL, and L, C, H for OKLCH.

Hi, for that you can use OkLCH (CSS) mode from the models' dropdown, as explained in plugin's page (FAQ > "Why is there "OkLCH" and "OkLCH (CSS)"?") I've made the choice to keep the simplified OkLCH notation with inverted order for users that come from years of using HSL 🙂.

Hm, got it, thank you.
What’s bothering me is that when someone chooses the OKLCH mode, they expect to get conventional LCH experience. However, in the plugin, they will get an unusual parameter order and an unusual Chroma value formatting.
Furthermore, I believe it would be better if all tools look and work consistently. Introducing unconventional variations might hinder user adoption.
What do you think?

Indeed, I'm thinking about it.
I kept this value for users that were using it before the last update, as I see it, many designers are still used to HSL/HSB models and if they want the true CSS formatting they can choose "OkLCH (CSS)".
However, I agree it can bring confusion on why they are two notations with one that's not conventional.
What I'm seeing for next update is to only have "OkLCH" in the dropdown which by default would be in the correct CSS notation and add a new settings screen in the plugin with the choice to change the order and value formatting if the user wants it (and possibly others options like changing the format of "88.4%" to 0.884 for L value).

authors: dokozero romashamin

repo: dokozero/okcolor


text:
Mobile version

Hello. Could it work on mobile like it works on desktop with page transitions?
Thanks!

Hello santicros,
Thank you for open an issues :)
Currently, Vue Booklet can not use page transitions effect on mobile. It may be little difficult but I can try to make it be a new feature.


text:
Question: RequestSnippetsEnabled Option Exposed?

I noticed the CURL command changed and according to the group at swagger-api, it was changed to BASH style. They said if the requestSnippetsEnabled option was exposed, I could enable the Windows specific cURL command.

While the SwaggerUI middleware doesn't currently have a top-level config method for this, it does have a mechanism to add any config items you like. For example, I was able to enable the request snippets plugin as follows:
app.UseSwaggerUI(c =>
{
    c.ConfigObject.AdditionalItems.Add("requestSnippetsEnabled", true);
});

Might be worth playing around with this technique to get the behavior you're looking for. Also, if you get it figured out, you could possibly submit an MR to add support for this on the top-level / strongly-typed config options 😉

Thanks. I tested this code and it works. Be nice to be able to move the tabs or hide them. However, thats beyond my skill haha.
Thanks for the help.


text:
How to add more databases?

I found this library while trying to determine why github.com/shift/domain_exporter didn't understand .il and .au country codes.  It appears I need to add new adapter implementations for this, but I could be wrong.  Some tips would be appreciated.

Hello @the-maldridge, this seems unrelated to the domainr/whois codebase, and probably better suited for Stack Overflow?

I would have assumed that adding support to query additional whois databases would have been suited to this project.  It appears however that a questionably implemented parse function in https://github.com/shift/domain_exporter is to blame for the incorrect domain handling.

authors: case the-maldridge

repo: domainr/whois


text:
TypeError: BundleDeclarationsWebpackPlugin is not a constructor

I am getting this error when merging typescript files using the Webpack BundleDeclarationsWebpackPlugin.
TypeError: BundleDeclarationsWebpackPlugin is not a constructor

What's wrong with my configuration below?
My Webpack config is:
const path = require('path');
const nodeExternals = require('webpack-node-externals');
const BundleDeclarationsWebpackPlugin = require("bundle-declarations-webpack-plugin");

module.exports = {
  entry: './src/index.ts',
  mode: 'production',
  output: {
   ...
  },
  devtool: 'source-map',
  module: {
      ...
  },
  plugins: [
    new BundleDeclarationsWebpackPlugin({
      entry: './dist/types/index.d.ts',    //specify the entry point for your declaration file (defaults to 'index.d.ts')
      outFile: './dist/index.d.ts',        //specify the output file name (defaults to 'index.d.ts')
    }),
  ],
  resolve: {
    extensions: ['.tsx', '.ts', '.js']
  }
};

package.json:
"devDependencies": {
    "@babel/cli": "^7.25.9",
    "@babel/core": "^7.26.0",
    "@babel/preset-env": "^7.26.0",
    "@babel/preset-react": "^7.25.9",
    "@babel/preset-typescript": "^7.26.0",
    "@rollup/plugin-commonjs": "28.0.1",
    "@rollup/plugin-node-resolve": "15.3.0",
    "@types/node": "^22.9.0",
    "@types/react": "^18.3.12",
    "@types/react-dom": "^18.3.1",
    "@types/webpack": "^5.28.5",
    "@types/webpack-dev-server": "^4.7.2",
    "@types/webpack-node-externals": "^3.0.4",
    "babel-loader": "^9.2.1",
    "bundle-declarations-webpack-plugin":"5.1.1",
    "css-loader": "^7.1.2",
    "html-webpack-plugin": "5.6.3",
    "sass-loader": "16.0.3",
    "style-loader": "^4.0.0",
    "ts-loader": "^9.5.1",
    "ts-node": "^10.9.2",
    "typescript": "^5.6.3",
    "webpack": "^5.96.1",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "5.1.0",
    "webpack-node-externals": "3.0.0"
  },

tsconfig.json
{
  "compilerOptions": {
    "target": "es2016", /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
    "jsx": "react-jsx", /* Specify what JSX code is generated. */
    "module": "ESNext", /* Specify what module code is generated. */
    "moduleResolution": "bundler", /* Specify how TypeScript looks up a file from a given module specifier. */
    "resolveJsonModule": true, /* Enable importing .json files. */
    "declaration": true, /* Generate .d.ts files from TypeScript and JavaScript files in your project. */
    "sourceMap": true, /* Create source map files for emitted JavaScript files. */
    "outDir": "dist/types", /* Specify an output folder for all emitted files. */
    "esModuleInterop": true, /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables
     allowSyntheticDefaultImports' for type compatibility. */
    "forceConsistentCasingInFileNames": true, /* Ensure that casing is correct in imports. */
    "strict": true, /* Enable all strict type-checking options. */
    "skipLibCheck": true /* Skip type checking all .d.ts files. */
  },
  "include": [
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "dist"
  ] // Exclude `node_modules` and the output directory
}

Its becouse BundleDeclarationsWebpackPlugin is not class. You should create new object with defaults by:
new BundleDeclarationsWebpackPlugin.default;

or with your settings:
new BundleDeclarationsWebpackPlugin.default({
	//...
})

I had this problem too and solved it by using const { BundleDeclarationsWebpackPlugin } = require("bundle-declarations-webpack-plugin");

Sounds like there could be an issue with the cjs output.  Will try to look into this next week. Believe one of the last few changes was to ship as ESM so this could be what you are all seeing, sorry about that.

authors: SzczeklikJakub cnestor1 dominicbirch mark-bailey-axomic


text:
建议增加一个类似于Nhibernate的version版本号的功能

我以前是使用Nhibernate的,它们有一个int字段的Version,用来处理并发修改的问题,
可以参考一下这篇文章
https://blog.csdn.net/weixin_33754913/article/details/85889869

可以这样吗,直观

观

FluentNHibernate里面可以这样配置,

如果在update之前查询到version不一致,就直接返回了,我再进行try,
而你上面的是要自己查询是否一致,多了一步,

我发现有这个功能 ，你数据库如果可以自动维护  更改就改成 比如MSSQL的时间戳类型
  [SqlSugar.SugarTable("Student")]
        public class StudentVersion
        {
            public int Id { get; set; }
            public string Name { get; set; }
            public DateTime CreateTime { get; set; }
            [SqlSugar.SugarColumn(IsEnableUpdateVersionValidation = true,IsOnlyIgnoreInsert=true)] //数据库会自动维护
            public byte[] Timestamp { get; set; }
        }

     //is ok
   db.Updateable(data).IsEnableUpdateVersionValidation().ExecuteCommand();

如果你数据库有自动维护 Timestamp 字段或者你用解发器让他更新自动变 就可以用这个现有功能

SqlServer中的时间戳 就可以用我上面的方式


text:
Don't work with Angular 2 template syntax

Angular 2 makes use of case-sensitive attributes.
For this test I have this html:
<nav>
      <span>
        <a [routerLink]=" ['./'] ">
          Index
        </a>
      </span>
</nav>

If I run:
$ html2hade test.html --bodyless

I get:
nav
  span
    a([routerlink]=" ['./'] ")
      | Index

As you can see, now the attribute routerLink is in lowercase, routerlink, and doesn't work anymore with Angular.
I tried with -s and --donotencode, same results.

This is related to #102 and share root cause: DOM parser used (jsdom) either did not or does not preserve case.

Hi @donpark, oh I see jsdom-little isn't updated from 2 years :/
Do you have any plan to solve this? Changing the DOM parser or something like this? Oh and sorry for duplicate issues, I made a search but didn't found that one.

@desaroger well, this issue calls for a major change which will very likely disturb existing users so I think it's best to fork.
@aichholzer any plan to address this issue?

@desaroger a complete re-write is on the way. I will revisit this issue when I get there. Thank you for reporting it.

@aichholzer Thanks, happy to see a resolution for this issue as I use html2jade all the time, and just now getting into Angular2 with case-sensitive dom elements.  Thanks!

Same with ngModel

authors: aichholzer desaroger donpark rmckeel rsxdalv


text:
BREAKING CHANGE

Version of react-native-audio-recorder-player
latest version
Platforms you faced the error (IOS or Android or both?)
both
startRecorder first argument is broken/non consistent between both OS!
Now iOS forces to use relative path and prepends the app temp directory to the path, but on android an absolute path should be provided, because it does not prepend the temp directory.
Why this behaviour was made?

Well, if I remember correctly, I think it didn't quite work well to make dir without an existing path maybe because of the permission.  If you know the better approach, please give us a PR.

@hyochan the issues are:

that there is no consistency between iOS and android. iOS requires a relative path, but android  an absolute
for iOS we are forced to use the temp app dir.

My opinion is to allow both platforms to use absolute paths and to fallback to the temp app dir.

Thanks for comming back! Could you kindly provide a PR please?

@hyochan the PR is not a problem, just I need to know your idea behind making that change in the iOS platform /the android is fine/

I think there was some issue in #94. I've not had much time to review this.

Ok, when I have enough time I'll make "proper" PR :)

@netbull Thank you!

@netbull Also, please edit index.ts file only and run yarn build or npm run build to generate index.js, index.d.ts, index.flow.js and run it on your example project. This project is not typescript based.

@netbull, @hyochan My PR does exactly that,  I removed the line where the path was prepended to the temp directory in iOS, so I could pass it a different directory to save the recording. If I'm understanding it right, that's what @netbull is asking for.
The thing is, tough the PR was merged, there is no version available with that change, so maybe that's why @netbull is still experiencing it.

@escobar5 Could you guide the changes again? I've had crashing issue report in earlier issues related to the changes in android. I hope we can check the changes once more.

@hyochan what do you mean with "guide the changes again"? also, can you point me to the crashing issue?

@escobar5 I am sorry that I've confused you. I've reverted your work as seen in line of code because I couldn't resolve the path with the code you've given. Could you kindly test your PR on ios again for directory path and path individually? Such as /path/file.m4a and file.m4a for ios.

Oh ok, I understand now, sure, let me check it again

authors: escobar5 hyochan netbull


text:
Added Pivotal inside the Enterprise section

Just added Pivotal.

✔ Company name
✔ Company description
✔ Company location
✔ GitHub link
✔ How Elixir is used
✔ Sorted alphabetically

It should be ok.

Wooo woo!  Awesome addition @dottorblaster 😁

Thanks! 😬

authors: doomspork dottorblaster

repo: doomspork/elixir-companies


text:
🛑 dorulog.com is down

In 27e4134, dorulog.com (https://dorulog.com) was down:

HTTP code: 503
Response time: 237 ms

Resolved: dorulog.com is back up in 9e34973 after 9 minutes.

repo: dorulog/upptime


text:
Getting "MSB3030	Could not copy the file ..winuiex\2.4.1\lib\net6.0-windows10.0.19041\WinUIEx\runtimes\win-x64\native\WebView2Loader.dll" because it was not found.

After adding WinUIEx to an OOB WinUI3 app template project, I get:
Severity	Code	Description	Project	File	Line	Suppression State	Details
Error (active)	MSB3030	Could not copy the file "E:\packages\NuGet\cache\winuiex\2.4.1\lib\net6.0-windows10.0.19041\WinUIEx\runtimes\win-arm64\native\WebView2Loader.dll" because it was not found.	App1WithWinUIEx	C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets	5321

Reproducible projects:

Project straight from VS Template:
https://github.com/MagnusJohansson/App1WithWinUIEx

Which gives me:
This version of the Windows App SDK requires Microsoft.Windows.SDK.NET.Ref 10.0.19041.38 or later.
    Please update to .NET SDK 6.0.134, 6.0.426, 8.0.109, 8.0.305 or 8.0.402 (or later).
    Or add a temporary Microsoft.Windows.SDK.NET.Ref reference which can be added with:
        <PropertyGroup>
            <WindowsSdkPackageVersion>10.0.19041.38</WindowsSdkPackageVersion>
        </PropertyGroup>

Project after adding the WindowsSdkPackageVersion:
https://github.com/MagnusJohansson/App1WithWinUIEx/tree/feature/amend-appsdk-requirements

All good.

Adding the latest WinUIEx Nuget package:
https://github.com/MagnusJohansson/App1WithWinUIEx/tree/add-winuiex

I now get the "WebView2Loader.dll" error as stated at the top.

Of course, if I clone this WinUIEx repo and build, everything works, because then I have those runtime dependencies:

But I don't have them in my NuGet cache:

Any ideas?

I have the same issue, not only with the WinUIEx NuGet package but also with some internal NuGet packages. I think it has something to do with the decoupling of WebView2 from WinUI in the new 1.6 release, but so far I haven't found any workaround other than downgrading to 1.5.

Which version are you referencing? There’s a bug in webview package that 1.6 of windows app Sdk relies on but I added a workaround for that in 2.4.1.
If you are already on 2.4.1 could you share a repro app?

@dotMorten sure, see the third link in my original post.

Actually I know what’s going on. I know I added that workaround for this issue but don’t see it now. Something in a merge must have gone wrong. I’ll get a fix out in a few hours …

I restored the fix but it'll be a little while before I can get to test it. If you have a minute, you can try the nuget package that'll be generated once the action completes here in a few minutes: https://github.com/dotMorten/WinUIEx/actions/runs/11035641248

I downloaded the WinUIEx.2.4.2.nupkg file from the action artifacts and referenced it as a local Nuget feed.
Seems to compile now.

Thanks for confirming. Looks like this issue only affects projects with a separate packaging project, which is why I missed it. It's a non-issue with single-project packaged apps.

Fixed in v2.4.2

@MagnusJohansson and thanks for the donation too! I'm having an extra coffee today :)

Also see this in community toolkit: https://github.com/CommunityToolkit/Tooling-Windows-Submodule/pull/216

authors: MagnusJohansson Trix07 dotMorten

repo: dotMorten/WinUIEx


text:
Select with external button

Hi,
Is there a way to add an extra button to the bottom of the dropdown? Also disable/cancel somehow the selection of the dropdown item by clicking on it? I would like to use the external button to accept my selection.
Thanks

Could you please comment if you still need this feature? This is something that is implementable but a lot of work. If you haven't responded in 2 weeks, I'll close this issue

Hi,
It would nice if this extra button could call a custom function, for example to update the "options" attribute and show more items updating this array/object.

authors: emanuelkling levipadre pkempenaers


text:
cli generation error text should wrap instead of ellipsis

Is your feature request related to a problem? Please describe.
When errors are displayed ellipsis is shown for large errors. By large errors I am referring to errors that have word count that cannot fit in screen.
Describe the solution you'd like
Error text should be wrapped instead of showing three dots
Describe alternatives you've considered
No response
Any additional important details?

(apologies if these seems wasteful or too minor of inconvinience which I agree it is)

Hi @ps173 ,
Would using --verbose flag a workaround for now? This should print everything in the log
e.g.
yarn graphql-codegen --verbose

repo: dotansimha/graphql-code-generator