From b0ee74361ac00babaf38f0727084572f42589bf0 Mon Sep 17 00:00:00 2001 From: ddeyo Date: Wed, 26 Sep 2018 09:19:18 -0700 Subject: [PATCH] API issues edited --- 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 5ae3f2bf28..7e5231f73d 100644 --- a/ee/ucp/release-notes.md +++ b/ee/ucp/release-notes.md @@ -38,7 +38,7 @@ upgrade your installation to the latest release. * 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 * Change node.alpha.kubernetes.io/unreachable to node.kubernetes.io/unreachable -* JSON configuration files (i.e. JSON files that you use with `kubectl create -f pod.json`) that contain fields with incorrect casing will no longer be 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 and the API server will once again be enforcing the correct case. 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. +* 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 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. # Version 3.0