stable crd creation fails on 1.17 kind

[clux]

Not sure if this is visible elsewhere, but I'm getting an error on applying the following resource:

    apiVersion: apiextensions.k8s.io/v1
    kind: CustomResourceDefinition
    metadata:
      name: foos.clux.dev
    spec:
      group: clux.dev
      names:
        kind: Foo
        plural: foos
        shortNames: []
        singular: foo
      scope: Namespaced
      versions:
        - additionalPrinterColumns: []
          name: v1
          served: true
          storage: true

i.e. created on a struct not setting #[kube(apiextensions = "v1beta1")]

[2020-03-08T20:39:50Z INFO  crd_apply] apply error: ErrorResponse { status: "Failure", message: "Incorrect version specified in apply patch. Specified patch version: apiextensions.k8s.io/v1, expected: apiextensions.k8s.io/v1beta1", reason: "BadRequest", code: 400 }
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `400`,
 right: `409`', kube/examples/crd_apply.rs:57:13

presumably something is causing kubernetes to expect that to be a v1beta version of the crd even if we're saying v1. Perhaps it's because we're not specifying the mandatory structural schema?

[clux]

can be recreated in #177 on a 0.7.0 kind cluster at cluster version 1.17.

[clux]

Running tests against 1.16.8 at the moment so I can deal with this later.

[nightkr]

Sounds like your old cluster already contained a CRD with that name that was using v1beta1. In that case, rebasing to 1.16.8 fixed it since you reset the cluster in the process.

[nightkr]

Nevermind, same issue on a clean 1.17.0. Weird..

[nightkr]

Ah, the issue is that the URL (from Api's K) needs to match the type specified in the YAML manifest. Api::patch still takes a raw byte array, so we can't verify that. Changing the apiexts use to ::v1 (from ::v1beta1) fixes the issue (or rather, crashes with another error since we don't supply a schema).

Ideally this would be a compile error with a typed Api::apply, but to make the transition between the two easier we could make the correct CustomResourceDefinition an associated type of the generated CRD.

[nightkr]

Then again, maybe it's good to leave this a bit janky, to discourage people from using this pattern outside of these trivial examples.

[praveenperera]

In apiextensions.k8s.io/v1 a schemas field is required under version could this problem be related to that?

#264

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

[nightkr]

@praveenperera #264 is unrelated to this.

[clux]

Are you sure? This might be related if we are in violation of the stable spec. Maybe we just got by on minikube.

[nightkr]

See #178 (comment) :P. It's still currently going to fail after that because of #264, but then it will give an error message explaining that reason as well.

[clux]

This was fixed in #348