Add a go.mod for cmd/otel-allocator

[atoulme]

Component(s)

target allocator

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

The target allocator has no links to the rest of the codebase.

Describe the solution you'd like

Define its own go.mod module definition and make tags for its release.

Describe alternatives you've considered

No response

Additional context

No response

[swiatekm]

This used to be the case, and we switched to a single go.mod because it simplified maintenance. See #2317. Why is the common go.mod a problem?

[atoulme]

Since there is no dependency from target-allocator to the rest of the code, it should be made independent and installable via go install. This can allow parts of the codebase to mature independently and be tagged with different version numbers.

[atoulme]

This allows keep clear responsibilities ; whoever is responsible for the code of the target-allocator then gets to review and manage the dependency updates directly without involvement or impact to the rest of the project.

[swiatekm]

Right now, neither of these are an actual problem for the operator maintainers. The same group of people is responsible for the target allocator codebase and the operator codebase. We don't want to have separate versioning or dependency updates for the target allocator, because it's more work without a clear benefit.

It's looking increasingly likely that the target allocator might become a lot more generic, to be able to work with platforms other than K8s and with Prometheus Agents as well as otel collectors. See #3317 for more discussion about that. Then, it's going to make sense to progressively detach the target allocator from the operator, culminating in moving it to a separate repository, potentially in the Prometheus org. We're not yet at that point, though.

[atoulme]

Is this allocator roadmap discussed in an issue somewhere? I would like to understand how this is shaping.