-
-
Notifications
You must be signed in to change notification settings - Fork 305
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
Merge ApiCapabilities
into ApiResource
#1036
Comments
clux
added
core
generic apimachinery style work
question
Direction unclear; possibly a bug, possibly could be improved.
labels
Sep 28, 2022
clux
changed the title
Merge
Merge Sep 28, 2022
ApiCapabilities
on ApiResource
ApiCapabilities
into ApiResource
Clarifying the argument for it for It's not possible for the new methods to protect against scope misuse on dynamic types as it stands: impl Client {
async fn create_namespaced_dyn<K>(&self, ns: &Namespace, pp: &PostParams, data: &K, dt: &K::DynamicType) -> Result<K>
where:
K: Resource<Scope = DynamicResourceScope> + Serialize + DeserializeOwned + Clone + Debug,
{
// TODO: need to runtime limit function based on the dynamic Scope of the dynamic resource
} Because of the dynamic type, scope needs to be limited at runtime rather than by a type constraint. This currently cannot be done because the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our
ApiResource
is intentionally a subset of the upstreamAPIResource
that lets us be able to use the type as aResource
. It has a special meaning as theDynamicType
forResource
in the dynamic discovery cases.ApiCapabilities
is more the other part of that; the parts that is not essential to have to use the type with the api, but for helpful for detecting "what you can do with it".However, the way we have split it is becoming harder to justify:
Scope
is becoming more and more necessary to use the api correctly (more so with Add core_methods directly onClient
#1032)APIResource
is becoming harder and harder (Add shortnames field in kube::discovery::ApiResource #1002)discovery
anyway as(ApiResource, ApiCapabilities)
Thus, I think we should reduce the distance between the native Kubernetes types and do one of the following:
Option 1: Bundle
capabilities
as an optional field insideApiResource
A least breaking change type thing.
Option 2: Merge fields from
ApiCapabilities
as optional fields insideApiResource
The most breaking potential change. This needs additional breaking changes to flatten the methods on
ApiCapabilities
intoApiResource
.In both cases:
discovery
goes from returningVec<(ApiResource, ApiCapabilities)>
toVec<ApiResource>
ApiResource::erase
can set whatever fields we don't need in the runtime toNone
.And we would get the struct more in-line with the upstream type, while retaining their light-weight use (optional types does not have an extra memory overhead when they are
None
) as aDynamicType
.Doing the most breaking change (full merge) I think would be easier because it also helps solve the problem of where to put the upstream fields, and help get direction on things like #1002.
The text was updated successfully, but these errors were encountered: