Add homebrew core formulae for ocb & collector

[svrnm]

This is a follow up issue to #5680 & #5689 by @jpeach (and maybe other similar requests to release ocb and collectro to homebrew)

Is your feature request related to a problem? Please describe.

Many MacOS users make use of homebrew, "the missing package manager for macOS", and many OSS projects are represented there. By adding ocb & otel collector there as well, we can make it easier for end-users to install both tools and make use of them.

Describe the solution you'd like
For my day job I am currently investigating homebrew, how it works, etc., so it came naturally to me to try out if I can get the collector (and ocb) packed into a formula. Here are the results:

• opentelemetry-collector-contrib.rb
• ocb.rb

I worked through the requirements to publish both on homebrew-core and both are more or less ready to be pushed via a PR.

Before doing that I wanted to do a sanity check with the collector community. @open-telemetry/collector-approvers / @open-telemetry/collector-maintainers shall I move forward with those two PRs or are there any concerns I might need to look into upfront?

Describe alternatives you've considered
As discussed in #5680 the OpenTelemetry community could host their own tap, but actually having the packages put into homebrew-core is much better: no own infrastructure is needed and more end-users are reached since they get access to the packages without the need of adding a 3rd party repository

[atoulme]

This seems in line with a new effort around packaging. Would you be open to discuss a packaging SIG that would look at this type of deliverable?

[svrnm]

This seems in line with a new effort around packaging.

I am not aware of that, can you share some context?

Would you be open to discuss a packaging SIG that would look at this type of deliverable?

If I understand the idea correctly this would be something happening across SIGs, not only for the collector?

[atoulme]

Yes, a new effort across the project.

[svrnm]

Makes sense, I think this is a good idea, although it's a question of capacity to staff such an effort.

[mx-psi]

@svrnm who would maintain the formula? Would this be on homebrew's maintainers? Would the Collector maintainers handle issues?

[jpeach]

OpenTelemetry community could host their own tap, but actually having the packages put into homebrew-core is much better:

FWIW, the infrastructure needed to host a tap is a git repository. goreleaser supports releasing to a tap, and IIRC the project already releases using goreleaser. So if you go the tap route, there's virtually no maintenance.

[svrnm]

@svrnm who would maintain the formula? Would this be on homebrew's maintainers? Would the Collector maintainers handle issues?

There's 2 options with advantages and disadvantages

