Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OTEL plugin: the header_type parameter is deprecated, please update your configuration to use propagation.extract and propagation.inject instead #13202

Closed
1 task done
garciasdos opened this issue Jun 13, 2024 · 2 comments · Fixed by #13220

Comments

@garciasdos
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Kong version ($ kong version)

Kong 3.7.0

Current Behavior

When any service call reaches this plugin, I get a warning message:

kong-1  | 2024/06/13 11:39:50 [warn] 5363#0: *6481 [kong] init.lua:86 [opentelemetry] the header_type parameter is deprecated, please update your configuration to use propagation.extract and propagation.inject instead, client: 192.168.65.1

Here's my opentelemetry plugin configuration:

  - name: opentelemetry
    id: 9e7fdd24-d119-40b7-8e7c-75e8042fd59d
    protocols:
      - grpc
      - grpcs
    tags:
      - global-plugin
    enabled: true
    config:
      endpoint: $ENDPOINT
      resource_attributes:
        ...
      headers:
        api-key: $KEY

but header_type is not being modified elsewhere

Expected Behavior

When any service call reaches this plugin, I should not get a warning message if no custom configuration was made

Steps To Reproduce

  1. Launch a kong 3.7 project
  2. Add the opentelemetry OSS plugin
  3. Do not modify the header_type attribute

Anything else?

No response

@StarlightIbuki
Copy link
Contributor

A possible cause of the issue: are you using decK? The old default value "preserve" could trigger the warning.
@samugi Could you take a look?

@samugi samugi linked a pull request Jun 17, 2024 that will close this issue
3 tasks
@samugi
Copy link
Member

samugi commented Jun 17, 2024

There are indeed redundant warnings, we have proper logic during schema validation that prevent this from happening when the value used is the default, but the ones logged during header propagation setup did not have a check for that. I removed them and attached the PR. Thanks for reporting @garciasdos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants