-
Notifications
You must be signed in to change notification settings - Fork 29
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
Lifecycle refactor #190
Lifecycle refactor #190
Conversation
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.
Overall looks good I don't see anything that blocks this merge more just questions for my edification.
configPath: configPath, | ||
version: version, | ||
loggingOpts: loggingOpts, | ||
statusChan: make(chan *Status, 10), |
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.
Any reason we chose 10 here?
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 was an arbitrary selection related to the select statement below. I wanted to give a wide enough buffer that if something was listening to the status channel, it minimized the risk of missing something if it wasn't consuming fast enough.
version: version, | ||
loggingOpts: loggingOpts, | ||
statusChan: make(chan *Status, 10), | ||
wg: &sync.WaitGroup{}, |
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.
nit: usually wait groups are not pointers unless passed into functions. I have no idea why honestly more of just an observation you don't have to change it.
select { | ||
case c.statusChan <- status: | ||
case c.statusChan <- &Status{running, 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.
Why is this in a select
? Is it just so we don't block sending? Seems like we could miss a send if the channel is full. Maybe that's ok?
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 went with this pattern, because I didn't think there were any guarantees that whoever is using this struct is listening to the status channel. So I didn't want to lock everything up on a full channel, in the scenario where there is no consumer.
pkg/collector/test/invalid.yaml
Outdated
|
||
service: | ||
pipelines: | ||
logs: | ||
receivers: [filelog] | ||
exporters: [logging] | ||
exporters: [nop] |
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.
nit newline (you can thank Duri for me noticing missing newlines on files)
pkg/collector/test/valid.yaml
Outdated
|
||
service: | ||
pipelines: | ||
logs: | ||
receivers: [filelog] | ||
exporters: [logging] | ||
exporters: [nop] |
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.
newline
Tests detected a race condition, and lots of this in ci-check
|
Proposed Change
Checklist