hashicorp / hashicorp/terraform-plugin-log
Consider Enabling TF_LOG_PROVIDER to Set Root Provider (and Root SDK?) Logger Levels
- Dominant language
- Go
- Stars
- 23
- Forks
- 11
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 1
Description
### terraform-plugin-log version
```
v0.4.0
```
### Use cases
terraform-plugin-sdk/v2@v2.18.0 enables the acceptance testing framework to passthrough the `TF_LOG_CORE` and `TF_LOG_PROVIDER` environment variables to its underlying `terraform-exec` handling and ultimately Terraform CLI. Acceptance testing is a little strange in terms of logging because the provider "under test" is being executed directly with its logs being controlled by the testing framework, rather than production where logs flow always through Terraform CLI. This means that setting just `TF_LOG_PROVIDER` during testing does not have the desired effect of controlling the provider under test logs anymore (it does, however, control _external_ providers that still log through Terraform CLI).
### Attempted solutions
`TF_LOG_CORE=WARN TF_LOG_PROVIDER_XXX=TRACE go test`
### Proposal
Introduce additional environment variable handling into the root loggers that would allow provider logging to work the same in production and acceptance testing.
The following behaviors could be a good starting point:
| TF_LOG_PROVIDER | TF_LOG_PROVIDER_XXX | TF_LOG_SDK | Provider Log Level | SDK Log Level |
| - | - | - | - | - |
| (none) | (none) | (none) | OFF | OFF |
| DEBUG | (none) | (none) | DEBUG | DEBUG |
| (none) | DEBUG | (none) | DEBUG | OFF |
| (none) | (none) | DEBUG | OFF | DEBUG |
| (none) | TRACE | DEBUG | TRACE | DEBUG |
| TRACE | DEBUG | (none) | DEBUG | TRACE |
| TRACE | (none) | DEBUG | TRACE | DEBUG |
| TRACE | DEBUG | INFO | DEBUG | INFO |
### References
- https://github.com/hashicorp/terraform-plugin-sdk/issues/992
Contributor guide
Research direction
Start by inspecting the root logger handling in terraform-plugin-log and how it reads TF_LOG_PROVIDER, TF_LOG_PROVIDER_XXX, and TF_LOG_SDK. Compare the current behavior with the proposal's provider and SDK log-level matrix, then define completion as consistent logging in production and acceptance testing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100