[receiver/zipkin] move global server configuration parameters to a separate parameter #35851
Conversation
github-actions
bot
requested review from
andrzej-stencel,
crobert-1 and
MovieStoreGuy
odubajDT
changed the title
odubajDT
force-pushed
the
refactor-zipkinreceiver
branch
from
19be99b
to
d7fe5ae
Compare
|
@andrzej-stencel would you please have time for a review? |
odubajDT
force-pushed
the
refactor-zipkinreceiver
branch
from
0fc263b
to
ca05388
Compare
| # Use this changelog template to create an entry for release notes. | ||
|
|
||
| # One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
| change_type: breaking |
There was a problem hiding this comment.
Can you explain why marking this as a breaking change?
There was a problem hiding this comment.
it's changing the configuration of the receiver even if it's changed behind a feature gate, but the user will be affected if the feature gate will be turned on/off. Do you consider this more as a deprecation?
odubajDT
force-pushed
the
refactor-zipkinreceiver
branch
from
4a31165
to
8a59a9a
Compare
…parate parameter Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Co-authored-by: Andrzej Stencel <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
odubajDT
force-pushed
the
refactor-zipkinreceiver
branch
from
5c8e10f
to
c476c08
Compare
| return fmt.Errorf(deprecationConfigMsg) | ||
| } | ||
| if isServerConfigDefined(cfg.Protocols.HTTP) { | ||
| return fmt.Errorf("cannot use .protocols.http together with default server config setup") |
There was a problem hiding this comment.
I'm afraid that with the current implementation of this change, the collector will fail to start also when user does not specify the protocols::http configuration. This is because the protocols::http configuration is part of the default config. As a result, collector will fail to start with this config:
receivers:
zipkin:
endpoint: localhost:1234To fix this, I propose to follow the approach that the OTLP receiver does here. It implements the Unmarshal method on the config where it removes the part of the default config that was not set by the user (the conf structure only contains config options set by the user).
| ) | ||
|
|
||
| const deprecationConfigMsg = "the inline setting of http server parameters has been deprecated, please use .protocols.http parameter instead." |
There was a problem hiding this comment.
| const deprecationConfigMsg = "the inline setting of http server parameters has been deprecated, please use .protocols.http parameter instead." | |
| const deprecationConfigMsg = "the inline setting of http server parameters has been deprecated, please use protocols::http parameter instead." |
| return fmt.Errorf(deprecationConfigMsg) | ||
| } | ||
| if isServerConfigDefined(cfg.Protocols.HTTP) { | ||
| return fmt.Errorf("cannot use .protocols.http together with default server config setup") |
There was a problem hiding this comment.
| return fmt.Errorf("cannot use .protocols.http together with default server config setup") | |
| return fmt.Errorf("cannot use protocols::http together with default server config setup") |
| } | ||
|
|
||
| var _ component.Config = (*Config)(nil) | ||
|
|
||
| // Validate checks the receiver configuration is valid | ||
| func (cfg *Config) Validate() error { | ||
| if isServerConfigDefined(cfg.ServerConfig) { | ||
| if disallowHTTPDefaultProtocol.IsEnabled() { | ||
| return fmt.Errorf(deprecationConfigMsg) |
There was a problem hiding this comment.
I'm not sure if re-using the deprecation warning message as the error message when the feature gate is enabled will be clear enough for the users when they see it.
Description
Move global server configuration parameters to a separate parameter under
protocolsparameter to allow future support of different protocols (like UDP), more context hereLink to tracking issue
Fixes #35730
Testing
Documentation