List Type Not Supported

[oliverisaac]

Terraform Version

Terraform v0.11.13

• provider.google v2.5.0
• provider.helm v0.9.0
• provider.k8sraw v0.1.93
• provider.kubernetes v1.6.2
• provider.template v2.1.1

Affected Resource(s)

Please list the resources as a list, for example:

• k8sraw_yaml

Terraform Configuration Files

resource "k8sraw_yaml" "example-list" {
    yaml_body = <<YAML
kind: List
apiVersin: v1
items:
- apiVersion: v1
  data:
    username: YWRtaW4=
  kind: Secret
  metadata:
    name: my-secret
    namespace: example
  type: Opaque
YAML
}

Expected Behavior

Should create a secret.

Actual Behavior

Got this error:

* k8sraw_yaml.example-list: failed to create kubernetes rest client for resource: resource provided in yaml isn't valid for cluster, check the APIVersion and Kind fields are valid

Steps to Reproduce

1. Apply the above terraform file.

References

• Support of CRD #11 <- Looks to be related to this issue in the sense that it's a valid kind but it's not be detected correctly by

  terraform-provider-kubernetes-yaml/kubernetes/resource_kubernetes_yaml.go

  Lines 275 to 278 in 2699cc2

  	apiResource, exists := checkAPIResourceIsPresent(resources, unstrut)
  	if !exists {
  	return nil, nil, fmt.Errorf("resource provided in yaml isn't valid for cluster, check the APIVersion and Kind fields are valid")
  	}

[oliverisaac]

Of note, if I do { kubectl api-resources -o name --namespaced=false; kubectl api-resources -o name --namespaced=true; } | grep -i list I do not get any matches for list. So while list is valid, it's not returned by api-resources.

[lawrencegripper]

This is an interesting one, I'm not sure if there is a way to support the list resources as the provider relies on their being a 1:1 mapping between the Terraform resources in HCL and a resource created in kuberentes. As the list is a grouping of lots of different k8s resources it's going to be hard to work out the update/diff logic.

I'd be interested if you wanted to dive into the code more and see if there is some way to work around this issue but fair warning I think it may be hard.

[oliverisaac]

Oh, I thought I had mentioned this in my original report, but this could go hand-in-hand with supporting multiple files. (E.g. using the --- file seperator)

If multiple-files were implemented somehow (perhaps an array index like the count operator?) then a list would just require the special case where we turn a list into multiple files (one per item), then apply those multiple files.

I'm mostly spitballing here to see if these are crazy ideas.

(BTW, for future googlers out there, my immediate solution was to break the list into individual files, then generate the HCL's referencing those files.)

[lawrencegripper]

Agreed, if there is some funky way to handle multi-resource files with --- then the same approach could be used here to handle list objects.

The concern I have around handling multi-resource files is that the Terraform provider does create, update and delete operations at a resource level. I'm unsure how you'd handle the case, for example, where one of the resources in a multi-resource file was removed - terraform would be performing a delete but the UI and commandline would probably have to show this as an update as we'd only be doing a partial delete....

Second splitting things out being the best way forward - I'll add an up for grabs tag to this one tho and if anyone fancies trying to build out a solution they're welcome to give it a go.

[jhoblitt]

I don't think k8s has a concept of a List resource and there isn't any way of tracking which resources were created/updated/etc. from a List. AFAIK -- the only way to get a List as a response is from a query returning multiple resources. E.g., kubectl get <foo> -oyaml. Which means that even if querying for a label applied to all resources in the original List, it wouldn't work for mixed resource types.

My guess is the only way to make something like this reasonably work is to either blindly create/apply the yaml document without any tf side resource tracking or for the provider to parse the List and transparently manage it as a group of resources.

The "blind" option would be a convenient way to support slurping in existing yaml files with multiple resources, as that is often a format provided for example deployments.

[davisford]

This one might be simpler than you think to solve. If the sample yaml is the same you're using and not just a typo in the writeup, the error message is correct about the apiVersion not being correct.