Change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When deploying a Manifest that is compatible with 1.11.3 against a newly provisioned 1.12.0-rc2 cluster, older manifests no longer worked. 2018-10-11T01:00:01.3680048Z error: error validating: error validating data: field [0].securityContext.procMount for v1.SecurityContext is required; if you choose to ignore these errors, turn validation off with --validate=false What you expected to happen: 11.3 compatible manifests should work against How to reproduce it (as minimally and precisely as possible): kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: traefik-ingress-controller namespace: kube-system labels: k8s-app: traefik-ingress-lb spec: template: metadata: labels: k8s-app: traefik-ingress-lb name: traefik-ingress-lb spec: serviceAccountName: traefik-ingress-controller terminationGracePeriodSeconds: 60 containers: image: traefik name: traefik-ingress-lb ports: name: http containerPort: 80 hostPort: 5001 name: admin containerPort: 8080 securityContext: capabilities: drop: ALL add: NETBINDSERVICE args: --api --kubernetes --logLevel=INFO Anything else we need to know?: Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.9", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-29T01:07:01Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64" kubectl delivered by VSTS Build. 2018-10-11T00:59:54.7599385Z ##[section]Starting: Deploy Traefik Ingress 2018-10-11T00:59:54.7604992Z ============================================================================== 2018-10-11T00:59:54.7606132Z Task : Deploy to Kubernetes 2018-10-11T00:59:54.7606242Z Description : Deploy, configure, update your Kubernetes cluster in Azure Container Service by running kubectl commands. 2018-10-11T00:59:54.7606322Z Version : 0.1.31 2018-10-11T00:59:54.7606416Z Author : Microsoft Corporation 2018-10-11T00:59:54.7606512Z Help : 2018-10-11T00:59:54.7606590Z ============================================================================== Cloud provider or hardware configuration: ACS-Engine 0.22.4. Windows 1803.
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
My expectation would be that this would default to "securityContext.procMount: default" - This appears to be related to . I notice that you've put this behind a feature gate. I'll admit that I'm relatively new to Kubernetes. My expectation would be that new fields would default - but is there some convention that says for features of a certain size, or of a certain complexity, we default them to on, and then force backwards compatibility via feature disable? It's not my intent to buck standard approach here.
What is it defaulting to for you now? It should default to default.
It's not defaulting at all. In the presence of this older manifest definition: securityContext: capabilities: drop: ALL add: NETBINDSERVICE args: --api --kubernetes --logLevel=INFO It's yelling at me that procMount is required. 2018-10-11T01:00:01.3680048Z error: error validating: error validating data: field [0].securityContext.procMount for v1.SecurityContext is required; if you choose to ignore these errors, turn validation off with --validate=false
ah ok I will do a fix
I'm also getting this error for the with K8s 1.12. It's not clear from this thread what I need to do to fix this. Can anyone make a suggestion? cc

Discussion:
"v1.SecurityContext": { "id": "v1.SecurityContext", "description": "SecurityContext holds security configuration that will be applied to a container. Some fields are present in both SecurityContext and PodSecurityContext.  When both are set, the values in SecurityContext take precedence.", <del> "required": [ "procMount" ], </del> "properties": { "capabilities": { "$ref": "v1.Capabilities",

<tr> <td class="tableblock halign-left valign-top"><p class="tableblock">procMount</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">procMount denotes the type of proc mount to use for the containers. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. This requires the ProcMountType feature flag to be enabled.</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock"><a href="#_v1_procmounttype">v1.ProcMountType</a></p></td> <td class="tableblock halign-left valign-top"></td> </tr>

// readonly paths and masked paths. // This requires the ProcMountType feature flag to be enabled. // +optional <del> ProcMount *ProcMountType `json:"procMount,omitEmpty" protobuf:"bytes,9,opt,name=procMount"` </del> <ins> ProcMount *ProcMountType `json:"procMount,omitempty" protobuf:"bytes,9,opt,name=procMount"` </ins> } type ProcMountType string