text:
v1.12.0-rc3: Unknown runtime specified default

Output of docker version:
Client:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 00:28:53 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 00:28:53 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 11
 Running: 0
 Paused: 0
 Stopped: 11
Images: 360
Server Version: 1.12.0-rc3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 383
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge host null
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 3.19.0-25-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 32
Total Memory: 62.89 GiB
Name: blade1
ID: RSHA:2HAV:XE3O:HTPX:3HVW:WXR2:IRBA:HU4A:KH5A:57RK:KGAC:GCSK
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 provider=generic
Insecure Registries:
 127.0.0.0/8

Running:
docker-compose up -d

with the same docker-compose file that worked on v1.12.0-rc2 I get this:
Starting blades_redis_1
ERROR: for redis  Unknown runtime specified default
...

For all my containers...
What I missed?

ping @mlaventure

Recreating all containers solved the issue 👹

I agree with @oleynikd - I had to run docker-compose down -v to remove the old containers, then when I brought the containers back up, everything started working again.

That's annoying... Just got this error myself too right after upgrading.

Just came to report the same issue. Was hoping not to have to recreate my existing containers.

Same problem here!

I bet we changed the default between rc2 and rc3, and that default was saved on the container config.

Appears the location of saved container data changed OR the upgrade blew away the old container volumes. At least on my machine.

The the location of it, but rather the value of a field.

Running docker volume inspect data_container_name outputs something similar to:
[
    {
        "Name": "data_container_name",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/idisclosecom_dbdata/_data",
        "Labels": null,
        "Scope": "local"
    }
]

However, the folder /var/lib/docker/volumes/idisclosecom_dbdata/_data does not exist on my machine. Or is there another place that it stores the volumes on mac?

same issue after upgrade to Version 1.12.0-rc3-beta18 (build: 9969)
Starting hibob_redis_1
Starting hibob_elasticsearch_1
Starting hibob_postgres_1

ERROR: for elasticsearch  Unknown runtime specified default

ERROR: for redis  Unknown runtime specified default

ERROR: for postgres  Unknown runtime specified default
ERROR: Encountered errors while bringing up the project.
ERROR: Encountered errors while bringing up the project.

same images running fine via docker run ...

@browningeric This has not changed at all. Volumes are stored in the VM, not on your Mac.

Is there a way at least to retrieve the data inside the old containers?

ugh, same here (not using docker compose)
$ docker start myredis
Error response from daemon: Unknown runtime specified default
Error: failed to start containers: myredis

$ docker ps -a | grep myredis
49e433d0c3d2        redis               "docker-entrypoint.sh"    13 days ago         Exited (0) About an hour ago                       myredis

Here's what I did to delete all of my containers and then I recreated just the one I needed right now.
Ref: https://coderwall.com/p/ewk0mq/stop-remove-all-docker-containers

Stop all containers: docker stop $(docker ps -a -q)
Delete all containers: docker rm $(docker ps -a -q)
Recreated my REDIS container: docker run --name myredis -d -p 6379:6379 redis

Attempted to stop, remove and recreate containers as @puddingfactory mentioned, but docker-compose up still brings this error:
jack is incompatible with use of CloseNotifier in same ServeHTTP call

what/who is jack anyway ?

yeah, a quick google showed me this https://github.com/docker/compose/issues/3685
Makes me think jack is really a nice greeting "Hi Jack"

💣

Same problem here!

Same issue here. Removing containers and recreating them didn't work for me.

Thank for the reports: the issue is acknowledged. We had a breaking change between 1.12.0-RC2 and 1.12.0-RC3 (introduced by #23775).
We're discussing what's the best way forward here. In the meantime, recreating your containers will solve the issue.

Same problem here!

Recreating containers left me with the same issue as @victorgama

Reset to factory defaults fix this problem

@CyrilPeponnet You can use docker inspect to find your existing containers data volume and mount that volume by name into a new container with the same image. Helped me bring my dev mongo container back up and dump the data from the new container. Example:
docker run --name mongobak -v a52847d484b6375a674debe8a3fa011ef8a8069d0139952648e5063085d66b51:/data/db -P mongo:2.6.8

Reset to factory defaults DOES NOT fix problem with debian:wheezy based container.

@dfarrell07 I found it simpler to restore the old one from the trash :) but yeah I was also looking at data volume just in case.

Same problem here... I had to run 'docker rm' to remove all stopped containers, and then my docker-compose worked.
And of course, my databases is gone too. =p. Thank god I have a dump.

I try to reset to factory defaults, remove and buil again. But I get the same issue when a try to run
http: Hijack is incompatible with use of CloseNotifier in same ServeHTTP call

Just updated to Version 1.12.0-rc3-beta18 (build: 9969).
Hitting this issue with a container
ERROR: for xxx  Unknown runtime specified default
ERROR: Encountered errors while bringing up the project.

Download URLs for Beta 17, in case anyone wants to go back:
Mac: https://download.docker.com/mac/beta/1.12.0.9779/Docker.dmg
Win: https://download.docker.com/win/beta/1.12.0.5022/InstallDocker.msi

+1 on this.  I can't get past this.

Same issue on OSX, recreating contains did not solve the issuel. However my error is missing the "Hi" in the word Hijack
db1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
mirth1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
stunnel1    | jack is incompatible with use of CloseNotifier in same ServeHTTP call

I can confirm that I am successfully able to run 1.12.0-rc3-beta18 with a fairly complex orchestrated container environment and it's working fine for me on OS X (v10.11.5)
amp-test (master)$ docker-compose -f docker-compose.amp.yml up -d
Creating amptest_amp-log-agent_1
Creating amptest_consul_1
Creating zookeeper
Creating amptest_influxdb_1
Creating amptest_amp-docker-agent_1
Creating amptest_nginx_1
Creating amp-ui
Creating amptest_elasticsearch_1
Creating amptest_amp-log_1
Creating kibana
Creating amptest_kafka-manager_1
Creating kafka
Creating amptest_amp-monitor_1
Creating amptest_amp-service-worker_1
Creating amptest_amp-log-worker_1
Creating amptest_amp-service_1
Creating telegraf

My first attempt after upgrading and removing all the containers failed. I had to explicitly release one of the container's ports after identifying the pid (sudo lsof -i :8086) associated with it.
ERROR: for influxdb  driver failed programming external connectivity on endpoint amptest_influxdb_1 (d88ca74e577ac7626c863701672a9543bdf3d5b3ed14773d6616205d4291f8cd): Error starting userland proxy: write /port/tcp:0.0.0.0:8086:tcp:172.23.0.4:8086/ctl: errno 526
ERROR: Encountered errors while bringing up the project.

After checking the port:
amp-test (master)$ sudo lsof -i :8086

I killed the process, and then successfully completed running docker-compose up.
Docker version and info outputs:
amp-test (master)$ docker version
Client:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   91e29e8
 Built:        Sat Jul  2 00:09:24 2016
 OS/Arch:      darwin/amd64
 Experimental: true

Server:
 Version:      1.12.0-rc3
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   876f3a7
 Built:        Tue Jul  5 02:20:13 2016
 OS/Arch:      linux/amd64
 Experimental: true

amp-test (master)$ docker info
Containers: 20
 Running: 20
 Paused: 0
 Stopped: 0
Images: 196
Server Version: 1.12.0-rc3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 413
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.14-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.954 GiB
Name: moby
ID: MUDB:ZVHH:B2L7:NBWE:XVSR:DT7L:WA2X:ZFN7:FFWV:RQSK:5SX3:YEAQ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 177
 Goroutines: 255
 System Time: 2016-07-05T21:37:42.075749891Z
 EventsListeners: 2
No Proxy: *.local, 169.254/16
Username: subfuzion
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
 127.0.0.0/8

So, looking in more details, it's clear that this change is due to #23775. We'll be discussing if this requires an extra patch to prevent errors for unknown runtimes. Discussion has started in #24345 for those interested.
That being said, in the particular case of the Docker 4 Mac Beta, there is unfortunately nothing we can do but advise to recreate your containers. Indeed, Docker 4 Mac is still a beta, and as part of it we made the deliberate choice to distribute the RC builds of the Docker Engine. Although we work hard to make sure all releases are fully backward-compatible, it is not the case for RC releases. The ability to iterate fast during code freeze, sometimes in a non backward-compatible manner, and collect feedback from you (thanks!) is necessary for us to ship the best possible stable version in the end.
I'm closing this as a it is pointing at an incompatibility between two successive RC, which is not guaranteed. Obviously, incompatibility between two successive stable releases would have been considered a bug.
In case you'd want to revert to the previous Docker 4 Mac Beta:

Mac: https://download.docker.com/mac/beta/1.12.0.9779/Docker.dmg
Win: https://download.docker.com/win/beta/1.12.0.5022/InstallDocker.msi

Thanks again for the reports.

