Open f7o opened 1 month ago
Pinging code owners:
extension/headerssetter: @jpkrohling
See Adding Labels via Comments if you do not have permissions to add labels yourself.
@f7o Makes sense to me, are you interested in contribute it?
@Frapschen yeah, sure
oh wait a minute. looking at the code I believe this functionally could be achieved by something like this:
headers:
- action: upsert
key: X-TENANT
from_context: X-TENANT
- action: insert
key: X-TENANT
value: some-tenant
I believe it would first try to set it from context, even if it's empty. But second set the value only if first header does not set it. I'll test this before continue implementing the new config field.
@jpkrohling have you had this use case before?
I believe that's correct: an upsert of a fixed value would cause it to act as a default value.
I tried the following
- action: upsert
key: X-NAMESPACE
from_context: X-TENANT
- action: insert
key: X-NAMESPACE
value: sre-test
This apparently does not work if X-TENANT
is not provided in upstream metadata. I'll continue implement the default_value config. It does not add the header at all, once I enable the header upstream the first rule matches and picks and sets the header from upstream.
Component(s)
extension/headerssetter
Is your feature request related to a problem? Please describe.
When using the header setter with
from_context
configuration set, and the key is not set within context from receiver, the header is set to nil on the exporter.Describe the solution you'd like
Describe alternatives you've considered
Allow to specify a default value per header action in case
X-TENANT
on the provided context is empty/nilAdditional context
No response