-
Notifications
You must be signed in to change notification settings - Fork 992
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
Conversation
7e89a96
to
71608a9
Compare
### Example: Get data from a ConfigMap | ||
|
||
```hcl | ||
data "kubernetes_resource" "example" { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
manifest/provider/datasource.go
Outdated
|
||
gvr, err := getGVR(apiVersion, kind, rm) | ||
if err != nil { | ||
return resp, err |
There was a problem hiding this comment.
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.
manifest/provider/datasource.go
Outdated
gvk := gvr.GroupVersion().WithKind(kind) | ||
ns, err := IsResourceNamespaced(gvk, rm) | ||
if err != nil { | ||
return resp, err |
There was a problem hiding this comment.
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.
manifest/provider/datasource.go
Outdated
return resp, nil | ||
} | ||
|
||
objectType, err := s.TFTypeFromOpenAPI(ctx, gvk, false) |
There was a problem hiding this comment.
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').
manifest/provider/datasource.go
Outdated
|
||
objectType, err := s.TFTypeFromOpenAPI(ctx, gvk, false) | ||
if err != nil { | ||
return resp, fmt.Errorf("failed to determine data source type: %s", err) |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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" { |
There was a problem hiding this comment.
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.
As discussed, I have changed |
95cba7e
to
7d25484
Compare
Looks good! How do you feel about the Diagnostics suggestions I made earlier? |
Yeah sounds good, I've wrapped all the errors in diagnostics. |
7d25484
to
4115bde
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Looks like the tests are failing because I missed something when rebasing – will fix. |
245dc82
to
06333fc
Compare
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. |
Description
This PR adds a generic
kubernetes_resource
data source as an analogue to thekubernetes_manifest
resource.Acceptance tests
Output from acceptance testing:
Release Note
Release note for CHANGELOG:
References
Community Note