[processor/routing] Deprecate component

[djaglowski]

Component(s)

processor/routing

Describe the issue you're reporting

This is a tracking issue relating to open-telemetry/opentelemetry-collector#7370

The processor should be reimplemented as a connector. (See #19738)

We should deprecate the processor once the connector is available.

[github-actions]

Pinging code owners for processor/routing: @jpkrohling @kovrus. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

Pinging code owners:

• processor/routing: @jpkrohling @kovrus

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

[mwear]

If this is up for grabs, I can work on it.

[djaglowski]

@mwear, that would be great. Before we can deprecate this component, we need to implement the connector (see #19738). Are you offering to take that on?

[mwear]

I am volunteering to convert it to a connector first. Should I ask the same on #19738?

[djaglowski]

No, just wanted to make sure. I'll assign the connector issue to you. Thank you for helping with this!

[mwear]

No problem. Thanks for assigning!

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/routing: @jpkrohling @kovrus

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

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/routing: @jpkrohling

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

[mx-psi]

Is there anything blocking this, or has it just not been taken up by anybody?

[djaglowski]

I believe the routing connector only matches the processor's OTTL abilities, which is limited to routing based on resource context. If I recall correctly, there was a discussion about this in a SIG and the decision was to not deprecate the processor until the connector's OTTL abilities could fully match the processor's non-OTTL implementation.

That said, I would not be opposed to deprecating the processor now and expecting that work continues on the connector/ottl to fill the gaps as necessary. Of course we should be confident that it is a full replacement before removing the component though.

[mx-psi]

If we confirm the eventual feature parity, I would vote for deprecating this component, so that we can make progress on open-telemetry/opentelemetry-collector/issues/7370. If the processor is here to stay, then we should think about a way to unblock open-telemetry/opentelemetry-collector/issues/7370 (an intermediate step could be to remove the method from the component.Host interface but still have the underlying struct implement it temporarily)

[djaglowski]

Now that we have a proper way to move data between pipelines, I do not think the processor should be here to stay.

If we confirm the eventual feature parity, I would vote for deprecating this component

Can you clarify what you mean here?

[mx-psi]

Can you clarify what you mean here?

Mostly what you said above: if we confirm that the connector can be a full replacement of the processor, we can deprecate the processor now, even if the connector doesn't have all the features today.

[mwear]

Future feature parity is still on my todo list. I've been busy with component health and the health check extension. That said, the health related work is likely to continue for the foreseeable future. If any wants to own closing the feature gaps, I'd be happy to hand it off, but if nobody gets to it, I'll resume this work when my schedule frees up.