ThirdPartyResource needs to be root scoped, not namespace scoped fixed in #25006

the namespace is not considered when registering API endpoints (in master.go#InstallThirdPartyResource), and the existence of a ThirdPartyResource affects all namespaces, not just the one where it is added.

the rest resource URL should be built from the kind the same way other resources are (kindToResource(kind), not just lower(kind)+"s")

m.addThirdPartyResourceStorage(path, thirdparty.Storage[strings.ToLower(kind)+"s"].(*thirdpartyresourcedataetcd.REST), apiGroup)

Edit: addressed in #25129 and #25374

cc @brendandburns @deads2k

also need to add validation:

• make sure thirdpartyresource names are well-formed (can parse kind/group from name)
• ensure version is a valid URL path segment
• validate objectmeta and objectmeta updates for thirdpartyresourcedata

edit: opened #25007

I don't think we should graduate ThirdPartyResource to beta until we have a story for

• extensible validation (author of the ThirdPartyResource can supply validation code - not just validating the few bits that are currently non-opaque)
• defaulting (similar to above)
• versioning and conversion
• admission control
• federated testing
• make kubectl extensible at runtime so a ThirdPartyResource can be pretty-printed in kubectl get and kubectl drescribe rather than just dumping out the YAML

After discussing with @bgrant0607 and @brendandburns I withdraw my list above. The argument is all of the above things can be done by some combination of a client (that is distributed with the TPR's controller, or even part of the same binary like hyperkube), logic in the controller, and runtime-extensible admission control (which is on our TODO list). And that federated testing isn't strictly necessary because the TPR's controller should be using regular Kubernetes APIs that are subject to the normal stability and deprecation guarantees (which isn't to say that TPR's shouldn't be continuously tested, just that there's a reasonable argument that we don't have to completely "solve" federated testing for TPR's to be useful).

I think this should be resolved:

• Removing a ThirdPartyResource orphans associated ThirdPartyResourceData (endpoints go away, so data can't be removed via the API, but lives on in etcd)

This is also a bug, though I'm not sure how important it is if the API can't actually do anything with multiple versions of a third party resource data:

• Specifying multiple versions for a ThirdPartyResource doesn't actually expose API endpoints for any version other than the first

Are there any ideas yet on how the migration path would look like if TPRs hit beta state? This is fairly important for anyone releasing controllers on top of v1alpha1.

Are there any ideas yet on how the migration path would look like if TPRs hit beta state? This is fairly important for anyone releasing controllers on top of v1alpha1.

Given the shortcomings of the API as a whole, the potential for auto-created naming conflicts which are impossible to resolve and inconsistencies between metadata for storage versus metadata from the API, I'm not sure that backwards compatibility will be maintainable when we try to fix it. The TPR resource itself is missing data and then the thirdpartydata storage allows inconsistencies which are hard to deal with. It may end up being breaking all the way down the chain.

Sub-resources for Third Party Resources: #38113

metadata.generation: #7328

superceded by CRD, beta in 1.7, tracked in kubernetes/enhancements#95