Helm chart for OpenTelemetry Collector

[dmitryax]

Link to tracking Issue: #227

More TODO:

• Other outputs
• Docs
• Tests
• Fill values.schema.json

[naseemkullah]

Looks really good!

Left some comments about wether or not if both collector types are desired, how this should be achieved either by one helm release or two. Also that autoscaling enablement should also depend on standalone being deployed.

[tigrannajaryan]

@dmitryax should we close this since there is a separate repo now?

[dmitryax]

@tigrannajaryan I'd rather finalize the initial PR here to be approved, then close and resubmit it in the helm repo as is.

[codecov]

Codecov Report

Merging #1026 into master will decrease coverage by 0.66%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1026      +/-   ##
==========================================
- Coverage   88.74%   88.08%   -0.67%     
==========================================
  Files         249      249              
  Lines       13295    11801    -1494     
==========================================
- Hits        11799    10395    -1404     
+ Misses       1141     1061      -80     
+ Partials      355      345      -10     

Flag	Coverage Δ
#integration	73.63% <ø> (-1.25%)	⬇️
#unit	87.36% <ø> (-0.61%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
receiver/redisreceiver/interval/interval_runner.go	42.10% <0.00%> (-9.75%)	⬇️
...er/awsxrayreceiver/internal/translator/metadata.go	66.66% <0.00%> (-8.34%)	⬇️
...ver/kubeletstatsreceiver/kubelet/stats_provider.go	55.55% <0.00%> (-8.09%)	⬇️
receiver/redisreceiver/redis_metric.go	63.15% <0.00%> (-6.41%)	⬇️
receiver/receivercreator/receiver.go	67.64% <0.00%> (-6.17%)	⬇️
internal/common/testing/container/container.go	67.64% <0.00%> (-6.17%)	⬇️
receiver/receivercreator/observerhandler.go	60.37% <0.00%> (-5.76%)	⬇️
receiver/kubeletstatsreceiver/kubelet/cert.go	63.63% <0.00%> (-5.60%)	⬇️
receiver/receivercreator/runner.go	48.14% <0.00%> (-5.19%)	⬇️
receiver/kubeletstatsreceiver/kubelet/cpu.go	80.00% <0.00%> (-4.62%)	⬇️
... and 239 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7b89268...ad826da. Read the comment docs.

[naseemkullah]

lgtm, I look forward to trying this out once the helm repo is set up and hosting it!
I do have one non-blocking nit: WDYT about renaming the agent-collector component/agentCollector value to just agent?
The current name makes it sounds like it collects agents.

[dmitryax]

I do have one non-blocking nit: WDYT about renaming the agent-collector component/agentCollector value to just agent?
The current name makes it sounds like it collects agents.

I agree it sounds a bit confusing. I was trying to have some consistency, so used this pair standaloneCollector/agentCollector . Do you suggest standaloneCollector/agent instead?

[naseemkullah]

I do have one non-blocking nit: WDYT about renaming the agent-collector component/agentCollector value to just agent?
The current name makes it sounds like it collects agents.

I agree it sounds a bit confusing. I was trying to have some consistency, so used this pair standaloneCollector/agentCollector . Do you suggest standaloneCollector/agent instead?

Ah I see, I would prefer any of these:

• standaloneCollector/agent
• standalone/agent
• collector/agent

The latter is probably my favorite, despite the service itself having collector in the name but any of these are nicer imho

[dmitryax]

I would lean towards collector/agent as well.

But we might want to introduce another name for the standalone collector which doesn't conflict with otel collector itself. So far I've heard versions like gateway or concentrator ...

@open-telemetry/collector-approvers any thoughts/suggestions on the naming for collector deployed as daemonset against collector deployed as standalone deployment? ^

[owais]

Some SDK libraries also use the term agent to refer to the auto-instrumentation agent for example, Java: https://github.com/open-telemetry/opentelemetry-java-instrumentation/

I guess .Net might do the same once they have auto-instrumentation. So probably better to not call the collector an agent? I don't think it's a huge deal but would be nice if we could use a specific name that can't be confused with other things in the opentelemetry ecosystem.

[keitwb]

I like what @dmitryax did with standaloneCollector/agentCollector, in that it has the term collector in both. However, standalone isn't very descriptive since all of the collectors are technically "stand alone" (not paired with anything else to do it's job).

One thing that has always been confusing to me is the totally different terms used for the same application (agent vs collector) to describe different configurations. Probably calling both of them some variation of collector is the clearest. Maybe centralCollector and hostCollector.

[dmitryax]

BTW choosing the naming we also need to consider how to differentiate other resources names like configmaps etc for each of the components. I added -agent suffix for agentCollector components, and resources used by standaloneCollector don't have a suffix.

[dmitryax]

I'm closing this PR in favor of open-telemetry/opentelemetry-helm-charts#2 .
I kept naming as is for now, and moved our discussion to the issue open-telemetry/opentelemetry-helm-charts#3