[receiver/aerospike] Determine future of component

[TylerHelmuth]

Component(s)

receiver/aerospike

Details

We have a problem right now where we can't upgrade github.com/aerospike/aerospike-client-go, the core dependency of the Aerospike Receiver, due to a proto name conflict. We've made several attempts since August 2023, but haven't had any success. We're getting into worrisome territory, where our version is falling behind, and there have been security releases we can't take.

I'm opening this issue not because the code owners have not tried to fix the issue, but because I am worried about maintaining a component with a dependency we can't upgrade. @antonblock @djaglowski what do you want to do here?

Generic Unmaintained Issue Template:

• Wait 6 weeks for the code owner to provide feedback, either here or in the linked issue
• Attempt to recruit new code owners, potentially from the community (cc @antonblock @djaglowski)
• On 2024-07-17, 6 weeks from now, the component will be labeled as unmaintained if the original code owner is still unresponsive and no other code owner for the component has been found
• On 2024-12-05, 6 months from now, the component will be removed

https://github.com/open-telemetry/opentelemetry-collector#unmaintained

Pull requests / Issues

• Bump github.com/aerospike/aerospike-client-go/v6 from 6.13.0 to 6.14.0 causes issues #26265
• Dependencies only support go1.21 #30101
• fix(deps): update module github.com/aerospike/aerospike-client-go/v6 to v7 #30261

[github-actions]

Pinging code owners:

• receiver/aerospike: @djaglowski @antonblock

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[djaglowski]

@khaf, you previously commented here about the potential root cause of the upgrade problem. Do you still think this is the problem and if so, do you have any hope it will be resolved upstream in the client library?

[crobert-1]

Removing unmaintained as a code owner has responded. I understand more discussion is necessary regarding the path forward here, so I'm adding discussion needed. Feel free to correct me if I've missed something.

[khaf]

@djaglowski I thought adding a package name in the manifest would help, but it didn't. What I'm going to do personally is that I'll try to reproduce the issue in open-telemetry and come up with a fix in the Go client. What I need though is a simple shell incantation that would allow me to reproduce the issue. Appreciate your help.

[djaglowski]

@khaf, I noted on the upstream issue here, but I was able to write a unit test which demonstrates the problem. I hope it's helpful. Really appreciate you looking into this.

[djaglowski]

The latest version of the dependency has resolved the underlying issue. I've opened #34244 to perform the upgrade on our end. Thanks again @khaf!