Paschalis Tsilias

It's something for later on, when we're ready to merge, but let's make sure we also include a converter in the [otelconvert](https://github.com/grafana/agent/tree/main/internal/converter/internal/otelcolconvert) package? We can help with that.

Could this also apply to loki.rules.kubernetes?

I'm not convinced this is the right solution; feels too arbitrary. One of clustering's main assumptions is that all nodes run with the same configuration files and that the upstream...

Which helm chart are you using? The latest Agent helm chart does allow overriding the registry: https://github.com/grafana/agent/blob/main/operations/helm/charts/grafana-agent/values.yaml#L13

After thinking back at how proposals were handled in the last couple of years, I'd also be in favor of trying this out. Things I liked: * Switching focus back...

But also, > We try, whenever possible, to resolve these issues without breaking compatibility. It's always a tradeoff, but I think it's a good opportunity to try and fix this...

I don't see the benefit of removing the translation layer though. Do you anticipate there being it an effort to maintain? On surface it sounds like a simple string-to-string mapping...

How would you feel about starting off with a subset of these? Eg. I can't see how someone could use the value of `flags.disable_reporting` or `flags.extra_args` to configure a component...

The answer is.. this kinda exists today already. In Alloy's built-in debug UI, you can see the endpoint that each exporter component exposes internally (eg. localhost:12345/api/v0/component/prometheus.exporter.self.LABEL/metrics`). This uses an unversioned...

Yeah, you're right, I see, thanks. I've amended the comment above.