OpenReports currently exposes a strongly typed Kubernetes API and generated client packages.
That works for controllers, but it creates unnecessary coupling for CLIs, scanners, converters, and other producers that only need to create or consume OpenReports objects.
The current module depends on:
- "k8s.io/api"
- "k8s.io/apimachinery"
- "k8s.io/client-go"
The report types also depend on strongly typed Kubernetes objects such as core resource references and metadata types.
There is no lightweight integration surface for consumers that intentionally use Kubernetes API machinery and unstructured objects, but do not want typed core APIs, generated clients, schemes, or controller dependencies.
This affects tools that:
- already operate on "unstructured.Unstructured";
- use dynamic Kubernetes clients;
- only need the OpenReports wire format;
- want to avoid coupling their Kubernetes module versions to the typed OpenReports API;
- do not need generated clients or runtime registration.
A useful boundary would be an unstructured OpenReports representation that:
- depends on "k8s.io/apimachinery";
- does not depend on "k8s.io/api";
- does not depend on "k8s.io/client-go";
- preserves the official "Report" and "ClusterReport" wire format;
- exposes the API group, version, kinds, and allowed result values;
- remains compatible with dynamic Kubernetes tooling;
- can be validated against the official CRDs.
The existing strongly typed API remains appropriate for controllers. The missing piece is a smaller unstructured surface for portable producers and consumers.
OpenReports currently exposes a strongly typed Kubernetes API and generated client packages.
That works for controllers, but it creates unnecessary coupling for CLIs, scanners, converters, and other producers that only need to create or consume OpenReports objects.
The current module depends on:
The report types also depend on strongly typed Kubernetes objects such as core resource references and metadata types.
There is no lightweight integration surface for consumers that intentionally use Kubernetes API machinery and unstructured objects, but do not want typed core APIs, generated clients, schemes, or controller dependencies.
This affects tools that:
A useful boundary would be an unstructured OpenReports representation that:
The existing strongly typed API remains appropriate for controllers. The missing piece is a smaller unstructured surface for portable producers and consumers.