Incorrectly nesting routes under virtualhost is considered valid

[erwbgy]

What steps did you take and what happened:
If routes is incorrectly nested under virtualhost the HTTPProxy object is still considered valid, but all calls just return 404 Not Found:

$ cat bad-explorer-httpproxy.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  annotations:
    heptio.contour.com/ingress.class: contour
  name: explorer
  namespace: burdik
spec:
  virtualhost:
    fqdn: explorer.my.domain
    routes:
    - services:
      - name: explorer
        port: 8080
$ kubectl create -f bad-explorer-httpproxy.yaml
httpproxy.projectcontour.io/explorer created
$ kubectl get httpproxy
NAME                    FQDN                                  TLS SECRET     STATUS   STATUS DESCRIPTION
explorer                explorer.my.domain                                   valid    valid HTTPProxy
$ curl -I explorer.my.domain
HTTP/1.1 404 Not Found
date: Fri, 15 May 2020 16:55:28 GMT
server: envoy
transfer-encoding: chunked

What did you expect to happen:

I expected that the HTTPProxy status would be invalid because routes is not allowed under virtualhost.

Anything else you would like to add:
With the indentation fixed the call works fine:

$ cat explorer-httpproxy.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  annotations:
    heptio.contour.com/ingress.class: contour
  name: explorer
  namespace: burdik
spec:
  virtualhost:
    fqdn: explorer.my.domain
  routes:
  - services:
    - name: explorer
      port: 8080
$ kubectl replace -f explorer-httpproxy.yaml
httpproxy.projectcontour.io/explorer replaced
$ curl -I explorer.my.domain
HTTP/1.1 200 OK
date: Fri, 15 May 2020 16:56:46 GMT
content-length: 446
content-type: text/html; charset=utf-8
x-envoy-upstream-service-time: 0
server: envoy

Environment:

• Contour version: 1.4.0
• Kubernetes version: v1.16.9
• Kubernetes installer & version: kubeadm v1.16.9
• Cloud provider or hardware configuration: on-prem
• OS (e.g. from /etc/os-release): RHEL 8.1

[stevesloka]

Hey @erwbgy I think what happened is since the yaml wasn't nested properly, it didn't get parsed correctly when Contour got the object, so in a sense, those invalid fields were just missing from the spec.

But what should have ended up is that you had a root proxy with no routes and I think that should be at least invalid (which I thought was already a test case). Let me look to see about that one.

[youngnick]

Hopefully once we can move to CRD v1, this problem will disappear, as incorrect YAML will be rejected by the apiserver. Agreed that a proxy with no routes should be invalid.

[jpeach]

Blocked by #2678