Change:
"aggregator.go", "certs.go", "chunking.go", <ins> "crd_watch.go", </ins> "custom_resource_definition.go", "etcd_failure.go", "framework.go",

Discussion:
I am suspicious that CRD watch is not working, but was unable to find e2e test coverage to persuade myself that it is working. cf .
(in particular, I'm looking for the update tests.)
I think this was due to enabling protobuf, though it also failed in a curl for me, so something strange is happening. (Maybe we have to explicitly ask for json?)
We test CRD watch in and in , but not in . I agree we should add e2e tests as a requirement before GA, and also for the sake of defining conformance.
/area custom-resources
Are we talking about CRD or CR watch and protobuf? The later with protobuf obviously does not work, as commented.
I'm not sure "obviously" is correct - list works, for example. IIRC watch with protobuf just silently fails to do anything - it doesn't return an error. And yes I mean CR watch :-)
it should obviously not work with protobuf, but in the sense that the negotiating serializer switches to JSON if you offer it json and protobuf as alternatives. This seems to be broken.
/cc
I'd like to take this up. I'm familiarising myself with the apiextension code base, please give me some time to come up with a PR :)
We already have integration tests for this. Is an e2e test really needed?
I think we do need an e2e test for CRD watch (among other things) as a requirement for CRD going GA. The most pressing need is to define conformance (which only e2e tests can do). Currently we only test that you can create and delete a CRD, but we don't test that you can actually do anything with it: We should expand the conformance (e2e) test for CRD to include checking that the custom resource gets installed and is usable, including watches. If not for conformance, I think an e2e test for CRD watch would still be appropriate since it's an important end-user flow (a thing we expect users to do on purpose; not an edge case). For example, the apiextensions-apiserver integration test might miss problems that come from embedding into kube-apiserver. Similarly, the kubectl tests are meant to test kubectl client functionality, not to protect against regressions on the server side.

Someone might reasonably change those tests in a way that suits kubectl, without realizing that doing so could leave some server code untested at the e2e level. We also need the e2e test to make sure we honor the guarantees of the raw API, to ensure clients other than kubectl will work.
For our developer purpose I would say that e2e tests are not needed when integration tests are in-place. We can even test with a real kube-apiserver including embdded into kube-apiserver if we want that. With conformance tests might have a point. Though I wonder where the line is between e2e and features we test in integration or unit tests only. We don't test all behaviour in e2e today, by far.
Since this has the help-wanted label, adding some useful info for new contributors to get started: About CRDs: If you are new to the Kubernetes API in general, I'd recommend reading the first. CustomResourceDefinition (CRD) is a way to extend the Kubernetes API. You can read more about it here: If you'd like to do some additional reading about this, I had written something up during the time I did GSoC (shamless plug): About testing: There are lots of integration tests for CRDs and you can get a general idea about testing for CRDs and apiextensions-apiserver in general. There is for CRDs. You can use this and other e2e tests to understand how to write them. contains useful information about how you can run tests. gives general info about e2e tests and mentions tests about writing good e2e tests. Also, you can ping me on Slack (I am there) if you have further questions or need help! :)