@icecrime I am still not clear on the ramifications or the resolution. I reset to factory defaults and still saw this issue. Are you saying we need to rebuild the containers? That is we need to "docker build" our containers again? Or are you saying that the reset to factory defaults should resolve the issue? If it's the latter, that is not true, the issue persists.
(I downgraded because I can't be fixing this type of thing today.)

@andyburke Removing and recreating the containers should be enough, so a "reset to factory defaults" should be more than enough. We might be missing something else if that's not the case (ping @justincormack @samoht).

I reset to factory defaults, then tried docker-compose up again, watched containers download, then saw the issue persist. Let me see if I can find a little bit to cut-and-paste:
Pulling rethinkdb (float/rethinkdb:latest)...
latest: Pulling from float/rethinkdb
c02c7df4a131: Pull complete
a3ed95caeb02: Pull complete
4acc5a0bbe02: Pull complete
e2c4c079e657: Pull complete
93563bc74311: Pull complete
76e91ce8b6dc: Pull complete
Digest: sha256:babb90d8d4e124ec873218bb5a7f8e8980d6f791e37d6615eff76e7aa60b8ace
Status: Downloaded newer image for float/rethinkdb:latest
Pulling rethinkdbproxy (float/rethinkdb_proxy:latest)...
latest: Pulling from float/rethinkdb_proxy
c02c7df4a131: Already exists
a3ed95caeb02: Already exists
4acc5a0bbe02: Already exists
e2c4c079e657: Already exists
93563bc74311: Already exists
76e91ce8b6dc: Already exists
Digest: sha256:742ee109cdb654fb30dcffa7e0b4537679a768f17d74e37f8dd8a93e81d99db9
Status: Downloaded newer image for float/rethinkdb_proxy:latest

... (more containers downloading)
rethinkdb_1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
rethinkdbproxy_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call

Again, this was after a reset to factory defaults (hence, the containers downloading).

@andyburke This issue is about the "unknown runtime specified default", the one you're referring to is docker/compose#3685.

Also experienced this issue. Docker should have release circles like Microsoft has for Windows and make their developers use the build first, so that, problems like this one get rectified before the build is released to the public.

Also getting the jack errors, as opposed to Hijack. Have tried deleting and rebuilding everything from square one, nothing gets me past those errors. Colleagues on the same codebase on different machines have different results.

I have the same result on two machines. It persists after reset and rebuild of images and containers.

This doesn't appear to be a problem with pre-built containers:
micah@micah ~/S/agent-activity> docker rm -f (docker ps -aq)
...
micah@micah ~/S/agent-activity> docker rmi (docker images -q)
...
micah@micah ~/S/agent-activity> docker-compose up
Starting agentactivity_zookeeper_1
Starting agentactivity_memcached_1
Starting agentactivity_kafka_1
Attaching to agentactivity_memcached_1, agentactivity_zookeeper_1, agentactivity_kafka_1
memcached_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
zookeeper_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
kafka_1      | jack is incompatible with use of CloseNotifier in same ServeHTTP call

All of these services are based on images found on hub.docker.com.

Thanks for restoring the download link to beta17

Same here.
Did someone find any valid workaround? It looks like recreating the containers didn't work for all.
How about downgrading BTW? Is that possible?

The Mac link in https://github.com/docker/docker/issues/24343#issuecomment-230623542 worked for me. Just recreating the containers via first removing via docker rm didn't work.
Had to quit docker before dragging the app from the dmg into applications and restarting.
Then had to run docker-compose up --force-recreate to get around the 'runc' related error.

@krihelis I have downgraded. You find the old version your trash.

Recreation "doesn't work for me" either, however the containers do actually get started! This is my current work-around:
$ docker-compose up
Starting projectx_postgres_1
Starting projectx_recommendation_1
Starting projectx_users_1
Starting projectx_pre_1
Starting projectx_eventlog_1
Starting projectx_web_1
Starting projectx_photo_1
Starting projectx_imaginary_1
Attaching to projectx_web_1, projectx_recommendation_1, projectx_eventlog_1, projectx_postgres_1, projectx_pre_1, projectx_photo_1, projectx_users_1, projectx_imaginary_1
web_1             | jack is incompatible with use of CloseNotifier in same ServeHTTP call
recommendation_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
eventlog_1        | jack is incompatible with use of CloseNotifier in same ServeHTTP call
postgres_1        | jack is incompatible with use of CloseNotifier in same ServeHTTP call
pre_1             | jack is incompatible with use of CloseNotifier in same ServeHTTP call
photo_1           | jack is incompatible with use of CloseNotifier in same ServeHTTP call
users_1           | jack is incompatible with use of CloseNotifier in same ServeHTTP call
imaginary_1       | jack is incompatible with use of CloseNotifier in same ServeHTTP call
^CGracefully stopping... (press Ctrl+C again to force)
Stopping projectx_users_1 ... done
Stopping projectx_web_1 ... done
Stopping projectx_recommendation_1 ... done
Stopping projectx_eventlog_1 ... done
Stopping projectx_photo_1 ... done
Stopping projectx_imaginary_1 ... done
Stopping projectx_postgres_1 ... done
Stopping projectx_pre_1 ... done

The work-around
$ docker-compose up -d
Starting projectx_postgres_1
Starting projectx_recommendation_1
Starting projectx_users_1
Starting projectx_pre_1
Starting projectx_eventlog_1
Starting projectx_web_1
Starting projectx_photo_1
Starting projectx_imaginary_1

$ docker-compose logs

This put me roughly in the same situation. The containers are actually running, I can connect to it and everything, but the logs won't be attached like when you normally just run docker-compse up.

As someone whose osx username is jack this was an extremely confusing issue

Does build 9996 fix this "Unknown runtime specified default" error without the need to recreate all containers?

The hijack, or rather "jack" issue is completely separate. It is specific to docker4mac/win. You either must downgrade or wait for a patch.

Downgrading seems to have been the only solution for our team also.

A new fix is out (Version 1.12.0-rc3-beta18 (build: 9996)) Thanks for working this fast guys!

I just installed Version 1.12.0-rc3-beta18 (build: 9996) and this seems to have caused the problem for me here Error response from daemon: Unknown runtime specified default. Had to delete/re-create and all is well now.

Yes, the new build is specifically for fixing the "Hijack is incompatible with use of Close Notifier" issue, which is specific to docker4mac/windows.
The issue that the OP posted here is not fixed and is just a breaking change between Docker 1.12-RC2 and 1.12-RC3

FYI, I've installed the latest Version 1.12.0-rc3-beta18 (build: 9996) ec40b14c72adc0bff3b01fa8886dae7f2eee1541 on OS X 10.11.5 (15F34) and I still get Error response from daemon: Unknown runtime specified default. Had to recreate all containers as well.

Docker version 1.12.0-rc3, build 91e29e8, experimental
Reseted to factory defaults, rebuild all images
Still has it:
Creating api_data_1
Creating api_db_1
Creating api_api_1
Attaching to api_data_1, api_db_1, api_api_1
db_1    | jack is incompatible with use of CloseNotifier in same ServeHTTP call
api_1   | jack is incompatible with use of CloseNotifier in same ServeHTTP call
data_1  | jack is incompatible with use of CloseNotifier in same ServeHTTP call
api_data_1 exited with code 0

How does one get the new version?  When I tell Docker for Mac to check for updates it says it has the latest at 1.12.0-rc3-beta18 but when I look at Docker > About it says 1.12.0-rc3-beta18 (build: 9969).

@Zoltu It's been pulled and beta17 is what's currently "latest".

Version 1.12.0-rc3-beta18 (build: 9996) having the same error
ERROR: for db  Unknown runtime specified default
ERROR: Encountered errors while bringing up the project.

@tylfin See the comments above. To "fix" the problem, you must re-create containers that are having the issue.
For compose, this means using --force-recreate

I have just upgraded to the latest version 1.12.0-rc3-beta18 (build: 9996), but I'm still not sure about the containers recreation workaround.
How do I recreate the containers? Can someone please add the exact commands that I need to run?

@antipin, what about the containers? Will they be removed?

@krihelis unfortunately yes, but what's the big deal to rebuild them?

I've create a hack to work-around this problem for people who really can't re-create their containers.
First, you must be on 1.12-rc3 (so beta 18 of docker4mac). If you have downgraded this will not help you.
If you are not on docker 1.12-rc3 this will make it so your containers will not start!!!
Simply run docker run --rm -v /var/lib/docker:/docker cpuguy83/docker112rc3-runtimefix:rc3 and then restart docker. You must restart docker afterwards otherwise the changes will not take affect*.
Source is here: https://github.com/cpuguy83/docker112rc3-runtimefix
From the repo:
First and foremost, this tool is a HACK. It is offered without guarantee or support! It modifies files generally considered private to the docker daemon!

beta 18 also completely broke my env... downloading beta 17 and doing a full reset fixed my issue

Just updated to beta 18, docker-compose down -v solved it for me.

I was able to run docker-compose -f file.ext up --force-recreate after rebooting my Mac, and it "just worked."
OS X: 10.11.5
Docker: Version 1.12.0-rc3-beta18 (build: 9996)
ec40b14c72adc0bff3b01fa8886dae7f2eee1541

I don't get why companies do this? Why would you gamble with my data when I trusted you???  Anyways I go the previous version of docker from my Trash folder "Docker (9779)"
Steps:

Move Docker (9779) from Trash to Desktop
Right click on the Docker (9779) icon and click on "show package contents"
Go to the Contents->MacOS folder
Run Docker

It is unfortunate that the latest version didn't work, yes, but we are on a beta program here; the risk should be well understood. Also, if you're potentially going to lose data, I suspect you're not using containers in the most ideal way. You should mount you vulnerable data as a volume on the host so you aren't at risk of losing anything.

dlgoodchild, I do agree with both your points, and its just frustration and panic at losing my dev databases and having to start again.  Sorry.  I edited my previous post to only include the useful information.

I replaced docker with an old version on my mac and it worked again. Remember to keep your old downloads.

@jfscoertzen @ajaali please have a look at https://github.com/docker/docker/issues/24343#issuecomment-230887236. Reverting to an older version of docker is not a solution here, because RC2 used a runtime name that will not be used in the GA release. Re-creating containers that were started using RC2, or updating their config using the steps explained in https://github.com/docker/docker/issues/24343#issuecomment-230887236 is the right solution.

same here.

same problem

@qxhy123 @immatt2015 Please read the thread, specifically: https://github.com/docker/docker/issues/24343#issuecomment-230599107
To remediate the issue you'll either need to recreate your containers or run https://github.com/docker/docker/issues/24343#issuecomment-230887236
I'm locking this issue as this is all that can be done.

authors: CyrilPeponnet DannyMoerkerke Dynom NotBobTheBuilder Zoltu ajaali alexgorbatchev andyburke andymcintosh antipin axelx5 browningeric cpuguy83 derosm2 djfarrelly dlgoodchild ericworkandco fernandomora icecrime immatt2015 ivancevich javawolfpack jfscoertzen johnlockwood-wf justinschier krihelis lielran loop0 lypborges matschaffer matthewjcooper mshick oleynikd pdougall1 pedrofernandezm puddingfactory qxhy123 raeesiqbal rodolfobarretoweb sonnyvan subfuzion sungsong88 swieczorek thaJeztah trentmswanson tylfin victorgama vladimirkazan zedd45


text:
tests from DockerSwarmSuite.* intermitently fail with "update out of sequence"

Description
Hi! I have a strange problem when running docker swarm tests in my Fedora 24. It reproduces in different swarm tests like DockerSwarmSuite.TestApiSwarmCAHash or DockerSwarmSuite.TestServiceUpdatePort.
Steps to reproduce the issue:
0. install docker-engine following https://docs.docker.com/engine/installation/linux/fedora/

git clone https://github.com/docker/docker.git --branch v1.12.3
cd docker
TESTFLAGS="-check.f=DockerSwarmSuite.*" make test-integration-cli

Describe the results you received:
FAIL: docker_cli_service_update_test.go:13: DockerSwarmSuite.TestServiceUpdatePort

[d40511895] waiting for daemon to start
[d40511895] daemon started
docker_cli_service_update_test.go:14:
    d := s.AddDaemon(c, true, true)
check_test.go:229:
    c.Assert(d.Init(swarm.InitRequest{}), check.IsNil)
... value *errors.errorString = &errors.errorString{s:"initializing swarm: invalid statuscode 500, \"{\\\"message\\\":\\\"error updating cluster settings: rpc error: code = 2 desc = update out of sequence\\\"}\\n\""} ("initializing swarm: invalid statuscode 500, \"{\\\"message\\\":\\\"error updating cluster settings: rpc error: code = 2 desc = update out of sequence\\\"}\\n\"")

Message "update out of sequence" is from v1.12.3:vendor/src/github.com/docker/swarmkit/manager/state/store/memory.go:490 func update().
And it seem that some object in swarm store is updating but version is not consistent. I can see always same versions: oldN.(Object).Meta().Version == {9} and o.Meta().Version == {2}.
Describe the results you expected:
No fail.
Additional information you deem important (e.g. issue happens only occasionally):
It is quiet accidental: last time I managed to get the problem once after 4 successful test runs.
Output of docker version:
Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 53
Server Version: 1.12.3
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay bridge null host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: vmlinuz-4.7.9-200.fc24.x86_64
Operating System: Fedora 24 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.54 GiB
Name: dhcp-10-30-29-163.sw.ru
ID: FOBI:53SZ:3XT7:5E4Q:JJND:QPOY:PQAT:GPCK:IVQ6:L2AO:IZPY:QWKU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Fedora 24, hardware node
bundles/1.12.3/test-integration-cli/d40511895/docker.log : https://gist.github.com/Snorch/3fc28b0f7edd07efca07ae8397911d11

This is related to spec versioning and retries
/cc @aaronlehmann @mrjana

Please do not forget about it.

Any news?

I can't reproduce that on current master 😅
I'll close for now, but feel free to discuss that more if it happens again, I'll reopen.

still happens:
Now lets wait another month, another release and the same answer, doesnt happen on my machine :)
are you using docker? you should :)

source: gharchive/issue

authors: Snorch aluzzardi josersleal vdemeester

repo: docker/docker

license_type: permissive

license_source: github-api


text:
Reference DigitalOcean volume driver from docs

I've implemented a Docker volume driver to integrate DigitalOcean's block storage solution into Docker:
https://github.com/omallo/docker-volume-plugin-dostorage
If you deem it appropriate, the driver might be referenced from the Docker docs:
https://docs.docker.com/engine/extend/legacy_plugins/

Sure; feel free to open a pull-request to add your driver; you can find the file that's used to generate that page in the documentation here; https://github.com/docker/docker/blob/master/docs/extend/legacy_plugins.md

Created a pull-request.

authors: omallo thaJeztah


text:
Dealing with a strictly controlled firewall

Hi,
We'd like to use Docker in a setup where the firewall is strictly controlled by ferm via puppet. The trouble we're running into is that ferm needs all rules in its own config, any changes performed by external applications (like docker) will get removed by ferm when it reloads. Which is a bit of a problem when you've bound ports to docker containers.
Aside from disabling ferm entirely (which is sadly not an option in this environment), I see only three ways around that, all of them require changes in docker:

Fixed IP addresses for docker containers, so we know in advance which port on which IP address needs to be masqueraded and we can add it to the ferm config statically.

Add an option to docker that makes it reload it's firewall config and set it up anew. This would be slightly problematic, since it would break already running connections, but at least it would allow me to get the config.

Make docker 'request' the firewall changes from some script that automagically creates the required ferm config and adds it in the ferm.d directory. Docker would invoke a script and sent its information in some format (json?) to the stdin of the script.

The first one is probably preferred, since it allows us to take the config change into account in config management (and thus, in version control). But maybe I'm overlooking already implemented solutions for this? On IRC it was recommended to simply open all the ports, but that's not an option.
I'd appreciate some input to this problem.

All the iptables rules are in a Chain called docker, you could run a iptables-save and iptables-restore to bring them back up.
Also you can used assign a fixed-cidr.
See the networking articles here: http://docs.master.dockerproject.com/articles/networking/

@timstoop you could use pre/post ferm hooks for this, and call helper scripts:
# !/bin/bash
# pre_script
iptables -S DOCKER -t nat > /etc/saved_rules/nat_DOCKER
iptables -S DOCKER > /etc/saved_rules/filter_DOCKER
iptables -S DOCKER-ISOLATION > /etc/saved_rules/filter_DOCKER-ISOLATION

# !/bin/bash
# post_script
for table in nat filter; do
  for chain in /etc/saved_rules/${table}_*; do
    iptables-restore -n ${table}_${chain}
  done
done

Not tested, might work :)

authors: jfrazelle leucos timstoop


text:
New libcontainer api

This is not fully finished integration(there are a lot ugly places, which can be much nicer), but this code contains new libcontainer API, so we can test it and find some bugs.
ping @crosbymichael

Whoa nice, so @icecrime does this mean we can make the hairpin nat PR after?

@jfrazelle Yup, indeed. And probably we can remove userland-proxy :)

LGTM

ping @tiborvass @jfrazelle @icecrime
Review pls :) There is a lot of further work on this before release.

I made a few minor comments; but I've reviewed the Docker integration code (not the libcontainer vendor update) and LGTM

LGTM

shit this broke lxc https://jenkins.dockerproject.com/job/Docker Master (lxc)/3/console

@jfrazelle haha, that's expected :)

source: gharchive/pull-request

authors: LK4D4 crosbymichael estesp jfrazelle


text:
allow the user to untag the history layer of the image in use

The problem:
Given two images with the following history:
tmp1:
3e39722dd807
324914d76d1c
bf6ad78f79e6

tmp2:
324914d76d1c
bf6ad78f79e6

and there are some running containers based on the image tmp1, when I run docker rmi tmp2, it raises an error saying that tmp2 is in use. It's a bit confusing. Moreover, I think in this case tmp2 should be untagged instead of raising the error.
How to reproduce:

Build an image with the following Dockerfile via docker build -t tmp1 .:
FROM busybox
RUN echo asdf >/tmp/1.txt
RUN echo ghjk >/tmp/2.txt

Create a container from the image. docker run -itd --name=tmp1 tmp1 sh

Create another image whose history is overlapped with the previous image.
This can be done in two ways:

a) Build another image with the following Dockerfile via docker build -t tmp2 .:
```
FROM busybox
RUN echo asdf >/tmp/1.txt
# RUN echo ghjk >/tmp/2.txt
```

b)  docker tag $(docker history -q tmp1|head -n 2|tail -n 1) tmp2
4. docker rmi tmp2 will return an error
```
Error response from daemon: Conflict, cannot delete f0ef9e6f70f9 because the running container 4f85b71ce1e7 is using it, stop it and use -f to force
FATA[0000] Error: failed to remove one or more images
```

Expected behaviors of docker rmi

[x] the image should not be deleted (irrespective of the -f flag) if there are running containers using it.
[x] the image should be deleted when the -f flag is provided if there are only stopped containers using it
[x] if deleting by repo tag, and the image has multiple tags, the provided tag should be deleted (no matter there are containers using it or not).
[ ] if deleting by repo tag and the image is the parent of another one with containers, the tag can be removed (this PR)
[x] if deleting by ID and the imageID has multiple repo tags,

[x] if there are running containers using the image, the image should not be deleted (irrespective of the -f flag)  (see #14116)
[x] otherwise the image can be deleted with the -f flag

PS: [x] is the current behavior, [ ] is not implemented

@mountkin Thanks for the patch! I gotta say I agree with you that this message is confusing, but I'll leave it to the experts to see if design sounds good (cc @dmcgowan @stevvooe).

I agree with @icecrime in that the output under this condition is confusing. However, I am confused about the methods used in the proposed fix. Please take some of the style changes to improve communication about what the intended design is.

Hi, @stevvooe I just refactored the patch. I hope the following image can help to describe my proposal.

@mountkin I am not sure if I was clear above. Please add to you issue a description of what these changes are trying to accomplish and why it works to solve the problem. This way we can evaluate the code against the intent.
I've also added some examples of proper if statement style. Check the guards early and bail, rather than splaying the condition across the function. The code will be much more readable.

@stevvooe I modified some of the code styles and updated the description of this PR.

I see that this is still in design review.
@stevvooe is it ready for code-review?

I think the intent is clear and sound so I'll move this to code review. Ping @aaronlehmann @RichardScothern: could you please give this a look?

Sorry, I'm a little late to the design review process, but this was my understanding of how docker rmi <image_reference> should work:

A hard dependent is defined as:

any descendent image.
any running container using this image.

A soft dependent is defined as:

any stopped container using this image.
any tag references to this image.

If a tag reference is specified, it is always okay to remove that tag regardless of whether or not the image it references has any hard or soft dependents.
If the referenced image ID has any hard dependents then it cannot be deleted.
If the referenced image ID has any soft dependents then it can only de deleted by force.

@mountkin Thank for enumerating the expected conditions.
I think we would be a lot more comfortable merging this PR if the code some how communicated those conditions. These relationships are fairly complex and should be represented in the data structures themselves. Perhaps, adding a few methods to help communicate that we are operating on hard vs soft dependencies can help to clarify what is happening.
The main issue here is not whether this is correct. It definitely looks to be. We just want to be able to maintain and understand this in 6 months to avoid introducing regressions.
This can be accomplished by separating the resolution of the dependents from the application of the logic. Have one function that returns dependents and whether or not they are hard or soft. The calling function can then take that output and apply conditions under which the deletion happens.

If a tag reference is specified, it is always okay to remove that tag regardless of whether or not the image it references has any hard or soft dependents.

Wait, apparently this isn't true? You aren't allowed to untag an image if a container is running from that tag? When did this happen? Why should you not always be able to untag an image?

I question the expected condition from this PR description:

[x] if deleting by repo tag, and the image has multiple tags, the provided tag should be deleted (no matter there are containers using it or not).

Why only untag if  "the image has multiple tags"?

@mountkin @stevvooe I spent some time this evening refactoring daemon/image_delete.go. Please take a look: https://github.com/docker/docker/pull/15606

Thanks for reviewing.
@jlhawn I meant that if the image has multiple tags, we can delete the specified tag without checking whether there are containers using the image.
If the image has only one tag, and the --no-prune is not provided, we have to check whether there are containers using the image before deleting the image.
I think we can close this PR and continue the discussion in  #15606

@mountkin you are okay with closing this, and continuing in https://github.com/docker/docker/pull/15606 ?
Although I really appreciate @jlhawn's work, I want to check with you first, because creating "competing" PR's is usually not the way things are done, and you already invested quite some time in this (researching, describing and coding) - I don't want this to result in "bad feelings"

@thaJeztah I also think that it's time to refactor the image_delete.go. @jlhawn did a great job. So I'm okay to close this.
No "bad feelings". All I want is to help to make the project better :smile:

Good to hear, @mountkin and thanks for all the work you did so far! I welcome you joining the discussion in https://github.com/docker/docker/pull/15606 :+1:

authors: LK4D4 icecrime jlhawn mountkin stevvooe thaJeztah


text:
Don't check RESOURCE_COUNTERS in new kernel

Closes: #13543
It's remove in 3.19 and have no replacement.
Signed-off-by: Qiang Huang h.huangqiang@huawei.com

LGTM

ping @tianon PTAL

@tianon Thanks, updated, please take a look.

LGTM

Thanks! :smile: :+1:

authors: hqhq jfrazelle thaJeztah tianon


text:
Add test coverage to pkg/jsonlog

After opts package (https://github.com/docker/docker/pull/13694), it was time for pkg/jsonlog :smile_cat:.

I've removed a few lines in jsonlog_marshalling.go that will never be called (or I missed something :sweat:), and updated the header with the diff.
Did the same for jsonlogbytes.go (almost).
It felt a little weird/overkill/too much to add the same test for jsonlogbytes.go and jsonlog_marshalling.go but well, I was on my way so.. :sweat_smile:.

# before
+ go test -test.timeout=45m github.com/docker/docker/pkg/jsonlog
PASS
coverage: 10.6% of statements
# after
+ go test -test.timeout=30m github.com/docker/docker/pkg/jsonlog
PASS
coverage: 94.9% of statements

Signed-off-by: Vincent Demeester vincent@sbr.pm

@vdemeester you're awesome :)

@runcom :blush:
Well, it's either windows or experimental build, but there's always one that fail :sweat_smile:.

Gave janky a kick. Fingers crossed!

LGTM! Ping @runcom

@vdemeester thanks for the fixes, LGTM

@icecrime @runcom seeing two LGTMs, this is ready to merge? (I suspect this won't need changes to documentation?)

@thaJeztah thanks for reminder :)

Thanks @vdemeester!

:blush:

authors: icecrime runcom thaJeztah vdemeester


text:
replace t.Fatal to t.Error

Fatal will halt the test function entirely, and subsequent test cases won't run, so that we could just find one potential bug.
When running unit test, we want to find as many bug as possible. It's a better choice to use Error and continue,  so that subsequent test cases could run and find more.
Usually, Fatal is used in cases where some internal error occurs so that test can not go on.
Signed-off-by: mqliang mqliang.zju@gmail.com

@mqliang Would you mind to squash commit pls?

Agree with the concept, but not sure if we need to be going and changing these just to change them.
Is there a style-guide for writing tests?

@MHBauer No, there is no. We just use Fatal everywhere. But Error allows you to collect more info to fix issue on failure.

once it's squashed, LGTM :cat:

This does NOT LGTM. Failing fast is always better and, as you mention, avoids side effects. Moreover, these tests will be modified again to use Fatal as soon as someone opens a PR to port them to go-check and c.Assert.
I'd rather migrate this tests to go-check and leave the behavior consistent to the rest of the suites.

Usually, when one of test cases failed, we should use Error and continue, Fatal is used in some inevitable error case so that subsequent test cases CAN NOT run, such as failed when fake a client.
Just like complier:  find out as much error as possible, but when we fix those errors, start fix from the first one to avoid cascading errors.
I am glad to refactor the leaving test files(may separated into several parts) if this looks good to you.

I agree with @calavera - failing as soon as an error occurs is better to avoid side effects so I'd stick with Fatal

looks like we don't reach consensus on this; I see two maintainers that want this change, two that don't want this. Should this be closed, or are more maintainers needed to make a decision?

I favor using Fatal. Error is okay in cases where it's clear there are no side effects from the failure, but we shouldn't go out of our way to use it.

I'll go ahead and close this. Thanks so much @mqliang, I hope you understand :heart:

It doesn't matter.
In fact, I don't mean replace all Fatal to Error. For example, if we want write a unit test for function GetOdd() which will return us some odd numbers, I propose to write our unit test like this:
TestGetOdd(t *testing.T) {
	odds, err := GetOdd()
	if err != nil {
		// use Fatal, since the following test cases can not go on
		t.Fatalf("unexpetced err")
	}
	for odd := range odds {
		if odd % 2 != 1 {
			// use Errorf, to find more error cases
			t.Errorf("%d is not odd", odd)
		}
		.....
	}
}

authors: LK4D4 MHBauer aaronlehmann calavera mqliang runcom thaJeztah vdemeester


text:
User network does not work with IPv6

Output of docker version:
Client:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:11:07 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:11:07 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 12
 Running: 6
 Paused: 0
 Stopped: 6
Images: 110
Server Version: 1.11.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 290
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.84 GiB
Name: *snip*
ID: *snip*
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory limit support
WARNING: No oom kill disable support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

Additional environment details (AWS, VirtualBox, physical, etc.):
Bare Metal Debian Jessie
Steps to reproduce the issue:
[root@~]docker network create -d bridge --ipv6 --subnet=2001:db8:1234:5678:1338::/80 test
366dbbe31c3847f14d9d662c484371cdb9e72bd722c191e04872e9b83aecf9bc
[root@~]docker run -it --rm --net=test --ip=2001:db8:1234:5678:1338::dead --ip=2001:db8:1234:5678:1338::beef debian
docker: Error response from daemon: User specified IP address is supported only when connecting to networks with user configured subnets.
[root@~ [125]]docker network rm test
[root@~]docker network create -d bridge --ipv6 --subnet=2001:db8:1234:5678:1338::/80 --subnet=172.25.0.0/16 test
8e5ef9b578199d965ab78701f1dc1a2feff7840dcacc349a6c960a0a7722999f
[root@~]docker run -it --rm --net=test --ip=2001:db8:1234:5678:1338::dead --ip=2001:db8:1234:5678:1338::beef debian
docker: Error response from daemon: Invalid address 2001:db8:1234:5678:1338::beef: It does not belong to any of this network's subnets.
[root@~ [125]]docker run -it --rm --net=test --ip=172.25.16.16 debian
*runs fine and even has IPv6 connectivity on a random IPv address*

Describe the results you received:
Using a custom docker bridge network does not properly detect IPv6 subnets.
Describe the results you expected:
Using a custom docker bridge network does properly detect IPv6 subnets.
Additional information you deem important (e.g. issue happens only occasionally):

You need to do docker run --ip6=... to set ipv6 addresses.

Thanks that worked.
You might want to add a hint to: https://docs.docker.com/engine/userguide/networking/work-with-networks/#linking-containers-in-user-defined-networks I used that page to learn about creating my own network and it only mentions the --ip flag.
You may close this issue if you don't feel like a change in the manual is warranted.

Do you want to write a pull request to update the docs for this?

@justincormack I just converted this issue into a proper pull request, you may review.

LGTM

LGTM thanks for contributing!

authors: TimWolla justincormack thaJeztah


text:
Add zsh completion for 'docker run --storage-opt size='

Ref: #23780
@albers thx for the ping
@vincentbernat
Signed-off-by: Steve Durrheimer s.durrheimer@gmail.com

LGTM

LGTM 🐮

authors: sdurrheimer vdemeester vincentbernat


text:
Delete conflict error code

Addresses #30159
- What I did
delete conflict status is now 409 instead of 400

- How I did it
in the PR
- How to verify it
Let me know how I can unit test this. Otherwise I can attempt manual testing.
I did run make test successfully already.
- Description for the changelog
delete conflict status is now 409 instead of 400

ping @stevvooe @justincormack PTAL

409 is a better error code, but this needs to be updated in the documentation.

Looks like there's already a 409 status code documented, but i need to check the latest API docs / swagger

409 was present in the 1.24 docs.
If I look at the new 1.2.5 docs it is not present

ah, looks like that was addressed on master, but not published yet; https://github.com/docker/docker/commit/c0cf14a73c38bf573803be8bc50af95a411732ba

That error message text isn't correct for this case. For this case it should say "the container is already being removed".
The current text doesn't actually make any sense to me as a 409 because there are not any conflicting requests. 400 would make a lot more sense to me: essentially the force flag is missing given that the container state is running
Please advise how you want to resolve this.

ping @thaJeztah what is the status ? :angel:

The current text doesn't actually make any sense to me as a 409 because there are not any conflicting requests.

When using HTTP status codes for an API, there's unfortunately a lot of room for "interpretation". A different description of 409 is "The request could not be completed due to a conflict with the current state of the target resource.", which does look appropriate for "You cannot remove a running container" (which could be due to a different request having introduced the conflict).
Feel free to open a separate PR for changing that to open a discussion if you feel strongly about that though.

Please advise how you want to resolve this.

Ideally, we'd add a second example to the 409 response code, however, it looks like Swagger / Open-API 2.0 does not support that; https://github.com/OAI/OpenAPI-Specification/issues/270, but is proposed to be added in Open-API 3.0 (https://github.com/OAI/OpenAPI-Specification/pull/741)
Perhaps we should be creative and put both possible errors in the same "message"?

Hmm, in this case it would be peculiar for a different request to have introduced the conflict. But given there is some plausibility I wouldn't change it if that means a change in the API.
However you would like to resolve the swagger is fine with me.

I updated the PR for the merge conflict.
OpenAPI v3 is out but It doesn't look like it offers us any help.
Rather than returning a 4xx would it make sense to return a 200 or 202? It isn't necessarily an error to request the removal of something that is in the process of being removed.

Actually, after reviewing my original bug report, a 200 or 202 could easily expose the original bug under a 200 error code instead of 400. Give this state, my preference would be to use a 409 or a 423.
@thaJeztah I am hoping we can get this merged soon.

I don't think 409 or 423 are appropriate. The spec says https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7/

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

So an extra DELETE while in progress should behave just like the original delete, and return a success error code.

@justincormack Google's API Style guide provides some decent guidance:

Calls to the Delete method should be idempotent in effect, but do not need to yield the same response. Any number of Delete requests should result in a resource being (eventually) deleted, but only the first request should result in a success code. Subsequent requests should result in a google.rpc.Code.NOT_FOUND.

Note that there is some GRPCisms in there, but this applies to HTTP behavior, as well.
In general, we should ask what we are trying to communicate to the client. Does the client care that there is an ongoing delete in progress? What actions would they take if we returned that instead of a 404 or 204?

Closing since the error returned is a conflict type now.

Thanks for looking into this and for your patience!

authors: cpuguy83 gregwebs justincormack stevvooe thaJeztah vdemeester


text:
improve semantics of utility function in cli/command/service

Signed-off-by: Gaetan de Villele gdevillele@gmail.com
- What I did
I changed the signature of the addServiceFlags function in cli/command/service/opts.go
I replaced the *cobra.Command param by a *pflag.FlagSet param, as the function doesn't need a cobra.Command struct. This makes it more "reusable", IMO.
🐨

ping @dnephin ptal

Thank you 🙂
What about the ppc build that failed? (Timeout)

authors: gdevillele thaJeztah


text:
Consider supporting default AWS profiles

It would cause less friction if default AWS profiles could be used in addition to named profiles.

There's no reason we don't let user run with default AWS profile.
setup command was just a draft, ECS context creation UX need to be fully revisited

cc @CarmenAPuccio

authors: mreferre ndeloof

repo: docker/ecs-plugin


text:
[19.03 backport] Ensure parent dir exists for mount cleanup file

backport of https://github.com/moby/moby/pull/39496
While investigating a test failure, I found this in the logs:
time="2019-07-04T15:06:32.622506760Z" level=warning msg="Error while setting daemon root propagation, this is not generally critical but may cause some functionality to not work or fallback to less desirable behavior" dir=/go/src/github.com/docker/docker/bundles/test-integration/d1285b8250308/root error="error writing file to signal mount cleanup on shutdown: open /tmp/dxr/d1285b8250308/unmount-on-shutdown: no such file or directory"

This path is generated from the daemon's exec-root, which appears to not
exist yet. This change just makes sure it exists before we try to write
a file.

all green; let's get this one in

repo: docker/engine


text:
Docker pull fails and some other commands too

docker pull jenkins
Error while pulling image: Get https://index.docker.io/v1/repositories/library/jenkins/images: dial tcp: lookup index.docker.io: no DNS servers
docker info
An error occurred trying to connect: Get http://localhost:2375/v1.21/info: dial
tcp 127.0.0.1:2375: ConnectEx tcp: No connection could be made because the targe
t machine actively refused it.
docker version
**
Client:
Version:      1.9.1
API version:  1.21
Go version:   go1.4.3
Git commit:   a34a1d5
Built:        Fri Nov 20 17:56:04 UTC 2015
OS/Arch:      windows/amd64
An error occurred trying to connect: Get http://localhost:2375/v1.21/version: di
al tcp 127.0.0.1:2375: ConnectEx tcp: No connection could be made because the ta
rget machine actively refused it.**
Windows 7 Enterprise, Service Pack 1, 64-bit
VirtualBox: Version 5.0.10 r104061
Please let me know if I can provide you with more info

Solved by following this advice:
https://github.com/docker/kitematic/issues/718#issuecomment-115489049

repo: docker/kitematic

license_source: bigquery


text:
whats happen with my docker?

Expected behavior
do login
Actual behavior
(HTTP code 401) unexpected - {"message":"Get https://registry-1.docker.io/v2/library/mysql/manifests/latest: unauthorized: incorrect username or password"}
Information about the Issue
Steps to reproduce the behavior

just attempt to sign in

Please try to login using your Docker ID (hub username) instead of your email. This should fix the issue.

thanks !
fixed :)
regards
2017-09-13 17:04 GMT-03:00 French Ben notifications@github.com:

Please try to login using your Docker ID (hub username) instead of your
email. This should fix the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/kitematic/issues/3062#issuecomment-329281255,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABFZZTY0eFw8Yg4zP-oKR7hhPvO4Y9Qkks5siDVUgaJpZM4PWmPu
.

--
att,
Victor C. Bredarioli .'.
Codelab Mobile - via iPhone

authors: FrenchBen victorcbr


text:
--net=none lacks useful DNS options

None of the existing DNS options make any sense for containers where --net=none.
Can we get something like --dns=ignore or something, where it mounts an empty resolv.conf file and doesn't get creative with trying to do some magical right thing, and never refreshes based on the host resolv.conf.
This probably isn't the right solution, but there needs to be some kind of solution.

@nbastin as discussed in the IRC, I dont think the embedded DNS server in 1.10 has nothing to do with the behavior that you see in --net=none. Also as discussed, can you please confirm which version of docker the behavior has changed (as per your requirement) ?

Yeah, I'm not actually sure where this changed.  It's definitely not 1.10 and embedded DNS isn't actually the source of this problem (although I would still like it to not be around if I'm not using it), so that part of the original report isn't valid.
My scripts for installing old dockers don't appear to work anymore (they did some auto-sed magic on the download script that apparently doesn't work and I haven't debugged it), so I'm not sure when this actually changed.  However, I don't think that's particularly relevant - I think really I'm asking for a feature that never explicitly existed (not one that worked before but is now broken).
So, what I really mean here is - can I get a world where --net=none is more pervasive than it is now?  I think this means just not munging /etc/resolv.conf now, but also making sure that networking (and networking-adjacent filesystem changes, which is really what /etc/resolv.conf is at some level) changes moving forward have no effect on containers created with --net=none.

@nbastin can you please also edit your description accordingly ? Also it would be good to know which docker version  were you using earlier and which version brought in this changed behavior ? This will help us narrow down the root-cause and if it will have any impact on other users.

@nbastin It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

For a bug: do you still experience the issue with the latest version?
For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to https://github.com/docker/libnetwork/issues/1926

I added https://github.com/docker/libnetwork/issues/1928 in order to try to encapsulate the current state of the problems that started showing up with this issue.  Since new installs do not work for us we are moving away from docker as we build new systems, so my interest in this problem is somewhat negligible at this point.

authors: GordonTheTurtle mavenugo nbastin

repo: docker/libnetwork


text:
make the overlay network range configurable

Looks like the network range is hard coded for the overlay network driver. https://github.com/docker/libnetwork/blob/master/drivers/overlay/overlay.go#L50
This should be configurable, I'm happy to work on a PR for this.

Thanks @kelseyhightower. Yes. We are moving to the new ipam. And that will remove the hard coded range. Pls look out for a PR shortly.

@mavenugo Awesome.

Closed by #525

@kelseyhightower fyi, overlay and all network drivers are migrated to use the new IPAM concept.

authors: aboch kelseyhightower mavenugo


text:
Update ROADMAP.md

Removed release-specific info from the ROADMAP (better to keep this on the wiki; will not get stale). Made a couple of nips and tucks.
Signed-off-by: Amy Lindburg amy.lindburg@docker.com

:+1: LGTM

Thanks. LGTM.

authors: amylindburg dave-tucker mavenugo


text:
Authentocation fails using docker machine azure similar #384

Here is the details:
authenticate to machine driver docker :
Correlation ID: 94060a02-0396-4306-8b17-d7a7aa909b7c
Timestamp: 2016-06-14 14:44:58Z
AADSTS90093: Does not have access to consent.
Thanks

@digeler which issue are you referring to in the title? 384 seems like an irrelevant one.

@nathanleclaire please consider closing.

authors: ahmetalpbalkan digeler

repo: docker/machine


text:
Default boot2docker machine is not reachable

I'm getting an error creating a new boot2docker machine on Arch x64. I've removed all Host-only networks but vboxnet0 from Virtualbox 5.1.2_OSE.
$ docker-machine create --driver virtualbox default
Running pre-create checks...
Creating machine...
(default) Copying /home/ghost/.docker/machine/cache/boot2docker.iso to /home/ghost/.docker/machine/machines/default/boot2docker.iso...
(default) Creating VirtualBox VM...
(default) Creating SSH key...
(default) Starting the VM...
(default) Check network to re-create if needed...
(default) Waiting for an IP...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with boot2docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

This machine has been allocated an IP address, but Docker Machine could not
reach it successfully.

SSH for the machine should still work, but connecting to exposed ports, such as
the Docker daemon port (usually <ip>:2376), may not work properly.

You may need to add the route manually, or use another related workaround.

This could be due to a VPN, proxy, or host file configuration issue.

You also might want to clear any VirtualBox host only interfaces you are not using.
Checking connection to Docker...
Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "192.168.99.100:2376": dial tcp 192.168.99.100:2376: i/o timeout
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which will stop running containers.

Some basic things. I can ssh into the machine.
$ docker-machine stop default
$ rm -rf ~/.docker
$ docker-machine --version
docker-machine version 0.8.1, build HEAD
$ docker --version
Docker version 1.12.1, build 23cf638
$ uname -a
Linux x220 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 GNU/Linux
$ VBoxManage list hostonlyifs
Name:            vboxnet0
GUID:            786f6276-656e-4074-8000-0a0027000000
DHCP:            Disabled
IPAddress:       192.168.99.1
NetworkMask:     255.255.255.0
IPV6Address:
IPV6NetworkMaskPrefixLength: 0
HardwareAddress: 0a:00:27:00:00:00
MediumType:      Ethernet
Status:          Down
VBoxNetworkName: HostInterfaceNetworking-vboxnet0

$ docker-machine --debug create --driver virtualbox default output
$ docker-machine --debug regenerate-certs -f default output
$ ip addr show output

A reinstallation of both Virtualbox and Docker solved this.
# pacaur -R docker-machine docker-compose docker
# pacaur -S docker docker-machine net-tools
# pacaur -S virtualbox-host-modules-arch virtualbox
# modprobe vboxdrv
# modprobe vboxnetadp
# vboxreload

I have similarly issue, https://github.com/docker/machine/issues/2590

authors: ehernandez-xk sjaakvandenberg


text:
check for existing keypair

This stems from #381.  We should check for an existing keypair with the same name as this will almost always fail since Machine will not have access to the private key.

I'll update #290 too.

authors: ehazlett sthulb


text:
Improve client logging

Signed-off-by: Hu Keping hukeping@huawei.com

LGTM!

here we go :)

:+1:  thank you for your prompt responses!

authors: HuKeping cyli

repo: docker/notary


text:
Add a user_keys subdirectory to the KeyFileStore ...

where users can keep user keys.
This makes it so that we can sign with any key in the user_keys subdir.  Currently,
created keys are created in the user_keys subdirectory under the gun subdirectory,
but this can be a future change.
Note that user keys can be ANY role that is not a valid role, so we don't write
ourselves into a corner yet.
Signed-off-by: Ying Li ying.li@docker.com
We've also tested this manually by building a binary, by creating a key and moving to ../private/user_keys/SHA.key, and were able to add a delegation and add a target to a delegation using a hacked up version of #440.

LGTM

Closing this in favor of just adding a test to see if dropping keys in tuf_keys works.

authors: cyli diogomonica


text:
fix link

Signed-off-by: Sven Dowideit SvenDowideit@home.org.au

@sfsmithcha

LGTM

LGTM

authors: SvenDowideit sfsmithcha thaJeztah

repo: docker/swarm


text:
How to add rsync to this image correctly?

Currently I try docksal/bitbucket-pipelines-agent:php.

I'm assuming you want to contribute and this is a very easy contribution in fact :)
The php flavor is built from the base image. Any standard additional packages (available from Alpine repos) would go here: https://github.com/docksal/bitbucket-pipelines-agent/blob/develop/base/Dockerfile#L4-L9
Once the base image is built, the php one can be built from it.
Feel free to submit a PR.

authors: ArtuGit lmakarov

repo: docksal/bitbucket-pipelines-agent

license: mit


text:
Issues/177

Closes #178 178

Thanks

authors: Boegie lmakarov

repo: docksal/service-cli


text:
MySQL issue persisting

cap@ecomm-1003-vm: /Dev/drupal8$ fin restart
Disconnecting project network...
Stopping services...
Stopping drupal8_web_1    ... done
Stopping drupal8_cli_1    ... done
Stopping drupal8_chrome_1 ... done
Stopping drupal8_solr_1   ... done
Stopping drupal8_db_1     ... done
Stopping drupal8_pma_1    ... done
Starting services...
Creating network "drupal8_default" with the default driver
Pulling db (docksal/mysql:8.0-edge)...
8.0-edge: Pulling from docksal/mysql
54fec2fa59d0: Pull complete
[..]
d2fb21ed3a96: Pull complete
Digest: sha256:191b916a2383c3c7d159213132f224cbf6bf122c78d03e9963632ddd5d1b124d
Status: Downloaded newer image for docksal/mysql:8.0-edge
Starting drupal8_chrome_1 ... done
Starting drupal8_pma_1    ... done
Recreating drupal8_db_1   ... done
Starting drupal8_solr_1   ... done
Starting drupal8_cli_1    ... done
Starting drupal8_web_1    ... done
Connected vhost-proxy to "drupal8_default" network.
Waiting for project stack to become ready...
[..]
Waiting for project stack to become ready...
cap@ecomm-1003-vm: /Dev/drupal8$ fin bash
docker@cli:/var/www$ mysql
ERROR 1045 (28000): Plugin caching_sha2_password could not be loaded: /usr/lib/x86_64-linux-gnu/mariadb19/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory
docker@cli:/var/www$

Short answer: that's not how it works.
Running mysql instead cli (fin bash) without any options won't connect to the mysql server in the db container.
Do it like this instead:
docker@cli:/var/www$ mysql -h ${MYSQL_HOST} -u ${MYSQL_USER} -p${MYSQL_PASSWORD} ${MYSQL_DATABASE}
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 31
Server version: 8.0.20 MySQL Community Server - GPL

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [default]>

or using drush:
$ fin bash
docker@cli:/var/www$ cd docroot/
docker@cli:/var/www/docroot$ drush sql:cli
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 95
Server version: 8.0.20 MySQL Community Server - GPL

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [default]>

or using fin db cli from the host machine:
$ fin db cli
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 12
Server version: 8.0.20 MySQL Community Server - GPL

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

authors: ChristianAdamski lmakarov

repo: docksal/service-mysql

license: MIT


text:
Quickly Register Remote Bitbucket Workflow

Describe the bug
When something is wrong with the bitbucket token and trying to register a bitbucket workflow with "Quickly Register Remote Workflow", the error message says to relink GitLab instead.
To Reproduce
Steps to reproduce the behavior:

Make sure your bitbucket token is wrong (but exists)
Go to "Quickly Register Remote Workflow"
Select bitbucket.org
See error

Expected behavior
Error should say to relink bitbucket token
Additional context

UI version: 2.5.1
Webservice version: 1.8.1
host location: dockstore.org

┆Issue is synchronized with this Jira Story
┆Issue Type: Story
┆Sprint: Sprint 32 Grouper
┆Issue Number: DOCK-1255

Correctly says bitbucket on quick register
API - 1.9.0-alpha.9-SNAPSHOT
UI - 2.6.0-rc.0-9-g264e5615

authors: NatalieEO garyluu

repo: dockstore/dockstore


text:
mknod: /dev/net/tun not permitted despite --cap-add NET_ADMIN (podman)

Hi !
it worked once and now it doesn't want to anymore...
First of all:
# ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 Mar 30 12:24 /dev/net/tun

Then I run the following cmd:
# /usr/bin/podman run --cgroups=no-conmon     --label io.containers.autoupdate=registry       --rm    --sdnotify=conmon  --replace       --cap-add NET_ADMIN     --device /dev/kvm       --name win11    --stop-timeout 120 -p 8006:8006    -p 3389:3389/tcp        -p 3389:3389/udp        -e RAM_SIZE="16G"       -e CPU_CORES="4"        -v /zmedia/tmp/windows_storage:/storage    docker.io/dockurr/windows
and I get:
❯ Starting Windows for Docker v2.08...
❯ For support visit https://github.com/dockur/windows

mknod: /dev/net/tun: Operation not permitted
❯ ERROR: TUN device missing. Please add the following setting to your container: --cap-add NET_ADMIN

the system is :
# uname -a
Linux arch 6.6.23-1-lts #1 SMP PREEMPT_DYNAMIC Wed, 27 Mar 2024 07:47:20 +0000 x86_64 GNU/Linux
# podman -v
podman version 5.0.0

Note 1: i have another container using --device=/dev/net/tun
Note 2: -v /zmedia/tmp/windows_storage:/storage is not empty (even still has the iso) since it worked once)
# ls /zmedia/tmp/windows_storage/
data.img  shared  win11x64.iso	windows.mac  windows.ver

Thanks in advance for some input :)

i thought the NET_ADMIN capabilty was for this.
I tried and adding this moved to an iptables error message.
i got bored and moved to--privilegedwhich allowed it to work

repo: dockur/windows


text:
the options's default value confuse me, some can help?

My example codes like this:
"""
Usage:
  auto_task [options] cmd <comand>
  auto_task [options] get <src> <dst>
  auto_task [options] put <src> <dst>

Options:
  -h --help             Show this screen.
  -u <user>             Remote username [default: root]
  -p <password>         User's password
  --pkey <private-key>  Local private key [default: /root/.ssh/id_rsa]
"""

How could I deal the --pkey option like that(argaprse implement like that, but as far as I know,docopt dosen't behave like that):
  command line with only '--pkey',  the result dict include '--pkey':'/root/.ssh/id_rsa'
  command line with '--pkey some.file',  the result dict include '--pkey':'some.file'
  command line without '--pkey',  the result dict include '--pkey':None

I've found myself with a similar situation. The only way I see is to handle the default yourself. Something like this:
__db__ = '~/.bookmarks.sqlite'
__usage__ = """
Usage:
Usage:
  bookmarks.py [options] ....

Options:
    -d REF --dbref=REF
                  SQLAlchemy DB URL [default: %s]
""" % ( __db__, )

....

if __name__ == '__main__':
    opts = docopt(__doc__ + __usage__)
    opts['--dbref'] = .... assert_dbref(opts['--dbref'])
```

With optparse one might use a callback action for this.

authors: bvberkum jkklee

repo: docopt/docopt


text:
document page needs a serious refactor

When the editor changes(e.q. when the user type), the whole component, like the pad title and toolbar, rerender again! This is a critical issue and causes many lag and performance problems.

What user actions cause the editor to change at the moment?

authors: HMarzban edsaperia


text:
翻译PR

翻译预设es-2015 es-2016 es-2017

#76 #77 #78

authors: JameJJ QC-L


text:
Doctrine ODM annotations not being loaded

I am having an issue with an model while the others works succesfully.  I am using version 2.2.
I get this error:
Type: Doctrine\Common\Annotations\AnnotationException
Code: 0
Message: [Semantical Error] The annotation "@Doctrine\ODM\MongoDB\Mapping\Annotations\Document" in class CAAM\Entities\Payment was never imported. Did you maybe forget to add a "use" statement for this annotation?
File: D:\xampp\htdocs\caam\vendor\doctrine\annotations\lib\Doctrine\Common\Annotations\AnnotationException.php
Line: 39

My model is:
namespace CAAM\Entities;

use Doctrine\ODM\MongoDB\Mapping\Annotations as ODM;

/** @ODM\Document(collection="payments") */
class Payment
{}

The other models are identical and works!

This issue was caused by Mercado Pago's SDK that uses Doctrine Annotations

This issue was caused by Mercado Pago's SDK that uses Doctrine Annotations

This issue was caused by Mercado Pago's SDK that uses Doctrine Annotations

This sounds like it should be reported upstream
In general if you're not using symfony bundle (or zend module) there's a setup step you need to do yourself so the annotations can be loaded, from https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.1/reference/introduction.html#setup
$loader = require_once('path/to/vendor/autoload.php');

AnnotationRegistry::registerLoader([$loader, 'loadClass']);

this possibly is mitigated by some newer version of doctrine/annotations, depends what you have installed.

This issue was caused by Mercado Pago's SDK that uses Doctrine Annotations

This sounds like it should be reported upstream
In general if you're not using symfony bundle (or zend module) there's a setup step you need to do yourself so the annotations can be loaded, from https://www.doctrine-project.org/projects/doctrine-mongodb-odm/en/2.1/reference/introduction.html#setup
$loader = require_once('path/to/vendor/autoload.php');

AnnotationRegistry::registerLoader([$loader, 'loadClass']);

this possibly is mitigated by some newer version of doctrine/annotations, depends what you have installed.

authors: malarzm thisbar

repo: doctrine/mongodb-odm


text:
Add aggregation builder

Doctrine\MongoDB\Collection has an aggregate() method that will run an aggregation pipeline against the collection. Unfortunately, the pipeline itself has to be defined with usual arrays:
$expectedPipeline = array(
    array(
        '$geoNear' => array(
            'near' => $point,
            'spherical' => true,
            'distanceField' => 'distance',
            'query' => array(
                'hasCoordinates' => array('$exists' => true),
                'username' => 'foo',
            ),
            'num' => 10
        )
    ),
    array('$match' =>
        array(
            'group' => array('$in' => array('a', 'b'))
        )
    ),
    array('$unwind' => 'a'),
    array('$unwind' => 'b'),
    array('$redact' =>
        array(
            '$cond' => array(
                'if' => array('$lte' => array('$accessLevel', 3)),
                'then' => '$$KEEP',
                'else' => '$$REDACT',
            )
        )
    ),
    array('$project' =>
        array(
            '_id' => false,
            'user' => true,
            'amount' => true,
            'invoiceAddress' => true,
            'deliveryAddress' => array(
                '$cond' => array(
                    'if' => array(
                        '$and' => array(
                            array('$eq' => array('$useAlternateDeliveryAddress', true)),
                            array('$ne' => array('$deliveryAddress', null))
                        )
                    ),
                    'then' => '$deliveryAddress',
                    'else' => '$invoiceAddress'
                )
            )
        )
    ),
    array('$group' =>
        array(
            '_id' => '$user',
            'numOrders' => array('$sum' => 1),
            'totalAmount' => array('$sum' => '$amount'),
            'avgAmount' => array('$avg' => '$amount')
        )
    ),
    array('$sort' => array('totalAmount' => 0, 'numOrders' => -1, 'avgAmount' => 1)),
    array('$limit' => 5),
    array('$skip' => 2),
    array('$out' => 'collectionName')
);

@jmikola has previously said (https://github.com/doctrine/mongodb/issues/89#issuecomment-14576474):

The real feature I had in mind was something integrated into the query builder, but I suppose that can wait.

That was some time ago, and since I recently needed to write some big aggregations I decided to give the whole thing a shot. I've decided against integrating it in the query builder and instead made a dedicated aggregation builder. This helps keeping both functionalities apart.
The idea behind this is best explained with a sample pipeline:
$builder = $collection->createAggregationBuilder();
$builder
    ->geoNear($point)
        ->distanceField('distance')
        ->limit(10) // Limit is applied on $geoNear
        ->field('hasCoordinates')
        ->exists(true)
        ->field('username')
        ->equals('foo')
    ->match()
        ->field('group')
        ->in(array('a', 'b'))
    ->unwind('a')
    ->unwind('b')
    ->redact()
        ->cond(
            $builder->operator()->lte('$accessLevel', 3),
            '$$KEEP',
            '$$REDACT'
        )
    ->project()
        ->excludeIdField()
        ->includeFields(array('user', 'amount', 'invoiceAddress'))
        ->field('deliveryAddress')
        ->cond(
            $builder->operator()
                ->addAnd($builder->operator()->eq('$useAlternateDeliveryAddress', true))
                ->addAnd($builder->operator()->ne('$deliveryAddress', null)),
            '$deliveryAddress',
            '$invoiceAddress'
        )
    ->group()
        ->field('_id')
        ->value('$user')
        ->field('numOrders')
        ->sum(1)
        ->field('totalAmount')
        ->sum('$amount')
        ->field('avgAmount')
        ->avg('$amount')
    ->sort('totalAmount')
    ->sort(array('numOrders' => 'desc', 'avgAmount' => 'asc')) // Multiple subsequent sorts are combined into a single stage
    ->limit(5)
    ->skip(2)
    ->out('collectionName');

TODOs:

[x] Aggregation\Expr object
[x] redact stage
[x] group stage
[x] project stage
[x] nested documents in project and group stages with appropriate methods
[x] Tests

[x] Tests for Aggregation\Expr
[x] Tests for Aggregation\Builder
[x] Tests for individual stages

[ ] Fix Scrutinizer issues

:+1:

Hi any idea when this will be available?  Do you know if it will support DBRef as part of the query?

@bicatu No idea when it will be ready. For now it supports all things I could think of when it comes to aggregation, I need to add unit tests which I won't be able to do until in a few weeks. Until then, if you're brave you can play around and see what complicated or larger aggregations feel like.
As for DBRef, it supports it as rudimentary as MongoDB allows within aggregation:

You can add a query for field.$id in the $match stage
You can use the entire field in a $project, $group or $redact stage like so $group: { _id: { '$fieldWithReference' } }
You can not specifically use any nested fields of a DBRef object due to the $ being reserved as operator, so this won't work: $group: { _id: { '$fieldWithReference.$id' } }

The last one is a limitation imposed by MongoDB that we can't circumvent.

Hi, I am trying your fork/branch and I can use for all but my DBRef queries.
Ex. The following match works in the console
db.collection.aggregate([ {$match: {member: DBRef("Member", ObjectId("5566706ea10fdb0ddc0041a7"), "doctrine_odm")}}])
but when I try from the code I get zero results.
$builder = $collection->createAggregationBuilder();
        $builder->match()
            ->field('member')
            ->equals(\MongoDBRef::create("Member", "5566706ea10fdb0ddc0041a7", "doctrine_odm"));

@bicatu Shouldn't the second param to MongoDBRef::create be wrapped in an ObjectId constructor?

Indeed, after I added the new \MongoId() it worked.  Thanks.
So now really we just have to wait for it to be merged :)
:+1:

Hi, beside time is there anything preventing this from being merged?

@bicatu: I spoke with @alcaeus earlier this week about reviewing this and several other outstanding PRs so we can triage for a 1.2.0 release. I hope to get to this and the Cursor interface stuff before the weekend.

Well, besides @jmikola and his all-seeing eye the only thing missing from my end are tests. I was on vacation the past two weeks which is why nothing has moved along. I'll pick this up again in the next couple of days™.

@alcaeus let me know if I can help.

@bicatu You can test it with the aggregation queries you are currently running against your database. I'm especially interested on feedback on how it feels to use the aggregation builder. The goal was to make the builder work like the query builder as much as possible, with the exception that aggregation queries are by nature more complex than regular lookups.
Other than that I'll just push through with unit test - of course you're welcome to help with those if you'd like ;)

Ufff that was huge, definitely :+1: for doing this! LGTM beside few small things I've pointed out :)

@alcaeus: I restarted the two hung builds earlier today and it looks like they've completed. Are we good to go here?

Yep - good to go. I thought about moving the field() method out of Expr and into the $group, $project and $redact stages separately since an Expression doesn't usually need the functionality with a field name, only root level expressions in an aggregation stage need it. It would be quite a change but clean up the API. What do you think?

It would be quite a change but clean up the API. What do you think?

Sounds reasonable to me. It will also make it less likely for a user to shoot themselves in the foot by generating an invalid pipeline.

since an Expression doesn't usually need the functionality with a field name

$project might need special consideration here. See: Embedded Document Fields, where this is valid projection on contact:
contact: { address: { country: <1 or 0 or expression> } }

$project might need special consideration here.

Yes, $project and $group both need an Expr class that has a field() method to support embedded documents. In that case I suggest we leave it as it is now to avoid having to introduce another Expr class in addition to the two classes we already have (Aggregation\Expr and Query\Expr).
This might leave some options where users might shoot themselves in the foot but I don't think those cases are worth introducing a bunch of classes.

LGTM. Feel free to do the honors :)

Glad to see that this feature is available in the version 1.0.1.
It would be more useful if hydration can be enabled for those queries which return single or collection of the same document on which aggregation is run.

@metanav as far as I know @alcaeus has plans to improve aggregation for ODM, this is just the base :)

As @malarzm has stated, this is just the base required to support hydrated aggregation results in ODM. Hydrated aggregation results are a bit complicated since it requires a lightweight way to map results - every aggregation query needs a different result document, unlike regular documents where every query produces the same result. I'll pick this up in the coming weeks - look for a PR in https://github.com/doctrine/mongodb-odm ;)

Sometimes it is needed to pass already built query (using QueryBuilder or manuallly) to the AggregationBuilder match stage as an array (or object, I don't know if both builders are compatible to each other). Is there any way to achieve this in the current version or any possibility to add this feature to make it more flexible?

You mean something like $queryBuilder->matchArray(['foo' => 'bar']);? In that case, no, it's not possible and when thinking of the API I didn't deem it necessary. If you could explain your use case I could give it some thought and see if we can come up with something.

I do not think it is not possible, may be I could not explain it.
I've created an example gist here:  https://gist.github.com/metanav/ace4e5de7aecd556c5a8

Gotcha. What you can do is abuse the fact that using equals without a currentField sets your query to whatever you pass it. In your case:
if (is_array($filter)) {
    $ab->match()->equals($filter);
} else {
    $ab->match()->text($filter);
}

I tried it by adding more fields after that as well:
public function testFilterArray()
{
    $filter = ['name' => 'keyword'];

    $matchStage = new Match($this->getTestAggregationBuilder());
    $matchStage
        ->equals($filter)
        ->field('someField')
        ->equals('someValue');

    $expectedMatch = ['name' => 'keyword', 'someField' => 'someValue'];
    $this->assertEquals(['$match' => $expectedMatch], $matchStage->getExpression());
}

Thanks, worked like a charm!  I hope this is not an artefact and should not be lost in some fixes :).

It is a feature of the query builder (on which the match stage relies) and has been there for some time. I think you might be safe ;)

I guess DateTime object to MongoDate object conversion is not being done automatically as we have in Query builder.

I'm guessing you're thinking of ODM. This library sits between the driver and ODM and just provides nicer interfaces for the legacy driver. Type conversion is handled only by the ODM - you'll have to do your own conversions.

Oh yes, got it!

FWIW, I should be able to get back to doctrine/mongodb-odm#1263 soon now that we've gotten rid of old PHP and driver versions across the board. That library will do type conversion, at least in early $match stages. Not sure how much type conversion is going to be possible once projection and grouping kicks in - we don't have any mapping information for stages in the middle of the pipeline.

Would priming be possible in doctrine/mongodb-odm#1263 at least in $match stages?

What exactly do you mean? Priming has nothing to do with individual stages, just result. Let's say your aggregation result document contains a reference to another document: this is where priming is effective since it fetches all referenced documents at once. However, this doesn't affect the execution of the pipeline itself, which is done by MongoDB. This library provides a clean interface to create pipelines, ODM will give you type conversion and hydration into nice objects instead of dealing with arrays. Everything else is MongoDB and the driver doing their things.

Yes, priming has nothing to do with match. I should have  asked if priming is possible in hydration?

I'll certainly put it on the list of things that could be useful. Not sure I can add it right from the get-go.

authors: alcaeus bicatu gruberro jmikola malarzm metanav solocommand

repo: doctrine/mongodb


text:
+HERE’S!!*+ WAY TO WATCH Aston Villa vs Brighton LiVe 𝐒𝐭𝐫𝐞𝐚𝐦𝐬 ON Premier League TV CHANNEL 2024

HERE’S!!* WAY TO WATCH Aston Villa vs Brighton LiVe 𝐒𝐭𝐫𝐞𝐚𝐦𝐬 ON Premier League TV CHANNEL

◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw
◑﹏◐
ALL TV LIVE
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
.
.

.
.

.
.

.
.
.
.

.
.

.

.
.
👉⏩🎥🅻🅸🆅🅴🔴▶ ✅🟢 STREAM PLAY NOW ▶
.
👉⏩🎥🆆🅰🆃🅲🅷🔴▶ ✅🟢 PLAY NOW ONLINE
xdw

bgf
✅🟢 STREAM PLAY NOW ▶
✅🟢 PLAY NOW ONLINE

.
✅🟢 STREAM PLAY NOW ▶
✅🟢 PLAY NOW ONLINE
xswq

authors: neroevo666 tmakhs umonhasana

repo: doczjs/docz


text:
Link filenames in statements to file content

Add option to link filenames in statements to file content (files in the description/media folder). This way, users can inspect the file content from the feedback table.

Example: submission 6607997
Here's how the file content is displayed in the feedback table of the Python judge:

Example: submission 6493363

Instead of all files in workdir we could also put them in evaluation (e.g. evaluation/workdir). This would not make the files accessible by default (the evaluation dir is only accessible for the judge, not for the submitted code; should be treated as readonly). We could then "register" the files that are needed in a given context, which could server multiple purposes:

copy only those files to the execution context (from evaluation/workdir or workdir); this would have the benefit that one context could not remove, change or tamper the files in a ways that influence other contexts
on the feedback page: link filenames in statements to file content
make files available e.g. to Python Tutor (future work)

To zoom in on "registering" the files, some possibilities I can think of:

Include a list of files in the test plan in a special input (e.g. there is a fixed file or you don't want to work with arguments)
Introduce a new "type" in the function arguments: "FileName".

Works with how we often do things (pass the "path" to the file as an argument)
Allows to annotate those params as a file for Dodona (I forget how this happens, but it will be cleaner than guessing which params are a file and which not)

Both could be supported at the same time.

This is how it looks like in a testcase on the feedback table:

coordinates('photo01.txt')

return

{(0, 0), (1, 1), (0, 2)}

Maybe we could also experiment with providing file links in a separate context-level message in the feedback table.

authors: niknetniko pdawyndt

repo: dodona-edu/universal-judge


text:
translate who-owns-dogecoin.md into Chinese

translate who-owns-dogecoin.md into Chinese

@bobdos


text:
Fire event when scrolling past?

Working with the circlular carousel, and I'm missing one feature
Wondering if there is a way to fire an event (e.g. haptic) when an item is passing by the center.
I've tried both onScrollEnd and ProgressChange trying to convert the absolute valute to index and then firing. But when scrolling faster it seems to not be possible.
Basically just the implementation from examples im playing with atm.
<Carousel
                  ref={ref}
                  width={itemSize}
                  height={itemSize}
                  style={{
                    width: UI_CONSTANTS.screenWidth,
                    height: UI_CONSTANTS.screenWidth / 2,
                  }}
                  onProgressChange={onProgressChange}
                  onScrollEnd={onSnapToItem}
                  snapEnabled
                  pagingEnabled={false}
                  overscrollEnabled={false}
                  scrollAnimationDuration={200}
                  data={data || []}
                  renderItem={({ item, index }) => (
                    <Pressable
                      key={item._id}
                      onPress={() => onItemPress(index)}
                      style={{ flex: 1 }}
                    >
                      <View
                        style={{
                          backgroundColor: 'black',
                          flex: 1,
                          borderRadius: 100,
                          justifyContent: 'center',
                          overflow: 'hidden',
                          alignItems: 'center',
                          borderWidth: 2,
                          borderColor: palette.primary[500],
                        }}
                      >
                        <View style={{ width: '100%', height: '100%' }}>
                          <SlideItem index={index} source={{ uri: item.imageLogo }} />
                        </View>
                      </View>
                    </Pressable>
                  )}
                  customAnimation={animationStyle}
                />

I solved it with useAnimatedReaction.
const scrollPosition = useSharedValue(0);
let centeredElement: number | undefined;

const onCenterItemChange = (currentIndex: any) => {
  if (centeredElement != currentIndex) {
    Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Soft)
    centeredElement = currentIndex;
     }};

useAnimatedReaction(
    () => Math.round(scrollPosition.value),
    (currentIndex) => {
        runOnJS(onCenterItemChange)(currentIndex);
    },
    [scrollPosition] );

  <Carousel
  ...
  onProgressChange={(_, absoluteProgress) => {
     scrollPosition.value = absoluteProgress;
      }}>
  ...

authors: DanielProode bobbyziom

repo: dohooo/react-native-reanimated-carousel


text:
use with multiple clusters in the same projet

Firstly, thanks for taking the time to create this tool. It has solved a key problem for us! :)
Describe the bug
I have two clusters, one for UAT and one for Live. I have set KubeIP up on the UAT cluster smoothly; no errors and IP addresses are being assigned. Working like a dream.
However, applying the same* process to the Live cluster has not rendered the same result. The KubeIP pod seems stuck in the ContainerCreating state.
The process for setting up the Live cluster (which I did second, after UAT) was a little different because I did not have to set up the service accounts, etc. These are project-bound as far as I know. Is this correct? I think that his also means that I can use the same secret key.
This command:

kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user gcloud config list --format 'value(core.account)'

Returned:

Error from server (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "cluster-admin-binding" already exists

Which did not happen the first time, when I was setting this up for UAT. I am a little suspicious that maybe this is the problem...
Also, this is how my status IP addresses are labelled. Is this configuration OK?

To Reproduce
Steps to reproduce the behavior:

Set up a cluster to use KubeIP (everything works fine);
Attempt to set up a second cluster (the KubeIP pod gets stuck in a ContainerCreating state).

Expected behavior
I believe that the pod should launch and I should get static IPs assigned.
Screenshots
See above.
Additional context
None.

Never mind! Silly error on my part. However, if anyone else comes across this problem the issue that you do not to create the kubeip-key for each cluster (well, within the namespace of each cluster).
Once I did that everything worked right away!
Thanks again for this awesome tool. :)

repo: doitintl/kubeip


text:
D3D9: Port flush heuristic from D3D11

Needs testing.
The flush heuristic itself already works well for D3D11 in practice, with major benefits being that:

There is no race condition with the pending submission count, unlike in the old code
We can flush at CS chunk boundaries, even during extremely long command sequences where we otherwise wouldn't
CPU timing is no longer used as a source of information, which makes this a lot more consistent
Resource readback latency in general should be much lower.

We probably don't want to flush halfway through some commands like StretchRect, ProcessVertices, LockImage and Clear which have a couple of EmitCs'es...
A few of these can probably be changed to be a lot smarter/less shit than the code I wrote like 3 years ago to avoid that too.

This currently breaks Gothic 3, which wont continue after finishing loading a game. Not sure if Josh's remarks would fix it.

Gothic should be fixed.

yep works now :beers:

Looks fine but I still want to merge some of these EmitCses at some point..,

authors: Joshua-Ashton Riesi doitsujin

repo: doitsujin/dxvk

license: Zlib


text:
[GUI] Template name empty: the text was not translated

The text was not translated into Portuguese:

Steps to reproduce the problem:

Click "Novo modelo"
Click "Salvar"

Affected Version: 58.2-20190321

Test OK.

Tested on Version: 62.3-20190603

repo: dojot/dojot


text:
make more use of module_utils

Make use of module_utils/ -- they’re your friends
– basic.py
– api.py
– facts/
– urls.py
– six.py
– noteworthy others: ec2.py, docker.py, database.py, mysql.py, powershell.ps1 — and many many more
See also ansible docs
Besides reusing functionality provided by ansible, there is also a ton of code duplication in the dokku_ modules, i.e. the first step would be just to remove that.

Not going to continue along this route for the moment.
Happy to reopen if someone wants to pick this up.

repo: dokku/ansible-dokku