New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CustomResourceDefinitionsOperationsImpl uses v1beta1 API instead of v1 #2287
Comments
If we just modify exiting CustomResourceDefinition to use v1, someone may report issue that we dropped v1beta1 CustomResourceDefinition Hmm, I'm thinking of adding an additional DSL endpoint
|
That looks good to me, but i might suggest that the default for |
Hmm, okay. we can modify old api entrypoint to use apiextensions/v1 |
i meant for the new apiextensions() based one, sorry! |
…nition Introduced a new api entrypoint called `client.apiextensions()` which would route to `apiextensions/v1` and `apiextensions/v1beta1` CustomResourceDefinitions
…nition Introduced a new api entrypoint called `client.apiextensions()` which would route to `apiextensions/v1` and `apiextensions/v1beta1` CustomResourceDefinitions
…nition Introduced a new api entrypoint called `client.apiextensions()` which would route to `apiextensions/v1` and `apiextensions/v1beta1` CustomResourceDefinitions
…nition Introduced a new api entrypoint called `client.apiextensions()` which would route to `apiextensions/v1` and `apiextensions/v1beta1` CustomResourceDefinitions
…nition Introduced a new api entrypoint called `client.apiextensions()` which would route to `apiextensions/v1` and `apiextensions/v1beta1` CustomResourceDefinitions
Would be good for this to use the non-beta API. This would require the client drop support for < 1.16 of k8s unless it is possible to let the fluent builders support both versions of the API.
The text was updated successfully, but these errors were encountered: