-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Creating AWS S3 Config Source #4575
Conversation
Aditya test old
Removed a local testing file
…y fatally logging
Please fix the build:
|
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.
Is it possible to use an abstraction like vfs to support all clouds?
https://github.com/C2FO/vfs
Reading config files doesn't seem like an extremely high-scale operation or anything that might benefit performance-wise from being "closer to metal" using the raw cloud sdks so maybe it's practical.
package awss3configsource | ||
|
||
import ( | ||
splunkprovider "github.com/signalfx/splunk-otel-collector" |
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 seems quite odd for the upstream collector to depend on a downstream distro, it's like a circular dependency
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.
Splunk is currently submitting a string of PRs into Collector - the plan is to have this merged in - in fact in the go.mod file I replace this reference with a local reference to the config provider folder
github.com/knadh/koanf v1.2.0 | ||
github.com/signalfx/splunk-otel-collector v0.0.0-00010101000000-000000000000 | ||
github.com/stretchr/testify v1.7.0 | ||
go.opentelemetry.io/collector v0.31.0 |
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.
Please use the same version as other go.mod
in the repo
@anuraaga Is VFS approved by security - I didn't spend a bunch of time thinking about it as I was under the impression that it would be rejected by AppSec out of hand Additionally, the goal of the config source interface is for each of the cloud providers to eventually add their own config source |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
@Aditya-Gollapudi Sorry for missing the comment from 20 days ago just saw it now. In principle, basically nothing is approved by AWS security as they check at a macro level - even if using the AWS SDK, the usage of the AWS SDK needs to get checked, etc. On the flip side, if using a different library like vfs, then the usage of that library would be checked in a similar way. Since VFS itself just wraps the AWS SDK, this will be straightforward. Also, this is the OpenTelemetry Collector - what's important is creating a component that makes sense for this codebase. If it's possible to make a generic mechanism for configuration across cloud providers, then that is a much better fit for this codebase than another mechanism that duplicates logic, with greater maintenance cost. If we think such a mechanism is simple, secure, and performant, than internal security review can be made to happen. |
@anuraaga Thanks for getting back - I believe that AppSec (perhaps AWS security is different) did approve the usage of the SDK in the way I did above - I didn't know that it was possible to get VFS approved. If that is the case I agree it makes some sense to use it as it more generic. However, I am no longer at Amazon for the moment so I'm not actively working on this. I believe Tianduo Hao is continuing my work (for some reason I can't seem to @skyduo) |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
@bogdandrutu @Aneurysm9 and I discussed how the Collector configuration can be extended to support the remote configuration needs. We do not think that the current ConfigSource approach fully covers all the uses cases and need to be extended somewhat. Please see the proposal here open-telemetry/opentelemetry-collector#4190 |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Signed-off-by: Bogdan Drutu <[email protected]>
Moved this from collector to contrib
Note: Please don't review anything in the configprovider folder - that will all be merged in a different PR (coming from Paolo) The only stuff from this that will be merged is in the s3configsource folder. This PR was mostly submitted to try to parallelize some of the reviewing
Description: Added a Config Source for S3 inline with the new config source changes that have been made
Testing: So far there is only a core test, but I will continue to add them - this is something of a draft. Also please note that we expect the configprovider folder to be merged in at some point later on but that won't live here - where exactly everything is to be merged is still up in the air
@pjanotti
Link to old PR: open-telemetry/opentelemetry-collector#3738