Validation is not failing for an invalid components

[csrwng]

The invalid configuration results in a build that can't be run. However, it should be caught before the BuildConfig is accepted.

[TomasTomecek]

buildConfig (env variable is defined incorrectly)

{
  "metadata":{
    "name": "test-os-build",
  }, 
  "kind": "Template",
  "apiVersion": "v1beta1",
  "description": "description or something",
  "parameters": [],
  "items": [
    {
      "metadata":{
        "name": "the-build2",
      },
      "kind": "BuildConfig",
      "apiVersion": "v1beta1",
      "triggers": [],
      "parameters": {
        "source" : {
          "type" : "Git",
          "git" : {
            "uri": "https://github.com/TomasTomecek/docker-hello-world.git"
          }
        },
        "strategy": {
          "type": "Custom",
          "customStrategy": {
            "image": "dh",
            "exposeDockerSocket": true,
            "env": [{
              "VARIABLE": {"whatever": "asd"}
            }]
          }
        },
        "output": {
          "imageTag": "built-image",
          "registry": "172.17.42.1:5000"
        },
      },
      "labels": {
        "name": "some-label"
      }
    }
  ]
}

Steps

$ o process -f wrong-build.json | o apply -f -
I0109 08:53:52.154938   19252 apply.go:59] Creation succeeded for BuildConfig with name the-build2

$ o start-build the-build2
f5e16698-9806-11e4-9911-fa163ed7ae77

$ o build-logs f5e16698-9806-11e4-9911-fa163ed7ae77
{
  "kind": "Status",
  "creationTimestamp": null,
  "apiVersion": "v1beta1",
  "status": "Failure",
  "message": "No such pod: pod \"build-f5e16698-9806-11e4-9911-fa163ed7ae77\" not found",
  "code": 500
}

[smarterclayton]

This is hard because of the existing JSON parser in golang (which runs in forgiving / drop-unrecognized fields mode). We need to track this in Kube, figure out a story, then implement it.

[smarterclayton]

It's important too to distinguish between fields that don't have the format we expect (which should be an error) vs fields that we don't recognize at all, which we must ignore.

[smarterclayton]

This is tracked by upstream kubernetes/kubernetes#3338