Add namedpipereceiver #29320
Add namedpipereceiver #29320
Conversation
sinkingpoint
force-pushed
the
namedpipe_receiver
branch
4 times, most recently
from
389832d
to
2631104
Compare
Certainly we need a readme for the component (i.e. Ideally we would also have a separate doc in |
There was a problem hiding this comment.
Code looks good, just need to include a readme and all the boilerplate updates like .github versions.yaml, etc. (#28818 is a recent reference)
sinkingpoint
force-pushed
the
namedpipe_receiver
branch
5 times, most recently
from
7cd3da6
to
a8fee05
Compare
|
@djaglowski I've added those + a basic README. Tests seem to be passing as well |
|
With #29472, we no longer have a dependabot.yml file. @codeboten, is there an equivalent change we need to make for renovate? |
| status: | ||
| class: receiver | ||
| stability: | ||
| alpha: [logs] |
There was a problem hiding this comment.
It will be once the PR is merged
| class: receiver | ||
| stability: | ||
| alpha: [logs] | ||
| distributions: [contrib] |
There was a problem hiding this comment.
this is not in the contrib distribution yet.
There was a problem hiding this comment.
I can be added once this PR is merged
|
This PR makes @djaglowski the only codeowner of the component - @djaglowski please approve the PR, this seems a bit out of pace with how we describe adding components in CONTRIBUTING.md. @sinkingpoint I see in the original issue you have yourself as codeowner, is that still valid? |
I'm waiting to approve until the dependabot conflict is addressed.
I asked that we first add an operator to pkg/stanza, which was done in #28841. This contains the bulk of the complexity and could be done in isolation of any receiver code. Subsequently, there is very little to do other than add the boilerplate because pkg/stanza input operators can be incorporated into a receiver with just a few lines of code.
Since this component was his first contribution, I suggested he add me initially, plan on applying for membership based on the contributing the component, then add himself as codeowner as well. |
|
Apologies - missed that there was something for me to do here. Will fix this up today |
sinkingpoint
force-pushed
the
namedpipe_receiver
branch
2 times, most recently
from
9bb574b
to
7c2ae6b
Compare
This adds a new receiver that reads from a named pipe, using the previously created namedpipeinput stanza operator. Because that operatos does the majority of the work, this is mostly boilerplate + a few tests to confirm that it works e2e. Signed-off-by: sinkingpoint <[email protected]> Prepare contrib-base for version v0.89.0
sinkingpoint
force-pushed
the
namedpipe_receiver
branch
from
7c2ae6b
to
b975674
Compare
This reverts commit 97a920d.
**Description:** This adds a new receiver that reads from a named pipe, using the previously created namedpipeinput stanza operator (open-telemetry#28841). Because that operator does the majority of the work, this is mostly boilerplate + a few tests to confirm that it works e2e. Link to tracking Issue: open-telemetry#27234 **Testing:** Added a few tests, loading the config, and actually creating a receiver to verify that it can read logs from the pipe. **Documentation:** None, yet. /cc @djaglowski - where should I add docs for this if any?
**Description:** This adds a new receiver that reads from a named pipe, using the previously created namedpipeinput stanza operator (open-telemetry#28841). Because that operator does the majority of the work, this is mostly boilerplate + a few tests to confirm that it works e2e. Link to tracking Issue: open-telemetry#27234 **Testing:** Added a few tests, loading the config, and actually creating a receiver to verify that it can read logs from the pipe. **Documentation:** None, yet. /cc @djaglowski - where should I add docs for this if any?
**Description:** This adds a new receiver that reads from a named pipe, using the previously created namedpipeinput stanza operator (open-telemetry#28841). Because that operator does the majority of the work, this is mostly boilerplate + a few tests to confirm that it works e2e. Link to tracking Issue: open-telemetry#27234 **Testing:** Added a few tests, loading the config, and actually creating a receiver to verify that it can read logs from the pipe. **Documentation:** None, yet. /cc @djaglowski - where should I add docs for this if any?
|
@sinkingpoint, I was just updating some things relating to code ownership and noticed that we still aren't able to assign you as an owner to this component because you're not a member of OpenTelemetry yet. Are you willing to apply? I'm happy to be one of your sponsors. |
|
I can be second sponsor. |
|
Ah! You did mention. Sure - application PR here: open-telemetry/community#1975 |
Description:
This adds a new receiver that reads from a named pipe, using the previously created namedpipeinput stanza operator (#28841). Because that operator does the majority of the work, this is mostly boilerplate + a few tests to confirm that it works e2e.
Link to tracking Issue: #27234
Testing:
Added a few tests, loading the config, and actually creating a receiver to verify that it can read logs from the pipe.
Documentation:
None, yet.
/cc @djaglowski - where should I add docs for this if any?