You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our ApiResource is intentionally a subset of the upstream APIResource that lets us be able to use the type as a Resource. It has a special meaning as the DynamicType for Resource 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:
These types are generally constructed together via 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 inside ApiResource
A least breaking change type thing.
Option 2: Merge fields from ApiCapabilities as optional fields inside ApiResource
The most breaking potential change. This needs additional breaking changes to flatten the methods on ApiCapabilities into ApiResource.
In both cases:
discovery goes from returning Vec<(ApiResource, ApiCapabilities)> to Vec<ApiResource>
ApiResource::erase can set whatever fields we don't need in the runtime to None.
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 a DynamicType.
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:
clux
added
core
generic apimachinery style work
question
Direction unclear; possibly a bug, possibly could be improved.
labels
Sep 28, 2022
Clarifying the argument for it for Scope as it came immediately in #1037.
It's not possible for the new methods to protect against scope misuse on dynamic types as it stands:
implClient{asyncfncreate_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 Scope resides on ApiCapabilities but we really need it inside the DynamicType (which is ApiResource).
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: