🐛 Fix manifest object type mutation

[arybolovlev]

Description

This PR fix an issue in the provider that happens when the data source kubernetes_resources receives multiple Kubernetes objects containing tuples with different numbers of elements.

The data source kubernetes_resources takes a Kubernetes object schema and generates a tftypes.Type representation of a Kubernetes resource once. All Kubernetes objects received by kubernetes_resources should conform to this schema. The issue arises when received objects contain a tuple with a different number of elements.

This occurs during the provider's iteration over received Kubernetes objects, invoking the DeepUnknown function. One of the arguments that DeepUnknown receives is the tftypes.Type representation of a Kubernetes resource (object type), which undergoes mutation within the DeepUnknown function. This mutation involves normalizing the number of elements in the tuple to match the number of elements in the Kubernetes objects being processed. If a subsequent Kubernetes object contains a different type of element, the provider throws an error, as the object appears inconsistent with the mutated object type. This pull request addresses the issue by fixing the mutation step, ensuring that the object type remains unchanged.

The following Terraform code should return all Pods in kube-system namespace:

data "kubernetes_resources" "pods" {
  api_version = "v1"
  kind        = "Pod"
  namespace   = "kube-system"
}

Here are two out of eight objects that the provider receives:

Pod coredns:

apiVersion: v1
kind: Pod
metadata:
  ...
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    ...
  - apiVersion: v1
    fieldsType: FieldsV1
    ...
  - apiVersion: v1
    fieldsType: FieldsV1
    ...
  name: coredns-5d78c9869d-drcfj
  namespace: kube-system
  ...

Pod etcd:

apiVersion: v1
kind: Pod
metadata:
  ...
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    ...
  - apiVersion: v1
    fieldsType: FieldsV1
    ...
  name: etcd-kube27-control-plane
  namespace: kube-system
 ...

In the case of the coredns pod, we can see that the metadata.managedFields tuple contains 3 elements. However, the following etcd pod contains only 2 elements, leading the provider to quit with an error at this point.

Acceptance tests

• Have you added an acceptance test for the functionality being added?

Release Note

Release note for CHANGELOG:

`data_source/kubernetes_resources`: fix an issue where the provider exits with an error when the data source `kubernetes_resources` receives multiple Kubernetes objects containing tuples with different numbers of elements.

References

Fix: #2215

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[jrhouston]

Nice! 🔧

[jrhouston]

Are these FIXMEs here to add a more meaningful summary?

[arybolovlev]

Those 4 don't reflect the errors they represent, I noticed this while working on this PR. I will open a new PR to fix it. Next time I will add more meaningful text that just FIX ME. 😔

[cguertin14]

hey! any updates on this? :)

[alexsomesan]

This makes sense. I also tested against issue #2440 and this fix resolves it.
Apologies for the long delay in getting this in.