• Operate our own tap, as outlined here: https://docs.brew.sh/How-to-Create-and-Maintain-a-Tap
  • As @jpeach stated the maintenance overhead is fairly low, you need a repository in a fixed structure and that's it. I operate one for Cisco Open, see here: https://github.com/cisco-open/homebrew-tap
  • Also, as @jpeach said you can use goreleaser (for go projects) to submit to that repository, the one project hosted over at the cisco open homebrew tap is actually doing that, so you can take a look how this looks like
  • Overall the big plus is control, the otel community owns and operates the tap and is on control of releases, etc. (see the section "Official Vendor Taps" in the doc on taps shared above as well)
  • Big minus is that when I do a brew search I will not found the tap out of the box (
• Provide formulae (their name for packages) to https://github.com/Homebrew/homebrew-core
  • Big big plus is discoverability and user expectations, by being included in core end-users can find OpenTelemetry packages by simply running brew search opentelemetry or brew search otel etc.
  • Another related plus is, that nobody can be stopped from providing formulae for opentelemetry artifacts to core, e.g. there is one for opentelemetry-cpp already
  • Another plus: Although a tap seems to be "easy to maintain", it is still something that needs work and attention, and people who learn how those taps work, etc (read into bottles if you really want to get a feeling of that). By providing the formulae via homebrew core, this is done by subject matter experts (aka the homebrew community) and otel contributors can focus on other things
  • Disadvantage is that we give up control over these packages
  • It's also important to note that formulae submitted to the core have stronger requirements (see https://docs.brew.sh/Acceptable-Formulae)
  • There is also this statement "We frown on authors submitting their own work unless it is very popular.", also I argue that otel is popular enough

My personal opinion is still that going down the road of being in the homebrew core is the preferable way: the user expectation and the fact that this will happen with our without us eventually anyhow are strong enough reasons that outweigh the other ones.

Final note: if we think there is a reason to keep a balance, it is of course possible to operate our own tap AND have the packages upstream.

[mx-psi]

Thanks for the summary! I am in favor of having a homebrew-core formula, I don't mind it being out of our control. I don't have an opinion on whether we are popular enough 😅

If darwin/amd64 binaries are released, I would like to fix #9114 first though: more usage on macOS will potentially lead to more issues, and right now we don't have anyone that is assigned to solve darwin/amd64 specific issues. It would also be nice to have more people owning darwin/arm64 issues if anyone wants to offer their help :)

[svrnm]

Thanks for the summary! I am in favor of having a homebrew-core formula, I don't mind it being out of our control. I don't have an opinion on whether we are popular enough 😅

As one of the larger CNCF projects I would argue that otel is popular enough, but worst case a PR gets rejects 🤷‍♂️

BTW, interesting in this context as well: Homebrew/homebrew-core#155035 -- there is some automation Grafana is using, we can learn from that.

If darwin/amd64 binaries are released, I would like to fix #9114 first though: more usage on macOS will potentially lead to more issues, and right now we don't have anyone that is assigned to solve darwin/amd64 specific issues. It would also be nice to have more people owning darwin/arm64 issues if anyone wants to offer their help :)

People that complain and raise issues can step up to become owners :-P

[edigaryev]

I've tried submitting a PR that includes a formula for OpenTelemetry Collector (contrib) to the Homebrew Core, and it was rejected with the following reasons:

• potential re-tagging: otelcol-contrib 0.92.0 (new formula) Homebrew/homebrew-core#160730 (comment)
• unstable version: otelcol-contrib 0.92.0 (new formula) Homebrew/homebrew-core#160730 (comment)

If I understand right, the second issue will be fixed by open-telemetry/community#1887, but I'm not sure about the first one, are there any plans to change that policy?

[mx-psi]

I commented on the original PR, since I think this is a misunderstanding

[svrnm]

thank you @mx-psi, looks like the plan is:

• wait for collector 1.0 release
• update that wording / rethink that policy
• make another PR

This may take a few more months I guess, but I think this would not justify to create an intermediate solution with an otel community owned tap

[mx-psi]

wait for collector 1.0 release

Actually I don't think this is what Homebrew/homebrew-core#160730 (comment) is talking about; there are plenty of formulas here https://formulae.brew.sh/formula/ that are 0.x, I think it refers to 'having a version at all'

[svrnm]

wait for collector 1.0 release

Actually I don't think this is what Homebrew/homebrew-core#160730 (comment) is talking about; there are plenty of formulas here formulae.brew.sh/formula that are 0.x, I think it refers to 'having a version at all'

Ok, then I don't understand the violation

[svrnm]

wait for collector 1.0 release

Actually I don't think this is what Homebrew/homebrew-core#160730 (comment) is talking about; there are plenty of formulas here formulae.brew.sh/formula that are 0.x, I think it refers to 'having a version at all'

Ok, then I don't understand the violation

I might have chosen my words poorly and this good come across incorrectly: If the vioalation is not that collector is still 0.x, can someone explain to me what this might actually mean and what we need to do to unblock it?

[mx-psi]

My interpretation of

Formulae in the core repository must have a stable version tagged by the upstream project.

Is that you can't just have a tarball that does not have any version: the upstream project needs to decide on the version and clearly label artifacts with said version, Homebrew will not do that for a project.

By "stable" I believe they mean that the association between version and artifact does not change (which is what they thought happened with the Collector)

[svrnm]

thanks for clarification @mx-psi, this makes sense.