KubernetesMockServer does not return same List type as Kubernetes Api Server

[rohanKanojia]

Describe the bug

Related to #1601

This issue applies to scenarios when you're using Kubernetes Mock Server with clients other than Fabric8 Kubernetes Client.

When you use KubernetesMockServer in crud mode to get response of list() query operations, you'd get response like this:

{"apiVersion":"v1","kind":"List", "items": [{"kind":"Secret","apiVersion":"v1","metadata":{"name":"sh.helm.release.v1.test-project.v1",

However, with a real Kubernetes API server, we get a concrete List type

{"kind":"SecretList","apiVersion":"v1","metadata":{"resourceVersion":"225"},"items":[{"metadata":{"name":"sh.helm.release.v1.test-project.v1","namespace":"default","uid":"eeccb069-92c8-4220-9ec7-e2237d4ab660",

This is coming from here:

kubernetes-client/junit/kubernetes-server-mock/src/main/java/io/fabric8/kubernetes/client/server/mock/KubernetesResponseComposer.java

Lines 30 to 32 in 6c24a98

	return String.format(
	"{\"apiVersion\":\"v1\",\"kind\":\"List\", \"items\": [%s], " +
	"\"metadata\": {\"resourceVersion\": \"%s\", \"selfLink\": \"\"}}",

This will work for KubernetesClient, however with other clients it causes problems in parsing list-objects.

Fabric8 Kubernetes Client version

SNAPSHOT

Steps to reproduce

Set up Kubernetes Mock Server with some other client and try doing list request, it would fail

Expected behavior

Kubernetes Mock Server list response should be same as Kubernetes Api Server

Runtime

other (please specify in additional context)

Kubernetes API Server version

1.25.3@latest

Environment

Linux

Fabric8 Kubernetes Client Logs

No response

Additional context

No response

[manusa]

As reviewed internally:

• Current state of Kubernetes Mock Server (CRUD) doesn't allow to reliably infer the list type from the path. This is required for the following cases:
  • There are no items for the resource located at the path
  • There are resources with mismatching or inconsistent kind at the specified path (this is not likely to happen, but it's still an issue)

Once we fix #6062 (Aggregated discovery of endpoints) and the Kubernetes model is completely inferred from OpenAPI (#6130), we might be able to implement this.