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

Build in log sink functionality. #9

Merged
merged 5 commits into from Sep 15, 2021
Merged

Build in log sink functionality. #9

merged 5 commits into from Sep 15, 2021

Conversation

paddycarver
Copy link
Contributor

Starting to address #6. This is just the start of the work, but it gives
us something to build on.

Basically, what we're trying to do is build log sink functionality into
terraform-plugin-log. Normally, Terraform acts as a log sink, gathering
up logs from core and from all the plugins, filtering them
appropriately, and combining them into a single log output stream, and
deciding where to send that stream. However, when running acceptance
tests, the plugin is actually the longest-running process, and so this
model breaks down. Instead, we need to have the plugin act as the sink,
gathering the logs from core and the plugin and other plugins, combining
them into a single stream, filtering the stream, and deciding where to
output the stream.

Rather than implement this functionality multiple times in different
SDKs, it makes more sense to add it to the tfsdklog package and just
call it from the test frameworks.

There are a few parts to this. First, we need a new sink logger that all
other loggers are derived from. It should read environment variables to
determine what level of output is desired, what format of output is
desired, and where to send that output. Second, we should make all our
loggers be sub-loggers of that sink when the sink is set. Third, we
should make sure our sub-loggers can only log at levels equal to or
higher than the level of this new sink logger when it's set. And
finally, we should provide functionality to process hclog JSON output
(like from terraform when TF_LOG=json) and route it through this sink
logger, so we can combine the log output of the CLI and other providers
with the log output native to the process.

This commit falls short in a few places:

  • sub-loggers aren't limited to equal-or-higher levels from the sink
    logger yet.
  • none of this has been tested, even manually. It builds?
  • we need to make the tflog package sink-aware, just like the tfsdklog
    package. This likely involves moving the sink functionality into an
    internal package.
  • we need to check that all the environment variables we need to be
    honoring are getting honored for the provider under test, the CLI, and
    the providers the CLI launches.

@paddycarver
Copy link
Contributor Author

In case these notes are helpful, here's how I'm thinking about the flow of logs between processes and components, and what environment variables get applied where.

IMG_20210817_052952

@paddycarver
Copy link
Contributor Author

Rebased on #10.

@paddycarver paddycarver marked this pull request as ready for review September 2, 2021 21:55
@paddycarver paddycarver requested a review from a team September 2, 2021 21:55
@bflad bflad added this to the v0.2.0 milestone Sep 3, 2021
@bflad bflad self-assigned this Sep 3, 2021
@bflad bflad added the enhancement New feature or request label Sep 3, 2021
@bflad
Copy link
Member

bflad commented Sep 3, 2021

Will review this when #10 is merged and this is rebased 😄

@paddycarver paddycarver force-pushed the paddy_sink branch 3 times, most recently from 71dca88 to 76e1d83 Compare September 4, 2021 06:55
paddycarver added a commit to hashicorp/terraform-plugin-go that referenced this pull request Sep 4, 2021
Update breaking changes and refactoring so we're ready for logging
sinks.
Starting to address #6. This is just the start of the work, but it gives
us something to build on.

Basically, what we're trying to do is build log sink functionality into
terraform-plugin-log. Normally, Terraform acts as a log sink, gathering
up logs from core and from all the plugins, filtering them
appropriately, and combining them into a single log output stream, and
deciding where to send that stream. However, when running acceptance
tests, the plugin is actually the longest-running process, and so this
model breaks down. Instead, we need to have the plugin act as the sink,
gathering the logs from core and the plugin and other plugins, combining
them into a single stream, filtering the stream, and deciding where to
output the stream.

Rather than implement this functionality multiple times in different
SDKs, it makes more sense to add it to the tfsdklog package and just
call it from the test frameworks.

There are a few parts to this. First, we need a new sink logger that all
other loggers are derived from. It should read environment variables to
determine what level of output is desired, what format of output is
desired, and where to send that output. Second, we should make all our
loggers be sub-loggers of that sink when the sink is set. Third, we
should make sure our sub-loggers can only log at levels equal to or
higher than the level of this new sink logger when it's set. And
finally, we should provide functionality to process hclog JSON output
(like from terraform when TF_LOG=json) and route it through this sink
logger, so we can combine the log output of the CLI and other providers
with the log output native to the process.

This commit falls short in a few places:

* sub-loggers aren't limited to equal-or-higher levels from the sink
  logger yet.
* none of this has been tested, even manually. It builds?
* we need to check that all the environment variables we need to be
  honoring are getting honored for the provider under test, the CLI, and
  the providers the CLI launches.

This depends on #10.
Copy link
Member

@bflad bflad left a comment

Choose a reason for hiding this comment

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

Overall this is shaping up well, very exciting. Great work. Just some code-level questions/comments. Since we need to manually test this anyways, I wonder if it is worth dropping any sort of documentation/checklist (README.md or whatever) about that process until #11 can be a focus.

tfsdklog/cli.go Show resolved Hide resolved
tfsdklog/sink.go Outdated Show resolved Hide resolved
tfsdklog/sink.go Show resolved Hide resolved
tfsdklog/sink_json.go Show resolved Hide resolved
@bflad bflad assigned paddycarver and unassigned bflad Sep 10, 2021
Copy link
Member

@bflad bflad left a comment

Choose a reason for hiding this comment

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

Amazing work! 🚀 Let's get this in so we can work through the various implementations.

tfsdklog/sink.go Show resolved Hide resolved
tfsdklog/sink_json.go Show resolved Hide resolved
tfsdklog/sink_json_test.go Show resolved Hide resolved
Comment on lines +88 to +94
if err != nil && tc.expectedErr != nil && err.Error() != tc.expectedErr.Error() {
t.Fatalf("expected error to be %v, got %v", tc.expectedErr, err)
} else if err == nil && tc.expectedErr != nil {
t.Fatalf("expected error to be %v, didn't get an error", tc.expectedErr)
} else if err != nil && tc.expectedErr == nil {
t.Fatalf("unexpected error %v", err)
}
Copy link
Member

Choose a reason for hiding this comment

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

Aside: I think using go-cmp's Diff works well for this scenario as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It doesn't let me cheat by using errors.New or fmt.Errorf, I'd need to use the right types of errors, too.

@paddycarver paddycarver merged commit 5013651 into main Sep 15, 2021
@paddycarver paddycarver deleted the paddy_sink branch September 15, 2021 16:07
paddycarver added a commit to hashicorp/terraform-plugin-go that referenced this pull request Sep 21, 2021
Update breaking changes and refactoring so we're ready for logging
sinks.
@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 contributions.
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 Oct 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants