Could a Spec be partial?

[qrilka]

While continuing my attempt to resolve https://github.com/infinyon/fluvio/issues/1131 I have found another corner case (a bit similar to #90 ) - MetadataClient uses Spec as a specification for a resource and provides methods for different operations for resources covered by that specification. But that set of operation looks to be fixed while Kubernetes API has resources with different sets of operations supported. In this particular case I'm trying to find an equivalent to kubectl auth can-i, under the hood it uses https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/#selfsubjectaccessreview-v1-authorization-k8s-io and this resource supports only one operation - Create. Is it expected for MetadataClient to be a superset of any operations which could be available for a resource and it's a responsibility for a user to use only correct ones? That sounds not very good in terms of type safety... So at the moment I'm a bit stuck between 2 conflicting requirements:

• using a Spec for SelfSubjectAccessReview means providing too much functionality and for exampe Status for this resource makes no sense at all
• using a special method for this resource would mean that other resources could require the same which would lead to not very clean API

In the end it looks that API should be more granular than single MetadataClient and a Spec should define also operations which are available for a resource but that's just an idea and it's not clear if there could be a good implementation for this which will not lead to a combinatorial explosion somewhere or would require too many type annotations. What could be a proper way to resolve this?

BTW The library doesn't have a lot of documentation so I'd like to ask one extra question - is there some concrete motivation for this set of crates instead of using kube-rs?

[sehz]

I agree, at this point Spec may need dummy "functionality" to satisfy traits. Please free to propose more type safety way. This crates predates kube-rs. At that time, there wasn't well supported Kubernetes Clients.

[qrilka]

Could it make sense to switch to it now when it appears to have mush fuller implementation?

[qrilka]

@sehz it looks like I didn't notice that SelfSubjectAccessReview has status as a part of it's API so that statement was not correct in my words. So I suppose SelfSubjectAccessReviewSpec makes some sense. As for supporting a subset of methods MetadataClient per request - what do you think about an idea to have marker traits in methods? E.g. create_item could have a constraint like S: Spec + SupportsCreate? And we could use a simple macro #supports[Create,Update,List] on a particular spec to create marker traits concisely.

[sehz]

I think that sounds reasonable. How about shortening SupportsCreate to Create ?

[qrilka]

Sure thing, and still what about an option to switch to kube-rs in your longer term plan?

[sehz]

Switching to kube-rs will be major change and will take some to evaluate pro/cons. Specifically, there are few factors to consider:

• What is stability guarantee of the library?
• What are API difference? Migration cost?
• Is library extensible and composable so that we can implement our customization easily?

Currently we don't have bandwidth to evaluate alternatives and maintenance costs are acceptable for now. But welcome contributions

[qrilka]

Thanks