mirror of https://github.com/docker/docs.git
February 2019 release notes
This commit is contained in:
Maria Bermudez
parent
7aee0ae6ea
commit
dd71ca6ae6
|
|
@ -11,6 +11,14 @@ known issues for each DTR version.
|
|||
You can then use [the upgrade instructions](admin/upgrade.md),
|
||||
to upgrade your installation to the latest release.
|
||||
|
||||
## Version 2.3.11
|
||||
|
||||
(28 February 2019)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Bump the Golang version that is used to build DTR to version 1.10.8. (docker/dhe-deploy#10064)
|
||||
|
||||
## Version 2.3.10
|
||||
|
||||
(29 January 2019)
|
||||
|
|
|
|||
|
|
@ -22,13 +22,56 @@ to upgrade your installation to the latest release.
|
|||
|
||||
# Version 2.6
|
||||
|
||||
## 2.6.3
|
||||
|
||||
(2019-2-28)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Bump the Golang version that is used to build DTR to version 1.11.5. (docker/dhe-deploy#10060)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Docker Engine Enterprise Edition (Docker EE) Upgrade
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before `18.09` to version `18.09` or greater. For DTR-specific changes, see [2.5 to 2.6 upgrade](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
* Web Interface
|
||||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
|
||||
* System
|
||||
* When upgrading from `2.5` to `2.6`, the system will run a `metadatastoremigration` job after a successful upgrade. This is necessary for online garbage collection. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
## 2.6.2
|
||||
|
||||
(2019-1-29)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Fixed a bug where scanning Windows images were stuck in Pending state. (docker/dhe-deploy #9969)
|
||||
* Fixed a bug where scanning Windows images were stuck in Pending state. (docker/dhe-deploy #9969)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Docker Engine Enterprise Edition (Docker EE) Upgrade
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before `18.09` to version `18.09` or greater. For DTR-specific changes, see [2.5 to 2.6 upgrade](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
* Web Interface
|
||||
* Users with read-only permissions to a repository can edit the repository README but their changes will not be saved. Only repository admins should have the ability to [edit the description](/ee/dtr/admin/manage-users/permission-levels/#team-permission-levels) of a repository. (docker/dhe-deploy #9677)
|
||||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
|
||||
* System
|
||||
* When upgrading from `2.5` to `2.6`, the system will run a `metadatastoremigration` job after a successful upgrade. This is necessary for online garbage collection. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
## 2.6.1
|
||||
|
||||
|
|
@ -43,6 +86,24 @@ to upgrade your installation to the latest release.
|
|||
### Changelog
|
||||
* GoLang version bump to 1.11.4.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Docker Engine Enterprise Edition (Docker EE) Upgrade
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before `18.09` to version `18.09` or greater. For DTR-specific changes, see [2.5 to 2.6 upgrade](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
* Web Interface
|
||||
* Users with read-only permissions to a repository can edit the repository README but their changes will not be saved. Only repository admins should have the ability to [edit the description](/ee/dtr/admin/manage-users/permission-levels/#team-permission-levels) of a repository. (docker/dhe-deploy #9677)
|
||||
* Poll mirroring for Docker plugins such as `docker/imagefs` is currently broken. (docker/dhe-deploy #9490)
|
||||
* When viewing the details of a scanned image tag, the header may display a different vulnerability count from the layer details. (docker/dhe-deploy #9474)
|
||||
* In order to set a tag limit for pruning purposes, immutability must be turned off for a repository. This limitation is not clear in the **Repository Settings** view. (docker/dhe-deploy #9554)
|
||||
|
||||
* Webhooks
|
||||
* When configured for "Image promoted from repository" events, a webhook notification is triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
|
||||
* System
|
||||
* When upgrading from `2.5` to `2.6`, the system will run a `metadatastoremigration` job after a successful upgrade. This is necessary for online garbage collection. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](/ee/dtr/admin/upgrade/#25-to-26-upgrade).
|
||||
|
||||
## 2.6.0
|
||||
|
||||
(2018-11-08)
|
||||
|
|
@ -105,6 +166,43 @@ to upgrade your installation to the latest release.
|
|||
|
||||
# Version 2.5
|
||||
|
||||
## 2.5.9
|
||||
|
||||
(2019-2-28)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Bump the Golang version that is used to build DTR to version 1.10.8. (docker/dhe-deploy#10071)
|
||||
|
||||
### Known Issues
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.8
|
||||
|
||||
(2019-1-29)
|
||||
|
|
@ -113,6 +211,35 @@ to upgrade your installation to the latest release.
|
|||
|
||||
* Fixed an issue that prevented vulnerability updates from running if they were previously interrupted. (docker/dhe-deploy #9958)
|
||||
|
||||
### Known Issues
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.7
|
||||
|
||||
(2019-01-09)
|
||||
|
|
@ -126,6 +253,35 @@ to upgrade your installation to the latest release.
|
|||
### Changelog
|
||||
* GoLang version bump to 1.10.7.
|
||||
|
||||
### Known Issues
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.6
|
||||
|
||||
(2018-10-25)
|
||||
|
|
@ -139,6 +295,35 @@ to upgrade your installation to the latest release.
|
|||
* Backported ManifestList fixes. (docker/dhe-deploy#9547)
|
||||
* Removed support sidebar link and associated content. (docker/dhe-deploy#9411)
|
||||
|
||||
### Known Issues
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.5
|
||||
|
||||
(2018-8-30)
|
||||
|
|
@ -149,6 +334,35 @@ to upgrade your installation to the latest release.
|
|||
* Fixed bug to enable poll mirroring with Windows images.
|
||||
* The RethinkDB image has been patched to remove unused components with known vulnerabilities including the RethinkCLI. To get an equivalent interface, run RethinkCLI from a separate image using `docker run -it --rm --net dtr-ol -v dtr-ca-$REPLICA_ID:/ca dockerhubenterprise/rethinkcli:v2.3.0 $REPLICA_ID`.
|
||||
|
||||
### Known Issues
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.3
|
||||
|
||||
(2018-6-21)
|
||||
|
|
@ -164,8 +378,33 @@ to upgrade your installation to the latest release.
|
|||
* Fixed issue where worker capacities wouldn't update on minor version upgrades.
|
||||
|
||||
### Known Issues
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* When configured for "Image promoted from repository" events, a webhook notification will be triggered twice during an image promotion when scanning is enabled on a repository. (docker/dhe-deploy #9685)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
|
||||
## 2.5.2
|
||||
|
|
@ -176,6 +415,35 @@ to upgrade your installation to the latest release.
|
|||
|
||||
* Fixed a problem where promotion policies based on scanning results would not be executed correctly.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.1
|
||||
|
||||
(2018-5-17)
|
||||
|
|
@ -202,6 +470,35 @@ to upgrade your installation to the latest release.
|
|||
* Enhancements to the mirroring interface including:
|
||||
* Fixed URL for the destination repository.
|
||||
* Option to skip TLS verification when testing mirroring.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Web Interface
|
||||
* The web interface shows "This repository has no tags" in repositories where tags
|
||||
have long names. As a workaround, reduce the length of the name for the
|
||||
repository and tag.
|
||||
* When deleting a repository with signed images, the DTR web interface no longer
|
||||
shows instructions on how to delete trust data.
|
||||
* There's no web interface support to update mirroring policies when rotating the TLS
|
||||
certificates used by DTR. Use the API instead.
|
||||
* The web interface for promotion policies is currently broken if you have a large number
|
||||
of repositories.
|
||||
* Clicking "Save & Apply" on a promotion policy doesn't work.
|
||||
* Webhooks
|
||||
* There is no webhook event for when an image is pulled.
|
||||
* HTTPS webhooks do not go through HTTPS proxy when configured. (docker/dhe-deploy #9492)
|
||||
* Online garbage collection
|
||||
* The events API won't report events when tags and manifests are deleted.
|
||||
* The events API won't report blobs deleted by the garbage collection job.
|
||||
* Docker EE Advanced features
|
||||
* Scanning any new push after metadatastore migration will not yet work.
|
||||
* Pushes to repos with promotion policies (repo as source) are broken when an
|
||||
image has a layer over 100MB.
|
||||
* On upgrade the scanningstore container may restart with this error message:
|
||||
FATAL: database files are incompatible with server
|
||||
|
||||
* System
|
||||
* When opting into online garbage collection, the system will run a `metadatastoremigration` job after a successful upgrade. If the three system attempts fail, you will have to retrigger the `metadatastoremigration` job manually. [Learn about manual metadata store migration](../../v18.03/ee/dtr/admin/configure/garbage-collection/#metadata-store-migration).
|
||||
|
||||
## 2.5.0
|
||||
|
||||
|
|
@ -299,6 +596,21 @@ specify `--log-protocol`.
|
|||
|
||||
# Version 2.4
|
||||
|
||||
## 2.4.10
|
||||
|
||||
(2019-2-28)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
* Bump the Golang version that is used to build DTR to version 1.10.8. (docker/dhe-deploy#10068)
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
|
||||
## Version 2.4.8
|
||||
|
||||
(2019-01-29)
|
||||
|
|
@ -306,6 +618,13 @@ specify `--log-protocol`.
|
|||
### Changelog
|
||||
* GoLang version bump to 1.10.6.
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
|
||||
## Version 2.4.7
|
||||
|
||||
(2018-10-25)
|
||||
|
|
@ -318,6 +637,12 @@ specify `--log-protocol`.
|
|||
* Patched security vulnerabilities in the load balancer.
|
||||
* Patch packages and base OS to eliminate and address some critical vulnerabilities in DTR dependencies.
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
## Version 2.4.6
|
||||
|
||||
(2018-07-26)
|
||||
|
|
@ -326,6 +651,12 @@ specify `--log-protocol`.
|
|||
* Fixed bug where repository tag list UI was not loading after a tag migration.
|
||||
* The RethinkDB image has been patched to remove unused components with known vulnerabilities including the rethinkcli. To get an equivalent interface please run the rethinkcli from a separate image using `docker run -it --rm --net dtr-ol -v dtr-ca-$REPLICA_ID:/ca dockerhubenterprise/rethinkcli $REPLICA_ID`.
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
## Version 2.4.5
|
||||
|
||||
(2018-06-21)
|
||||
|
|
@ -338,6 +669,12 @@ specify `--log-protocol`.
|
|||
|
||||
* Prevent OOM during garbage collection by reading less data into memory at a time.
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
## Version 2.4.4
|
||||
|
||||
(2018-05-17)
|
||||
|
|
@ -353,11 +690,17 @@ specify `--log-protocol`.
|
|||
* Reduce noise in the jobrunner logs by changing some of the more detailed messages to debug level.
|
||||
* Eliminate a race condition in which webhook for license updates doesn't fire.
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
## Version 2.4.3
|
||||
|
||||
(2018-03-19)
|
||||
|
||||
**Security**
|
||||
**Security notice**
|
||||
|
||||
* Dependencies updated to consume upstream CVE patches.
|
||||
|
||||
|
|
@ -411,6 +754,12 @@ vulnerability database.
|
|||
removed in DTR 2.5. You can use the
|
||||
`/api/v0/imagescan/repositories/{namespace}/{reponame}/{tag}` endpoint instead.
|
||||
|
||||
**Known issues**
|
||||
|
||||
* Backup uses too much memory and can cause out of memory issues for large databases.
|
||||
* The `--nfs-storage-url` option uses the system's default NFS version instead
|
||||
of testing the server to find which version works.
|
||||
|
||||
|
||||
## DTR 2.4.0
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,28 @@ upgrade your installation to the latest release.
|
|||
|
||||
# Version 3.1
|
||||
|
||||
## 3.1.4
|
||||
|
||||
2019-02-28
|
||||
|
||||
**New platforms**
|
||||
* Added support for SLES 15.
|
||||
* Added support for Oracle 7.6.
|
||||
|
||||
**Kubernetes**
|
||||
* Kubernetes has been updated to version 1.11.7. (docker/orca#16157)
|
||||
|
||||
**Bug Fixes**
|
||||
* Bump the Golang version that is used to build UCP to version 1.10.8. (docker/orca#16068)
|
||||
* Fixed an issue that caused UCP upgrade failure to upgrade with Interlock deployment. (docker/orca#16009)
|
||||
* Fixed an issue that caused Windows node ucp-agent(s) to constantly reboot when audit logging is enabled. (docker/orca#16122)
|
||||
* Fixed an issue to ensure that non-admin user actions (with the RestrictedControl role) against RBAC resources are read-only. (docker/orca#16121)
|
||||
* Fixed an issue to prevent UCP users from updating services with a port that conflicts with the UCP controller port. (escalation#855)
|
||||
* Fixed an issue to validate Calico certs expiration dates and update accordingly. (escalation#981)
|
||||
|
||||
**Enhancements**
|
||||
* Changed packaging and builds for UCP to build bootstrapper last. This avoids the "upgrade available" banner on all UCPs until the entirety of UCP is available.
|
||||
|
||||
## 3.1.3
|
||||
|
||||
2019-01-29
|
||||
|
|
@ -212,6 +234,16 @@ The following features are deprecated in UCP 3.1.
|
|||
|
||||
# Version 3.0
|
||||
|
||||
## 3.0.10
|
||||
|
||||
2019-02-28
|
||||
|
||||
**Bug Fixes**
|
||||
* Bump the Golang version that is used to build UCP to version 1.10.8.
|
||||
* Prevent UCP users from updating services with a port that conflicts with the UCP controller port. (escalation#855)
|
||||
* Fixed an issue that causes UCP fail to upgrade with Interlock deployment. (#16009)
|
||||
* Validate Calico certs expiration date and update accordingly. (escalation#981)
|
||||
|
||||
## 3.0.9
|
||||
|
||||
2018-01-29
|
||||
|
|
@ -654,12 +686,66 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
|
||||
# Version 2.2
|
||||
|
||||
## Version 2.2.17
|
||||
|
||||
2019-02-28
|
||||
|
||||
**Bug Fixes**
|
||||
* Bump the Golang version that is used to build UCP to version 1.10.8.
|
||||
* Prevent UCP users from updating services with a port that conflicts with the UCP controller port. (escalation#855)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.16
|
||||
|
||||
2019-01-29
|
||||
2019-01-29
|
||||
|
||||
### Bug fixes
|
||||
* Added support for the `limit` argument in `docker ps`. (#15812)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.15
|
||||
|
||||
|
|
@ -670,7 +756,30 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* Significantly reduced database load in environments with a lot of concurrent and repeated API requests by the same user.
|
||||
* Added the ability to set custom HTTP response headers to be returned by the UCP Controller API Server.
|
||||
* Web interface
|
||||
* Fixed stack creation for non admin user when UCP uses a custom controller port.
|
||||
* Fixed stack creation for non admin user when UCP uses a custom controller port.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.14
|
||||
|
||||
|
|
@ -684,6 +793,29 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
|
||||
* Web Interface
|
||||
* Fixed an issue that prevented "Per User Limit" on Admin Settings from working. (docker/escalation#639)
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.13
|
||||
|
||||
|
|
@ -694,6 +826,29 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* Security
|
||||
* Fixed a critical security issue to prevent UCP from accepting certificates from
|
||||
the system pool when adding client CAs to the server that requires mutual authentication.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.12
|
||||
|
||||
|
|
@ -706,6 +861,29 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
were stored in cleartext on UCP hosts. Please refer to the following KB article
|
||||
https://success.docker.com/article/upgrading-to-ucp-2-2-12-ucp-3-0-4/
|
||||
for proper implementation of this fix.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.11
|
||||
|
||||
|
|
@ -730,6 +908,29 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* UI
|
||||
* Fixed an issue that causes the web interface to not parse volume options correctly.
|
||||
* Fixed an issue that prevents the user from deploying stacks through the web interface.
|
||||
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.10
|
||||
|
||||
|
|
@ -765,11 +966,28 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* UCP can now be installed on a system with more than 127 logical CPU cores.
|
||||
* Improved the performance of UCP's local and global health checks.
|
||||
|
||||
### Known Issue
|
||||
### Known issues
|
||||
|
||||
* Excessive delay is seen when sending `docker service ls` through a UCP client
|
||||
bundle on a cluster that is running thousands of services.
|
||||
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.9
|
||||
|
||||
|
|
@ -785,6 +1003,27 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* Core
|
||||
* Fixed an issue that causes container fail to start with `container ID not found`
|
||||
during high concurrent API calls to create and start containers.
|
||||
|
||||
### Known issues
|
||||
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.7
|
||||
|
||||
|
|
@ -795,6 +1034,27 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* Fixed an issue where the minimum TLS version setting is not correctly handled,
|
||||
leading to non-default values causing `ucp-controller` and `ucp-agent` to keep
|
||||
restarting.
|
||||
|
||||
### Known issues
|
||||
|
||||
* RethinkDB can only run with up to 127 CPU cores.
|
||||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.6
|
||||
|
||||
|
|
@ -850,6 +1110,20 @@ deprecated. Deploy your applications as Swarm services or Kubernetes workloads.
|
|||
* When integrating with LDAP and using multiple domain servers, if the
|
||||
default server configuration is not chosen, then the last server configuration
|
||||
is always used, regardless of which one is actually the best match.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
|
||||
## Version 2.2.5
|
||||
|
|
@ -873,6 +1147,20 @@ plugins. If you’re using certain third-party volume plugins (such as Netapp)
|
|||
and are planning on upgrading UCP, you can skip 2.2.5 and wait for the upcoming
|
||||
2.2.6 release, which will provide an alternative way to turn on RBAC enforcement
|
||||
for volumes.
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.4
|
||||
|
||||
|
|
@ -905,7 +1193,19 @@ for volumes.
|
|||
### Known issues
|
||||
|
||||
* Docker currently has limitations related to overlay networking and services using VIP-based endpoints. These limitations apply to use of the HTTP Routing Mesh (HRM). HRM users should familiarize themselves with these limitations. In particular, HRM may encounter virtual IP exhaustion (as evidenced by `failed to allocate network IP for task` Docker log messages). If this happens, and if the HRM service is restarted or rescheduled for any reason, HRM may fail to resume operation automatically. See the Docker EE 17.06-ee5 release notes for details.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* The Swarm admin web interface for UCP versions 2.2.0 and later contain a bug. If used with Docker Engine version 17.06.2-ee5 or earlier, attempting to update "Task History Limit", "Heartbeat Period" and "Node Certificate Expiry" settings using the UI will cause the cluster to crash on next restart. Using UCP 2.2.X and Docker Engine 17.06-ee6 and later, updating these settings will fail (but not cause the cluster to crash). Users are encouraged to update to Docker Engine version 17.06.2-ee6 and later, and to use the Docker CLI (instead of the UCP UI) to update these settings. Rotating join tokens works with any combination of Docker Engine and UCP versions. Docker Engine versions 17.03 and earlier (which use UCP version 2.1 and earlier) are not affected by this problem.
|
||||
* Upgrading heterogeneous swarms from CLI may fail because x86 images are used
|
||||
instead of the correct image for the worker architecture.
|
||||
* Agent container log is empty even though it's running correctly.
|
||||
* Rapid UI settings updates may cause unintended settings changes for logging
|
||||
settings and other admin settings.
|
||||
* Attempting to load an (unsupported) `tar.gz` image results in a poor error
|
||||
message.
|
||||
* Searching for images in the UCP images UI doesn't work.
|
||||
* Removing a stack may leave orphaned volumes.
|
||||
* Storage metrics are not available for Windows.
|
||||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
## Version 2.2.3
|
||||
|
||||
|
|
@ -960,7 +1260,6 @@ for volumes.
|
|||
* You can't create a bridge network from the web interface. As a workaround use
|
||||
`<node-name>/<network-name>`.
|
||||
|
||||
|
||||
## version 2.2.2
|
||||
|
||||
2017-08-30
|
||||
|
|
@ -994,9 +1293,34 @@ for volumes.
|
|||
|
||||
### Known issues
|
||||
|
||||
* When deploying compose files that use secrets, the secret definition must
|
||||
include `external: true`, otherwise the deployment fails with the error
|
||||
* UI issues:
|
||||
* Cannot currently remove nodes using UCP web interface. Workaround is to remove from CLI
|
||||
instead.
|
||||
* Search does not function correctly for images.
|
||||
* Cannot view label constraints from a collection's details pages. Workaround
|
||||
is to view by editing the collection.
|
||||
* Certain config changes to UCP make take several minutes to update after making
|
||||
changes in the web interface. In particular this affects LDAP/AD configuration changes.
|
||||
* Turning `LDAP Enabled` from "Yes" to "No" disables the save button. Workaround
|
||||
is to do a page refresh which completes the configuration change.
|
||||
* Removing stacks from the UI may cause certain resources to not be deleted,
|
||||
including networks or volumes. Workaround is to delete the resources directly.
|
||||
* When you create a network and check 'Enable hostname based routing', the web
|
||||
interface doesn't apply the HRM labels to the network. As a workaround,
|
||||
[create the network using the CLI](https://docs.docker.com/datacenter/ucp/2.2/guides/user/services/use-domain-names-to-access-services/#service-labels).
|
||||
* The web interface does not currently persist changes to session timeout settings.
|
||||
As a workaround you can update the settings from the CLI, by [adapting these instructions for the
|
||||
session timeout](https://docs.docker.com/datacenter/ucp/2.2/guides/admin/configure/external-auth/enable-ldap-config-file/).
|
||||
* docker/ucp
|
||||
* The `support` command does not currently produce a valid support dump. As a
|
||||
workaround you can download a support dumps from the web interface.
|
||||
* Compose
|
||||
* When deploying compose files that use secrets, the secret definition must include `external: true`, otherwise the deployment fails with the error.
|
||||
`unable to inspect secret`.
|
||||
* Windows issues
|
||||
* Disk related metrics do not display for Windows worker nodes.
|
||||
* If upgrading from an existing deployment, ensure that HRM is using a non-encrypted
|
||||
network prior to attaching Windows services.
|
||||
|
||||
## Version 2.2.0
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,16 @@ consistency and compatibility reasons.
|
|||
> `sudo apt install docker-ce docker-ce-cli containerd.io`. See the install instructions
|
||||
> for the corresponding linux distro for details.
|
||||
|
||||
## 18.09.3
|
||||
|
||||
2019-02-28
|
||||
|
||||
* Fixed an issue to address Windows `- restart always` flag on standalone containers not working when specifying a network. (docker/escalation#1037)
|
||||
* Fixed an issue to address the IPAM state from networkdb if manager is not attached to the overlay network. (docker/escalation#1049)
|
||||
|
||||
### Known Issues
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before 18.09 to version 18.09 or greater.
|
||||
|
||||
## 18.09.2
|
||||
|
||||
2019-02-11
|
||||
|
|
@ -39,8 +49,10 @@ consistency and compatibility reasons.
|
|||
|
||||
For additional information, [refer to the Docker blog post](https://blog.docker.com/2019/02/docker-security-update-cve-2018-5736-and-container-security-best-practices/).
|
||||
|
||||
## 18.09.1
|
||||
### Known Issues
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before 18.09 to version 18.09 or greater.
|
||||
|
||||
## 18.09.1
|
||||
|
||||
2019-01-09
|
||||
|
||||
|
|
@ -93,6 +105,7 @@ Update your configuration if this command prints a non-empty value for `MountFla
|
|||
|
||||
### Known Issues
|
||||
* When upgrading from 18.09.0 to 18.09.1, `containerd` is not upgraded to the correct version on Ubuntu. [Learn more](https://success.docker.com/article/error-upgrading-to-engine-18091-with-containerd).
|
||||
* There are [important changes to the upgrade process](/ee/upgrade) that, if not correctly followed, can have impact on the availability of applications running on the Swarm during upgrades. These constraints impact any upgrades coming from any version before 18.09 to version 18.09 or greater.
|
||||
|
||||
## 18.09.0
|
||||
|
||||
|
|
@ -239,6 +252,12 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
## Older Docker Engine EE Release notes
|
||||
|
||||
## 18.03.1-ee-7
|
||||
2019-02-28
|
||||
|
||||
### Bug fixes
|
||||
* Fixed an issue to address the IPAM state from networkdb if manager is not attached to the overlay network. (docker/escalation#1049)
|
||||
|
||||
## 18.03.1-ee-6
|
||||
2019-02-11
|
||||
|
||||
|
|
@ -325,7 +344,6 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
+ Add /proc/acpi to masked paths [(CVE-2018-10892)](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-10892). [moby/moby#37404](https://github.com/moby/moby/pull/37404)
|
||||
|
||||
|
||||
## 18.03.1-ee-1
|
||||
2018-06-27
|
||||
|
||||
|
|
@ -350,6 +368,33 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
+ Support for `--chown` with `COPY` and `ADD` in `Dockerfile`.
|
||||
+ Added functionality for the `docker logs` command to include the output of multiple logging drivers.
|
||||
|
||||
## 17.06.2-ee-20
|
||||
2019-02-28
|
||||
|
||||
### Bug fixes
|
||||
* Fixed an issue to address the IPAM state from networkdb if manager is not attached to the overlay network. (docker/escalation#1049)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-19
|
||||
|
||||
|
|
@ -359,6 +404,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
* Update `runc` to address a critical vulnerability that allows specially-crafted containers to gain administrative privileges on the host. [CVE-2019-5736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5736)
|
||||
* Ubuntu 14.04 customers using a 3.13 kernel will need to upgrade to a supported Ubuntu 4.x kernel
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-18
|
||||
2019-01-09
|
||||
|
||||
|
|
@ -372,6 +439,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
* Fix resource leak on `docker logs --follow` [moby/moby#37576](https://github.com/moby/moby/pull/37576)
|
||||
* Mask proxy credentials from URL when displayed in system info (docker/escalation#879)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-17
|
||||
2018-10-25
|
||||
|
||||
|
|
@ -391,6 +480,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
* Fixed leaking task resources. [docker/swarmkit#2755](https://github.com/docker/swarmkit/pull/2755)
|
||||
* Fixed deadlock in dispatcher that could cause node to crash. [docker/swarmkit#2753](https://github.com/docker/swarmkit/pull/2753)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-16
|
||||
2018-07-26
|
||||
|
||||
|
|
@ -417,6 +528,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
* RoleManager will remove deleted nodes from the cluster membership. [docker/swarmkit#2607](https://github.com/docker/swarmkit/pull/2607)
|
||||
- Fix unassigned task leak when service is removed. [docker/swarmkit#2708](https://github.com/docker/swarmkit/pull/2708)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-15
|
||||
2018-07-10
|
||||
|
||||
|
|
@ -424,6 +557,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
- Add /proc/acpi to masked paths [(CVE-2018-10892)](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-10892). [moby/moby#37404](https://github.com/moby/moby/pull/37404)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
### 17.06.2-ee-14
|
||||
2018-06-21
|
||||
|
||||
|
|
@ -443,6 +598,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
- Fix `docker stack deploy --prune` with empty name removes all swarm services. [moby/moby#36776](https://github.com/moby/moby/issues/36776)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-13
|
||||
2018-06-04
|
||||
|
||||
|
|
@ -450,6 +627,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
- Fix attachable containers that may leave DNS state when exiting. [docker/libnetwork#2175](https://github.com/docker/libnetwork/pull/2175)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-12
|
||||
2018-05-29
|
||||
|
||||
|
|
@ -457,6 +656,28 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
- Fix to allow service update with no connection loss. [docker/libnetwork#2157](https://github.com/docker/libnetwork/pull/2157)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-11
|
||||
2018-05-17
|
||||
|
||||
|
|
@ -481,6 +702,23 @@ Ubuntu 14.04 "Trusty Tahr" [docker-ce-packaging#255](https://github.com/docker/d
|
|||
|
||||
* When all Swarm managers are stopped at the same time, the swarm might end up in a
|
||||
split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-10
|
||||
2018-04-27
|
||||
|
|
@ -489,6 +727,26 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
|
||||
* Fix version output to not have `-dev`.
|
||||
|
||||
#### Known issues
|
||||
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-9
|
||||
2018-04-26
|
||||
|
||||
|
|
@ -503,6 +761,26 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
- Increase raft ElectionTick to 10xHeartbeatTick. [docker/swarmkit#2564](https://github.com/docker/swarmkit/pull/2564)
|
||||
- Adding logic to restore networks in order. [docker/swarmkit#2584](https://github.com/docker/swarmkit/pull/2584)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* Under certain conditions, swarm leader re-election may timeout
|
||||
prematurely. During this period, docker commands may fail. Also during
|
||||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-8
|
||||
2018-04-17
|
||||
|
||||
|
|
@ -525,6 +803,18 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
this time, creation of globally-scoped networks may be unstable. As a
|
||||
workaround, wait for leader election to complete before issuing commands
|
||||
to the cluster.
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-7
|
||||
2018-03-19
|
||||
|
|
@ -577,6 +867,21 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
- Synchronize Dispatcher.Stop() with incoming rpcs [docker/swarmkit#2524](https://github.com/docker/swarmkit/pull/2524)
|
||||
- Fix IP overlap with empty EndpointSpec [docker/swarmkit#2511](https://github.com/docker/swarmkit/pull/2511)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-6
|
||||
2017-11-27
|
||||
|
||||
|
|
@ -594,6 +899,21 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
* Only shut down old tasks on success [docker/swarmkit#2308](https://github.com/docker/swarmkit/pull/2308)
|
||||
* Error on cluster spec name change [docker/swarmkit#2436](https://github.com/docker/swarmkit/pull/2436)
|
||||
|
||||
#### Known issues
|
||||
|
||||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-5
|
||||
2017-11-02
|
||||
|
||||
|
|
@ -643,6 +963,15 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
* It's recommended that users create overlay networks with `/24` blocks (the default) of 256 IP addresses when networks are used by services created using VIP-based endpoint-mode (the default). This is because of limitations with Docker Swarm [moby/moby#30820](moby/moby/issues/30820). Users should _not_ work around this by increasing the IP block size. To work around this limitation, either use `dnsrr` endpoint-mode or use multiple smaller overlay networks.
|
||||
* Docker may experience IP exhaustion if many tasks are assigned to a single overlay network, for example if many services are attached to that network or because services on the network are scaled to many replicas. The problem may also manifest when tasks are rescheduled because of node failures. In case of node failure, Docker currently waits 24h to release overlay IP addresses. The problem can be diagnosed by looking for `failed to allocate network IP for task` messages in the Docker logs.
|
||||
* SELinux enablement is not supported for containers on IBM Z on RHEL because of missing Red Hat package.
|
||||
* If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-4
|
||||
2017-10-12
|
||||
|
|
@ -662,6 +991,17 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
* Overlay fix for transient IP reuse [docker/libnetwork#1935](https://github.com/docker/libnetwork/pull/1935) [docker/libnetwork#1968](https://github.com/docker/libnetwork/pull/1968)
|
||||
* Serialize IP allocation [docker/libnetwork#1788](https://github.com/docker/libnetwork/pull/1788)
|
||||
|
||||
#### Known issues
|
||||
|
||||
If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.2-ee-3
|
||||
2017-09-22
|
||||
|
|
@ -670,6 +1010,18 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
|
||||
- Increase max message size to allow larger snapshots [docker/swarmkit#131](https://github.com/docker/swarmkit/pull/131)
|
||||
|
||||
#### Known issues
|
||||
|
||||
If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.1-ee-2
|
||||
2017-08-24
|
||||
|
||||
|
|
@ -690,6 +1042,18 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
|
||||
- Ignore PullOptions for running tasks [#2351](https://github.com/docker/swarmkit/pull/2351)
|
||||
|
||||
#### Known issues
|
||||
|
||||
If a container is spawned on node A, using the same IP of a container destroyed
|
||||
on nodeB within 5 min from the time that it exit, the container on node A is
|
||||
not reachable until one of these 2 conditions happens:
|
||||
|
||||
1. Container on A sends a packet out,
|
||||
2. The timer that cleans the arp entry in the overlay namespace is triggered (around 5 minutes).
|
||||
|
||||
As a workaround, send at least a packet out from each container like
|
||||
(ping, GARP, etc).
|
||||
|
||||
## 17.06.1-ee-1
|
||||
2017-08-16
|
||||
|
||||
|
|
@ -707,7 +1071,6 @@ split-brain scenario. [Learn more](https://success.docker.com/article/KB000759).
|
|||
migrated to the v2 protocol, set the `--disable-legacy-registry=false` daemon
|
||||
option.
|
||||
|
||||
|
||||
#### Builder
|
||||
|
||||
+ Add `--iidfile` option to docker build. It allows specifying a location where to save the resulting image ID
|
||||
|
|
@ -1452,6 +1815,11 @@ Initial Docker EE release, based on Docker CE 17.03.0
|
|||
#### Swarm
|
||||
* Remove watchMiss from swarm mode [docker/libnetwork#2047](https://github.com/docker/libnetwork/pull/2047)
|
||||
|
||||
#### Known Issues
|
||||
* Health check no longer uses the container's working directory [moby/moby#35843](https://github.com/moby/moby/issues/35843)
|
||||
* Errors not returned from client in stack deploy configs [moby/moby#757](https://github.com/docker/cli/pull/757)
|
||||
* Docker cannot use memory limit when using systemd options [moby/moby#35123](https://github.com/moby/moby/issues/35123)
|
||||
|
||||
## 17.12.0-ce
|
||||
2017-12-27
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue