docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Known issues updates

This commit is contained in:
paigehargrave 2019-06-11 16:19:36 -04:00 committed by GitHub
parent c5ab8e75f9
commit 17fe71e6ca
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 24 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
engine/release-notes.md
View File

@ -180,11 +180,29 @@ fix: `api.go doesn't respect nsswitch.conf`. [moby/moby#38126](https://github.co
include the error `code = ResourceExhausted desc = grpc: received message larger than include the error `code = ResourceExhausted desc = grpc: received message larger than
max (5351376 vs. 4194304)`. This does not indicate any failure or misconfiguration by the user, max (5351376 vs. 4194304)`. This does not indicate any failure or misconfiguration by the user,
and requires no response. and requires no response.
* Attempts to deploy local PV fail with regular UCP configuration unless PV binder SA is binded to cluster admin role. * Attempts to deploy local PV fail with regular UCP configuration unless PV binder SA is bound to cluster admin role.
- Workaround: Create a `ClusterRoleBinding` that binds the `persistent-volume-binder` serviceaccount
to a `cluster-admin` `ClusterRole`, as shown in the following example:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
subjectName: kube-system-persistent-volume-binder
name: kube-system-persistent-volume-binder:cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: persistent-volume-binder
namespace: kube-system
```
* Orchestrator port conflict can occur when redeploying all services as new. Due to many swarm manager * Orchestrator port conflict can occur when redeploying all services as new. Due to many swarm manager
requests in a short amount of time, some services are not able to receive traffic and are causing a `404` requests in a short amount of time, some services are not able to receive traffic and are causing a `404`
error after being deployed. error after being deployed.
Workaround: restart all tasks via `docker service update --force`. - Workaround: restart all tasks via `docker service update --force`.
* Traffic cannot egress the HOST because of missing Iptables rules in the FORWARD chain * Traffic cannot egress the HOST because of missing Iptables rules in the FORWARD chain
The missing rules are : The missing rules are :
@ -192,9 +210,10 @@ The missing rules are :
sbin/iptables --wait -C FORWARD -o docker_gwbridge -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT sbin/iptables --wait -C FORWARD -o docker_gwbridge -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables --wait -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT /sbin/iptables --wait -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
``` ```
Workaround: Add these rules back using a script and cron definitions. The script must contain '-C' commands to check for the presence of a rule and '-A' commands to add rules back. Run the script on a cron in regular intervals, for example, every <x> minutes. (Is there a recommendation for 'x'?) - Workaround: Add these rules back using a script and cron definitions. The script must contain '-C' commands
(If Arko's workaround becomes available, the docs will be updated to direct customers to use that until we get it out in a patch.) to check for the presence of a rule and '-A' commands to add rules back. Run the script on a cron in regular
Affected versions: 17.06.2-ee-16, 18.09.1, 19.03.0 intervals, for example, every <x> minutes.
- Affected versions: 17.06.2-ee-16, 18.09.1, 19.03.0
## 18.09.6 ## 18.09.6
2019-05-06 2019-05-06