sample-apiserver returns "$type does not implement the protobuf marshalling interface and cannot be encoded to a protobuf message" error instead of falling back to second Accept type

[liggitt]

What happened:
Creating an example object against the sample-apiserver returns the following error with a default client:

test/e2e/framework/framework.go:639
Dec 13 01:57:24.796: creating a new flunders resource
Unexpected error:
    <*errors.StatusError | 0xc0011a4aa0>: {
        ErrStatus: {
            TypeMeta: {Kind: "", APIVersion: ""},
            ListMeta: {
                SelfLink: "",
                ResourceVersion: "",
                Continue: "",
                RemainingItemCount: nil,
            },
            Status: "Failure",
            Message: "object *v1alpha1.Flunder does not implement the protobuf marshalling interface and cannot be encoded to a protobuf message",
            Reason: "NotAcceptable",
            Details: nil,
            Code: 406,
        },
    }
    object *v1alpha1.Flunder does not implement the protobuf marshalling interface and cannot be encoded to a protobuf message
occurred
test/e2e/apimachinery/aggregator.go:396

What you expected to happen:
The sample-apiserver would fall back to encoding the object in json

How to reproduce it (as minimally and precisely as possible):

• Define a type that does not support protobuf
• Create a client that accepts protobuf,json
• Use that client to submit an object to the server

Anything else we need to know?:
Seen in a PR attempting to update the sample-apiserver used in e2e to 1.17.0 levels (#84735, https://prow.k8s.io/view/gcs/kubernetes-jenkins/pr-logs/pull/84735/pull-kubernetes-e2e-kind/1205296180716638211)

/sig api-machinery
/assign @smarterclayton

[tedyu]

In TestWatchNonDefaultContentType, there is test for falling back to JSON serialization:

+       // set the default content type to protobuf so that we test falling back to JSON serialization
+       contentConfig := defaultContentConfig()
+       contentConfig.ContentType = "application/vnd.kubernetes.protobuf"

[liggitt]

In TestWatchNonDefaultContentType, there is test for falling back to JSON serialization:

That's testing client-side fallback. This bug is about a server serving a type which cannot be serialized using protobuf.

[liggitt]

I set up a simple addition to the sample-apiserver integration test to exercise this:

       flunder := `{"apiVersion":"wardle.k8s.io/v1alpha1","kind":"Flunder","metadata":{"labels":{"sample-label":"true"},"name":"abc","namespace":"default"}}`
       result := wardleClient.Discovery().RESTClient().Post().
               AbsPath("/apis/wardle.k8s.io/v1alpha1/namespaces/default/flunders").
               Body([]byte(flunder)).
               SetHeader("Content-Type", "application/json").
               SetHeader("Accept", "application/vnd.kubernetes.protobuf,application/json").
               Do()
       if err := result.Error(); err != nil {
               t.Fatal(err)
       }

Tested this across all releases since the working 1.10 API server:

• 1.10: returns 200 with "cannot encode to protobuf" error
• 1.11: returns 200 with "cannot encode to protobuf" error
• 1.12: returns 406 with "cannot encode to protobuf" error
• 1.13: returns 406 with "cannot encode to protobuf" error
• 1.14: returns 406 with "cannot encode to protobuf" error
• 1.15: returns 406 with "cannot encode to protobuf" error
• 1.16: returns 406 with "cannot encode to protobuf" error
• 1.17: returns 406 with "cannot encode to protobuf" error

[liggitt]

digging further, 1.10 and 1.11 did not actually succeed, but returned 200 responses containing status errors (issue reported in #50342, fixed in #67041 to correctly report the error attempting to encode to protobuf)

we should still improve the server to fall back to other supported Accept types when the type being encoded did not support the first requested Accept encoding, but this is not a new issue

[liggitt]

The likely approach here is to filter the encoders the server supports to the ones the type for a particular endpoint supports when deciding what types a particular resource supports.