Have a single interface containing both ApiVersion/Kind and Metadata

[admilazz]

With IKubernetesObject and IMetadata<T> being completely separate, there is no single type that I can use to capture them both, which leads to a great proliferation of generics with type constraints, e.g.
Process<T>(T obj) where T : IKubernetesObject, IMetadata<V1ObjectMeta>. Every place where such an object is passed or returned must be made generic and decorated with type constraints.

It'd be helpful to have an interface that encapsulates the combination of the above. I suggest:

interface IKubernetesObject<TMetadata> : IKubernetesObject, IMetadata<TMetadata> { }

[macsux]

I wrote that PR that added these interfaces. There are some objects in k8s that don't have metadata as I've discovered when I tried slapping them with the interface you have above. I came to conclusion that isolating low level traits as separate interfaces made more sense. I'm still evaluating which interfaces to create that recombine one or more of these like the one above. One can make the argument that it should also include Status and or Spec, as most objects have it. But the key thing here is most, not all.

It may still be worthwhile to do this, but I wanted to evaluate which combination of "trait" interfaces should be introduced, as you can go down a big rabbit hole trying to cover all scenarios, generating many "intermediate" interfaces that will introduce noise. If we're going to introduce some of these, I would like to keep the number of these interfaces low.

I do think something that groups IMetadata, ISpec together makes sense, as 95% of objects in k8s follow this convention, with potentially another inheriting that adds IStatus.

[admilazz]

I don't think it'd be good to include status and spec given that they are different for each type of object. Presumably only a single type would implement each combination of status and spec, and you wouldn't gain much from it. You could just use the concrete type name such as V1Pod rather than IStatusAndSpec<V1PodSpec,V1PodStatus>, since V1Pod is the only type implementing it. Grouping IMetadata and ISpec has the same problem: only one type would implement it and you wouldn't gain much from it.

On the other hand, almost all objects have ApiVersion, Kind, and V1ObjectMeta, and many generic operations can be performed using those without needing to know the details of the spec or status. The point of my comment was to have an interface that serves as a base type that nearly all objects can be assigned to and operated on generically. In particular, in my own code I do many operations on generic objects that have IKubernetesObject, IMetadata<V1ObjectMeta> and would like to be able do it without a great proliferation of generic type parameters and constraints.

[brendandburns]

Closing since #404 merged.