From cd8dba45e18622b6516551287d49a379dd8ca1fb Mon Sep 17 00:00:00 2001 From: ddeyo Date: Wed, 31 Oct 2018 20:37:34 -0700 Subject: [PATCH 1/8] changelog for 3.1 incorporated --- ee/ucp/release-notes.md | 57 ++++++++++++++++++++++++++++------------- 1 file changed, 39 insertions(+), 18 deletions(-) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index b62c629163..bf2093d3ba 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -23,18 +23,39 @@ upgrade your installation to the latest release. ## 3.1.0 (2018-11-8) -**New Features** -* Default address pool for Swarm is now user configurable -* UCP now supports Kubernetes Network Encryption using IPSec -* UCP now supports Kubernetes v1.11 -* UCP now supports Kubernetes native role-based access control -* UCP now provides service metrics for all API calls, using Prometheus deployed as Kubernetes Daemon Set -* UCP now supports use of an external Prometheus instance to scrape metrics from UPC endpoints -* UCP supports SAML authentication -* DTR vulnerability scan data is now available through the UCP web interface +## New Features + +### Kubernetes + +* Kubernetes is updated to version 1.11.2. +* Access control for Kubernetes resources is now handled by the Kubernetes RBAC feature. Users can now create roles for Kubernetes APIs using Kubernetes `Role` and `ClusterRole` objects in the Kubernetes API. They can also grant permissions to users and service accounts with the `RoleBinding` and `ClusterRoleBinding` objects. The web interface for Kubernetes RBAC reflects these changes. + +### Logging + +Admins can now enable audit logging in the UCP config. This logs all incoming user-initiated requests in the `ucp-controller` logs. Admins can choose whether to log only metadata for incoming requests or the full request body as well. + +### Authentication + +* Admins can configure UCP to use a SAML-enabled identity provider for user authentication. If enabled, users who log into the UCP web interface are redirected to the identity provider's website to log in. Upon log in, users are redirected back to the UCP web interface, authenticated as the user chosen. + +### Metrics + +* The `ucp-metrics` Prometheus server (used to render charts in the UCP interface) has been engineered from a container on manager nodes to a Kubernetes daemonset. This lets admins change the daemonset's scheduling rules so that it runs on a set of worker nodes instead of manager nodes. Admins can designate certain UCP nodes to be metrics server nodes, freeing up resources on manager nodes. +* A `/metricsdiscovery` endpoint is added to the UCP controller so users can connect their own Prometheus instances to scrape UCP metrics data. + +### UCP web interface + +* If you enable single sign-on for a DTR instance with UCP, the UCP web interface shows image vulnerability data for images in that DTR instance. Containers, services, etc. that use images from that DTR instance show any vulnerabilities DTR detects. +* The UCP web interface is redesigned to offer larger views for viewing individual resources, with more information for Kubernetes resources. + +### Configs + +* UCP now stores its configs in its internal key-value store instead of in a Swarm config to allow config changes to propagate across the cluster more quickly. + +## API updates + +There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are: -**API updates** -* There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are: * A compatibility issue with the `allowPrivilegeEscalation` field that caused policies to start denying pods they previously allowed was fixed. If you defined `PodSecurityPolicy` objects using a 1.8.0 client or server and set `allowPrivilegeEscalation` to false, these objects must be reapplied after you upgrade. * These changes are automatically updated for taints. Tolerations for these taints must be updated manually. Specifically, you must: * Change `node.alpha.kubernetes.io/notReady` to `node.kubernetes.io/not-ready` @@ -44,14 +65,14 @@ upgrade your installation to the latest release. * JSON configuration used with `kubectl create -f pod.json` containing fields with incorrect casing are no longer valid. You must correct these files before upgrading. When specifying keys in JSON resource definitions during direct API server communication, the keys are case-sensitive. A bug introduced in Kubernetes 1.8 caused the API server to accept a request with incorrect case and coerce it to correct case, but this behaviour has been fixed in 1.11 so the API server will again enforce correct casing. During this time, the `kubectl` tool continued to enforce case-sensitive keys, so users that strictly manage resources with `kubectl` will be unaffected by this change. * If you have a pod with a subpath volume PVC, there’s a chance that after the upgrade, it will conflict with some other pod; see [this pull request](https://github.com/kubernetes/kubernetes/pull/61373). It’s not clear if this issue will just prevent those pods from starting or if the whole cluster will fail. -**Known issues** -* You must use the ID of the user, organization, or team if you are manually creating a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. - * For the `User` subject Kind, the `Name` field should be the ID of the user. - * For the `Group` subject Kind, the format depends on whether you are creating a Binding for a team or an organization: +## Known issues +* You must use the ID of the user, organization, or team if you manually create a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. (#14935) + * For the `User` subject Kind, the `Name` field contains the ID of the user. + * For the `Group` subject Kind, the format depends on whether you are create a Binding for a team or an organization: * For an organization, the format is `org:{org-id}` * For a team, the format is `team:{org-id}:{team-id}` -* In order to deploy Pods with containers using Restricted Parameters, a user must be an admin and a service account must explicitly have a **ClusterRoleBinding** with `cluster-admin` as the **ClusterRole**. Restricted Parameters on Containers include: +* To deploy Pods with containers using Restricted Parameters, the user must be an admin and a service account must explicitly have a **ClusterRoleBinding** with `cluster-admin` as the **ClusterRole**. Restricted Parameters on Containers include: * Host Bind Mounts * Privileged Mode * Extra Capabilities @@ -59,9 +80,9 @@ upgrade your installation to the latest release. * Host IPC * Host PID -* If you delete the built-in **ClusterRole** or **ClusterRoleBinding** for `cluster-admin`, restart the `ucp-kube-apiserver` container on any manager node to recreate them. +* If you delete the built-in **ClusterRole** or **ClusterRoleBinding** for `cluster-admin`, restart the `ucp-kube-apiserver` container on any manager node to recreate them. (#14483) -**Deprecated features** +## Deprecated features The following features are deprecated in UCP 3.1 From f2d0e1fb3f2fb14061a8a02dc8216fc7f9c057d6 Mon Sep 17 00:00:00 2001 From: ddeyo Date: Wed, 31 Oct 2018 20:41:52 -0700 Subject: [PATCH 2/8] edits --- ee/ucp/release-notes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index bf2093d3ba..3a3f2bf098 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -54,7 +54,7 @@ Admins can now enable audit logging in the UCP config. This logs all incoming us ## API updates -There are several backwards-incompatible changes in the Kube API that may affect user workloads. They are: +There are several backward-incompatible changes in the Kubernetes API that may affect user workloads. They are: * A compatibility issue with the `allowPrivilegeEscalation` field that caused policies to start denying pods they previously allowed was fixed. If you defined `PodSecurityPolicy` objects using a 1.8.0 client or server and set `allowPrivilegeEscalation` to false, these objects must be reapplied after you upgrade. * These changes are automatically updated for taints. Tolerations for these taints must be updated manually. Specifically, you must: From bb84913b17828e22d516e36004dcdc06a9c50fed Mon Sep 17 00:00:00 2001 From: ddeyo Date: Thu, 1 Nov 2018 11:19:43 -0700 Subject: [PATCH 3/8] peer review and eng changes made --- ee/ucp/release-notes.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index 3a3f2bf098..b071533301 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -23,24 +23,33 @@ upgrade your installation to the latest release. ## 3.1.0 (2018-11-8) +## Bug Fixes + +* Swarm placement constraint warning banner no longer shows up for `ucp-auth` services (#14539) +* "update out of sequence" error messages no longer appear when changing admin settings (#7093) +* Kubernetes namespace status appears in the web interface (#14526) +* UCP Kubernetes compose components always run on managers (#14208) +* `docker network ls --filter id=` now works with a UCP client bundle (#14840) +* Collection deletes are correctly blocked if there is a node in the collection (#13704) + ## New Features ### Kubernetes * Kubernetes is updated to version 1.11.2. -* Access control for Kubernetes resources is now handled by the Kubernetes RBAC feature. Users can now create roles for Kubernetes APIs using Kubernetes `Role` and `ClusterRole` objects in the Kubernetes API. They can also grant permissions to users and service accounts with the `RoleBinding` and `ClusterRoleBinding` objects. The web interface for Kubernetes RBAC reflects these changes. +* Kubernetes native RBAC feature manages access control for Kubernetes resources. Users can now create roles for Kubernetes APIs using Kubernetes `Role` and `ClusterRole` objects in the Kubernetes API. They can also grant permissions to users and service accounts with the `RoleBinding` and `ClusterRoleBinding` objects. The web interface for Kubernetes RBAC reflects these changes. ### Logging -Admins can now enable audit logging in the UCP config. This logs all incoming user-initiated requests in the `ucp-controller` logs. Admins can choose whether to log only metadata for incoming requests or the full request body as well. +Admins can now enable audit logging in the UCP config. This logs all incoming user-initiated requests in the `ucp-controller` logs. Admins can choose whether to log only metadata for incoming requests or the full request body as well. For more information, see [Create UCP audit logs](https://docs.docker.com/ee/ucp/admin/configure/create-audit-logs/). ### Authentication -* Admins can configure UCP to use a SAML-enabled identity provider for user authentication. If enabled, users who log into the UCP web interface are redirected to the identity provider's website to log in. Upon log in, users are redirected back to the UCP web interface, authenticated as the user chosen. +Admins can configure UCP to use a SAML-enabled identity provider for user authentication. If enabled, users who log into the UCP web interface are redirected to the identity provider's website to log in. Upon log in, users are redirected back to the UCP web interface, authenticated as the user chosen. For more information, see [Enable SAML authentication](https://docs.docker.com/ee/ucp/admin/configure/enable-saml-authentication/). ### Metrics -* The `ucp-metrics` Prometheus server (used to render charts in the UCP interface) has been engineered from a container on manager nodes to a Kubernetes daemonset. This lets admins change the daemonset's scheduling rules so that it runs on a set of worker nodes instead of manager nodes. Admins can designate certain UCP nodes to be metrics server nodes, freeing up resources on manager nodes. +* The `ucp-metrics` Prometheus server (used to render charts in the UCP interface) has been engineered from a container on manager nodes to a Kubernetes daemonset. This lets admins change the daemonset's scheduling rules so that it runs on a set of worker nodes instead of manager nodes. Admins can designate certain UCP nodes to be metrics server nodes, freeing up resources on manager nodes. For more information, see [Collect UCP cluster metrics with Prometheus](https://docs.docker.com/ee/ucp/admin/configure/collect-cluster-metrics/). * A `/metricsdiscovery` endpoint is added to the UCP controller so users can connect their own Prometheus instances to scrape UCP metrics data. ### UCP web interface @@ -50,7 +59,7 @@ Admins can now enable audit logging in the UCP config. This logs all incoming us ### Configs -* UCP now stores its configs in its internal key-value store instead of in a Swarm config to allow config changes to propagate across the cluster more quickly. +* UCP now stores its configurations in its internal key-value store instead of in a Swarm configuration so changes can propagate across the cluster more quickly. ## API updates From 502e674f1327aa5e7f81688ee288e0da43a6b047 Mon Sep 17 00:00:00 2001 From: ddeyo Date: Thu, 1 Nov 2018 11:33:09 -0700 Subject: [PATCH 4/8] more edits --- ee/ucp/release-notes.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index b071533301..d858c6e9e4 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -49,8 +49,8 @@ Admins can configure UCP to use a SAML-enabled identity provider for user authen ### Metrics -* The `ucp-metrics` Prometheus server (used to render charts in the UCP interface) has been engineered from a container on manager nodes to a Kubernetes daemonset. This lets admins change the daemonset's scheduling rules so that it runs on a set of worker nodes instead of manager nodes. Admins can designate certain UCP nodes to be metrics server nodes, freeing up resources on manager nodes. For more information, see [Collect UCP cluster metrics with Prometheus](https://docs.docker.com/ee/ucp/admin/configure/collect-cluster-metrics/). -* A `/metricsdiscovery` endpoint is added to the UCP controller so users can connect their own Prometheus instances to scrape UCP metrics data. +* The `ucp-metrics` Prometheus server (used to render charts in the UCP interface) was engineered from a container on manager nodes to a Kubernetes daemonset. This lets admins change the daemonset's scheduling rules so that it runs on a set of worker nodes instead of manager nodes. Admins can designate certain UCP nodes to be metrics server nodes, freeing up resources on manager nodes. For more information, see [Collect UCP cluster metrics with Prometheus](https://docs.docker.com/ee/ucp/admin/configure/collect-cluster-metrics/). +* The UCP controller has a `/metricsdiscovery` endpoint so users can connect their own Prometheus instances to scrape UCP metrics data. ### UCP web interface From fe8a830dc708f8d6021fe1be9bb68bfa7ebdaa0f Mon Sep 17 00:00:00 2001 From: ddeyo Date: Thu, 1 Nov 2018 14:47:11 -0700 Subject: [PATCH 5/8] engine upgrade known issue added --- ee/ucp/release-notes.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index d858c6e9e4..58dee7a06c 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -75,6 +75,8 @@ There are several backward-incompatible changes in the Kubernetes API that may a * If you have a pod with a subpath volume PVC, there’s a chance that after the upgrade, it will conflict with some other pod; see [this pull request](https://github.com/kubernetes/kubernetes/pull/61373). It’s not clear if this issue will just prevent those pods from starting or if the whole cluster will fail. ## Known issues +* There are important changes to the upgrade process that, if not correctly followed, can impact the availability of applications running on the Swarm during uprades. These constraints impact any upgrades coming from any Docker Engine version before 18.09 to version 18.09 or greater. For more information about about upgrading Docker Enterprise to version 2.1, see [Upgrade Docker](../upgrade) + * You must use the ID of the user, organization, or team if you manually create a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. (#14935) * For the `User` subject Kind, the `Name` field contains the ID of the user. * For the `Group` subject Kind, the format depends on whether you are create a Binding for a team or an organization: From 02ab1ec89151222c8203dbf7655ed8c29cb8a270 Mon Sep 17 00:00:00 2001 From: ddeyo Date: Fri, 2 Nov 2018 11:38:02 -0700 Subject: [PATCH 6/8] LDAP disappearing settins added to known issues --- ee/ucp/release-notes.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index 58dee7a06c..12c2d61770 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -77,6 +77,8 @@ There are several backward-incompatible changes in the Kubernetes API that may a ## Known issues * There are important changes to the upgrade process that, if not correctly followed, can impact the availability of applications running on the Swarm during uprades. These constraints impact any upgrades coming from any Docker Engine version before 18.09 to version 18.09 or greater. For more information about about upgrading Docker Enterprise to version 2.1, see [Upgrade Docker](../upgrade) +* In the UCP web interface, LDAP settings disappear after submitting them. However, the sattings are properly saved. (#15503) + * You must use the ID of the user, organization, or team if you manually create a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. (#14935) * For the `User` subject Kind, the `Name` field contains the ID of the user. * For the `Group` subject Kind, the format depends on whether you are create a Binding for a team or an organization: From 35a4934a85da71a8cb736b7a4914b3f3e1416f3d Mon Sep 17 00:00:00 2001 From: David Deyo Date: Fri, 2 Nov 2018 13:30:58 -0700 Subject: [PATCH 7/8] Update release-notes.md --- ee/ucp/release-notes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index 12c2d61770..068507c848 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -77,7 +77,7 @@ There are several backward-incompatible changes in the Kubernetes API that may a ## Known issues * There are important changes to the upgrade process that, if not correctly followed, can impact the availability of applications running on the Swarm during uprades. These constraints impact any upgrades coming from any Docker Engine version before 18.09 to version 18.09 or greater. For more information about about upgrading Docker Enterprise to version 2.1, see [Upgrade Docker](../upgrade) -* In the UCP web interface, LDAP settings disappear after submitting them. However, the sattings are properly saved. (#15503) +* In the UCP web interface, LDAP settings disappear after submitting them. However, the settings are properly saved. (#15503) * You must use the ID of the user, organization, or team if you manually create a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. (#14935) * For the `User` subject Kind, the `Name` field contains the ID of the user. From 2e36f4787268e3dc90fcc86805940e5d7ee68d12 Mon Sep 17 00:00:00 2001 From: ddeyo Date: Fri, 2 Nov 2018 14:17:59 -0700 Subject: [PATCH 8/8] deprecated features updated --- ee/ucp/release-notes.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/ee/ucp/release-notes.md b/ee/ucp/release-notes.md index 12c2d61770..80e3c1c071 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -21,7 +21,7 @@ upgrade your installation to the latest release. # Version 3.1 -## 3.1.0 (2018-11-8) +## 3.1.0 (2018-11-08) ## Bug Fixes @@ -54,7 +54,7 @@ Admins can configure UCP to use a SAML-enabled identity provider for user authen ### UCP web interface -* If you enable single sign-on for a DTR instance with UCP, the UCP web interface shows image vulnerability data for images in that DTR instance. Containers, services, etc. that use images from that DTR instance show any vulnerabilities DTR detects. +* If you enable single sign-on for a DTR instance with UCP, the UCP web interface shows image vulnerability data for images in that DTR instance. Containers and services that use images from that DTR instance show any vulnerabilities DTR detects. * The UCP web interface is redesigned to offer larger views for viewing individual resources, with more information for Kubernetes resources. ### Configs @@ -77,7 +77,7 @@ There are several backward-incompatible changes in the Kubernetes API that may a ## Known issues * There are important changes to the upgrade process that, if not correctly followed, can impact the availability of applications running on the Swarm during uprades. These constraints impact any upgrades coming from any Docker Engine version before 18.09 to version 18.09 or greater. For more information about about upgrading Docker Enterprise to version 2.1, see [Upgrade Docker](../upgrade) -* In the UCP web interface, LDAP settings disappear after submitting them. However, the sattings are properly saved. (#15503) +* In the UCP web interface, LDAP settings disappear after submitting them. However, the settings are properly saved. (#15503) * You must use the ID of the user, organization, or team if you manually create a **ClusterRoleBinding** or **RoleBinding** for `User` or `Group` subjects. (#14935) * For the `User` subject Kind, the `Name` field contains the ID of the user. @@ -100,7 +100,8 @@ There are several backward-incompatible changes in the Kubernetes API that may a The following features are deprecated in UCP 3.1 * Collections - * Nested collections are deprecated and will be removed in future versions of the product. Customers should use non-nested collections going forward. + * User-created nested collections more than 2 layers deep within the root `/Swarm/` collection are deprecated and will be removed in future versions of the product. In the future, we recommend that at most only two levels of collections be created within UCP under the shared Cluster collection designated as `/Swarm/`. For example, if a production collection is created as a collection under the cluster collection `/Swarm/` as `/Swarm/production/` then at most one level of nestedness should be created, as in `/Swarm/production/app/`. + * Kubernetes * **PersistentVolumeLabel** admission controller is deprecated in Kubernetes 1.11. This functionality will be migrated to Cloud Controller Manager [https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/) * `--cni-install-url` is deprecated in favor of `--unmanaged-cni`