Pablo Baeyens
Pablo Baeyens
> so if you need access to any other docker repos from https://github.com/open-telemetry/opentelemetry-collector-releases just ask here and we can give the token stored in DOCKER_TOKEN_COLLECTOR_RELEASES access to other docker repos....
@thc1006 Sure! Here is how I would go about it: 1. Add the field to this struct: https://github.com/open-telemetry/opentelemetry-collector/blob/82f253445acdefbb5d7a7d9c13d5be679811a28e/cmd/mdatagen/internal/metadata.go#L18 2. Add a section to the template here: https://github.com/open-telemetry/opentelemetry-collector/blob/main/cmd/mdatagen/internal/templates/readme.md.tmpl that checks if...
> Probably for OCB it can be a configuration setting instead of a runtime flag (making this part of the declarative/version-controled manifests)? Yeah, I guess something like that makes sense....
On the Collector stability meeting yesterday I suggested that we wait until the project-wide OTEP is done on this regard so that the implementation we do is aligned with that.
> I am not seeing motivation / justification in the description. Why is this needed? It adds redundancy in the configuration. Does it unblock any scenarios not already possible? @yurishkuro...
@yurishkuro No, that's not what I mean, I think the best example are keepalives in `configgrpc`. [`configgrpc.ClientConfig`](https://pkg.go.dev/go.opentelemetry.io/collector/config/configgrpc#ClientConfig) has a `Keepalive` field that [is a `configoptional.Some` by default](https://github.com/open-telemetry/opentelemetry-collector/blob/config/configgrpc/v0.137.0/config/configgrpc/configgrpc.go#L119). That means that...
`CookiesConfig` and other empty sections can work fine with this: diff for CookiesConfig ```diff diff --git a/config/confighttp/client.go b/config/confighttp/client.go index 41e5dd1b5..f6a2b946c 100644 --- a/config/confighttp/client.go +++ b/config/confighttp/client.go @@ -101,7 +101,7 @@ type...
@dfawley It would be useful to understand why these packages cannot be published as separate modules. This should solve most of the concerns from your side about compilation, wouldn't it?...
Apologies for the delay. I had not realized that "These packages are direct dependencies of grpc itself." which complicates things a bit. Nonetheless I still think we can avoid this...