Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add kubernetes_resource data source #1548

Merged
merged 3 commits into from
Feb 23, 2022
Merged

Add kubernetes_resource data source #1548

merged 3 commits into from
Feb 23, 2022

Conversation

jrhouston
Copy link
Collaborator

Description

This PR adds a generic kubernetes_resource data source as an analogue to the kubernetes_manifest resource.

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=TestAccXXX'

...

Release Note

Release note for CHANGELOG:

Add kubernetes_resource data source

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

@jrhouston jrhouston changed the title Manifest datasource Add kubernetes_resource data source Dec 14, 2021
### Example: Get data from a ConfigMap

```hcl
data "kubernetes_resource" "example" {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexsomesan open to thoughts on the naming here, I didn't use manifest because that specifically refers to the YAML file you apply to the cluster whereas here we're retrieving an API resource so I thought resource made sense. kubernetes_object would also work too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with you. This is a good choice of name. Using manifest would likely be more confusing. Also, this datasource could be used together with the native resources (non kubernetes_manifest) and then it makes even more sense to call it like this.


```hcl
data "kubernetes_resource" "example" {
apiVersion = "v1"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth noting that we're going to break the snake_case convention that is used everywhere else (and all other providers too) for resource attributes. api_version would be fine here, just that the camelCase convention is probably more familiar to users of this provider.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly am ok with either option. There are valid points, which you raised, for both of them.
I'm with you there that keeping with the spirit of this resources trying to track as close as possible to native K8s, this looks like the slightly better option.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed this to api_version after my conversation with DevEx – they recommended not breaking the convention.

Copy link
Member

@alexsomesan alexsomesan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! I played around with the datasource and it works nicely as expected.

I dropped some observations about UX down below, but structurally this is great work!
Thanks! a lot!


gvr, err := getGVR(apiVersion, kind, rm)
if err != nil {
return resp, err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to keep consistent and return nice Diagnostics here that wrap this error. We should strive to have zero instances of raw error returns to the protocol.

gvk := gvr.GroupVersion().WithKind(kind)
ns, err := IsResourceNamespaced(gvk, rm)
if err != nil {
return resp, err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same observation about error returned here.

return resp, nil
}

objectType, err := s.TFTypeFromOpenAPI(ctx, gvk, false)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A point could be made that this should best happen before the actual API Get call. Reason being that it might serve as validation for the correctness of the input attributes independently of potential permission errors on the resource Get call.
What I'm not sure about is whether client-go distinguishes (with different error codes) between a RBAC permission issue on a valid path and an invalid path (likely also reported by 'not found').


objectType, err := s.TFTypeFromOpenAPI(ctx, gvk, false)
if err != nil {
return resp, fmt.Errorf("failed to determine data source type: %s", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Diagnostic vs raw error here too

...and a few more spot down below.


```hcl
data "kubernetes_resource" "example" {
apiVersion = "v1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I honestly am ok with either option. There are valid points, which you raised, for both of them.
I'm with you there that keeping with the spirit of this resources trying to track as close as possible to native K8s, this looks like the slightly better option.

### Example: Get data from a ConfigMap

```hcl
data "kubernetes_resource" "example" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with you. This is a good choice of name. Using manifest would likely be more confusing. Also, this datasource could be used together with the native resources (non kubernetes_manifest) and then it makes even more sense to call it like this.

@jrhouston
Copy link
Collaborator Author

jrhouston commented Feb 1, 2022

As discussed, I have changed metadata to a block instead of an object – this should be good to go.

@jrhouston jrhouston force-pushed the manifest-datasource branch 2 times, most recently from 95cba7e to 7d25484 Compare February 1, 2022 03:17
@alexsomesan
Copy link
Member

Looks good! How do you feel about the Diagnostics suggestions I made earlier?

@jrhouston
Copy link
Collaborator Author

Yeah sounds good, I've wrapped all the errors in diagnostics.

Copy link
Member

@alexsomesan alexsomesan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jrhouston
Copy link
Collaborator Author

Looks like the tests are failing because I missed something when rebasing – will fix.

@jrhouston jrhouston merged commit bc4290b into main Feb 23, 2022
@jrhouston jrhouston deleted the manifest-datasource branch February 23, 2022 06:51
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants