Add data source kubernetes_nodes, resource kubernetes_node_taint

[partcyborg]

Description

• Add new data source kubernetes_nodes
• Add new resource kubernetes_node_taint

closes #1932

Acceptance tests

• Have you added an acceptance test for the functionality being added?
• Have you run the acceptance tests on this branch?

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccKubernetesResourceNodeTaint_basic'
==> Checking that code complies with gofmt requirements...
go vet .
TF_ACC=1 go test "/home/mwilder/src/go/src/github.com/hashicorp/terraform-provider-kubernetes/kubernetes" -v -run=TestAccKubernetesResourceNodeTaint_basic -timeout 3h
=== RUN   TestAccKubernetesResourceNodeTaint_basic
--- PASS: TestAccKubernetesResourceNodeTaint_basic (23.15s)
PASS
ok  	github.com/hashicorp/terraform-provider-kubernetes/kubernetes	23.212s
$ make testacc TESTARGS='-run=TestAccKubernetesDataSourceNodes_basic'
==> Checking that code complies with gofmt requirements...
go vet .
TF_ACC=1 go test "/home/mwilder/src/go/src/github.com/hashicorp/terraform-provider-kubernetes/kubernetes" -v -run=TestAccKubernetesDataSourceNodes_basic -timeout 3h
=== RUN   TestAccKubernetesDataSourceNodes_basic
--- PASS: TestAccKubernetesDataSourceNodes_basic (17.03s)
PASS
ok  	github.com/hashicorp/terraform-provider-kubernetes/kubernetes	17.061s

Release Note

Release note for CHANGELOG:

New data source: `kubernetes_nodes`
New resource: `kubernetes_node_taint`

References

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

[hashicorp-cla]

All committers have signed the CLA.

[partcyborg]

Any chance I can get a review?

[partcyborg]

Friendly ping. This has been open for over a month now, any chance I could get a review?

[alexsomesan]

We'll have a look at this shortly, we do have this feature on our roadmap.
There's a bit of a conversation to be had about how to implement taints support, since there are a few different ways to about it, each with pros and cons.

[alexsomesan]

It would be great to have the entire set of node attributes returned here (status included), instead of just the name. I think that would make the data-source more broadly useful, as well as keeping in line with the rest of the data-sources in the provider.

[partcyborg]

I have added:

• all metadata fields
• all spec fields (except configSource which is deprecated)
• capacity related fields status.capacity and status.allocatable
• everything in status.node_info

The remainder of the fields under status seem too verbose and/or ephemeral to be of use for a data source that returns resources in a list. It is my opinion that if more detailed information is needed then a kubernetes_node data source that retrieves everything for a specific node would make more sense.

[alexsomesan]

@partcyborg I had a look through the changes. I think we can get the nodes datasource in pretty easily if you would be so kind as to add the rest of the attributes.

For taints, we would prefer an implementation along the lines of the kubernetes_annotations resource, which uses ServerSideApply with field manager tracking. We feel this approach is more robust when touching a resource that isn't fully managed by Terraform.

If you don't have the capacity to redo the taints resource, I'm more than happy to take care of that myself while you would update the schema for the nodes data-source.

Let me know how you want to move forward. Thanks!

[partcyborg]

@partcyborg I had a look through the changes. I think we can get the nodes datasource in pretty easily if you would be so kind as to add the rest of the attributes.

For taints, we would prefer an implementation along the lines of the kubernetes_annotations resource, which uses ServerSideApply with field manager tracking. We feel this approach is more robust when touching a resource that isn't fully managed by Terraform.

If you don't have the capacity to redo the taints resource, I'm more than happy to take care of that myself while you would update the schema for the nodes data-source.

Let me know how you want to move forward. Thanks!

@alexsomesan Thank you for the review!

You are absolutely correct that the read-modify-update cycle I was using here was not very robust. I discovered this myself as we have started to use this code in production (via our own fork of the provider) and the nodes one of our clusters are being constantly mutated by the CSP, causing all attempts to taint to fail with resource conflicts.

To fix this, I changed the implementation to use the Patch API instead. Looking through resource_kubernetes_annotations.go, including field manager tracking seems pretty straightforward so I am happy to do that.

[partcyborg]

@partcyborg I had a look through the changes. I think we can get the nodes datasource in pretty easily if you would be so kind as to add the rest of the attributes.

For taints, we would prefer an implementation along the lines of the kubernetes_annotations resource, which uses ServerSideApply with field manager tracking. We feel this approach is more robust when touching a resource that isn't fully managed by Terraform.

If you don't have the capacity to redo the taints resource, I'm more than happy to take care of that myself while you would update the schema for the nodes data-source.

Let me know how you want to move forward. Thanks!

kubernetes_node_taint is now using server side apply with field manager tracking.

Please let me know if you have any other questions or comments.

[alexsomesan]

@partcyborg I've had a quick look and the changes for taints look good. I'll keep testing it locally for a bit.

How about my other suggestion of adding full schema to the nodes datasource? I've read through the schema changes, looks ok.

[alexsomesan]

Tested this locally - works as expected.

Thanks for contributing, @partcyborg !