-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Return an error in service.NewConfigProvider
if there is no configLocations (v0.45)
#4762
Conversation
service.NewConfigProvider
if there is no configLocationsservice.NewConfigProvider
if there is no configLocations (v0.45)
Plese rebase. |
d159eac
to
2fedc6e
Compare
Codecov Report
@@ Coverage Diff @@
## main #4762 +/- ##
==========================================
- Coverage 90.66% 90.54% -0.12%
==========================================
Files 182 182
Lines 10621 10656 +35
==========================================
+ Hits 9630 9649 +19
- Misses 774 788 +14
- Partials 217 219 +2
Continue to review full report at Codecov.
|
Should I add entry to changelog? In my last PR |
@noisersup yes add a changelog entry, and rebase so we can merge this. |
2fedc6e
to
9b9d76e
Compare
done |
@noisersup I am sorry, I missed this release, but I think that is good, because I think we can do even better now. What about we start using an Option pattern here, and keep only the locations (as required) field? cc @codeboten @tigrannajaryan @jpkrohling
|
@noisersup looks like we have an agreement here, do you mind implementing that change? |
@bogdandrutu Sure, I'll implement that. |
9b9d76e
to
0c8c405
Compare
I hope I understood the requirements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I documented couple of options. Probably we can extract issues out of these and move forward with the current PR which does improve lots of the things.
service/config_provider.go
Outdated
func WithConfigMapProviders(c map[string]configmapprovider.Provider) ConfigProviderOption { | ||
return func(opts *ConfigProviderOptions) { | ||
opts.configMapProviders = c | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we want a map as argument or one of the next two options:
func WithConfigMapProvider(scheme string, p configmapprovider.Provider) ConfigProviderOption {
return func(opts *ConfigProviderOptions) {
opts.configMapProviders[scheme] = p
}
}
// Change configmapprovider.Provider to have a `Scheme()` func on it.
func WithConfigMapProvider(p configmapprovider.Provider) ConfigProviderOption {
return func(opts *ConfigProviderOptions) {
opts.configMapProviders[p.Scheme()] = p
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to implement both approaches in seperate commits but I have an issue with the first.
Due to the fact that 2 of the functions (service.MustNewConfigProvider
and service.TestConfigProvider_Errors
) that use WithConfigMapProviders
are using map[string]configmapprovider.Provider
approach I need to translate these maps to []ConfigProviderOption
and after that append this array to other Options and pass them to NewConfigProvider
function.
example:
// Convert map[string]configmapprovider.Provider to []ConfigProviderOption
configMapProvidersOpts := []ConfigProviderOption{}
for scheme, provider := range configMapProviders {
configMapProvidersOpts = append(configMapProvidersOpts, WithConfigMapProvider(scheme, provider))
}
configProvider, err := NewConfigProvider(locations, append(configMapProvidersOpts, WithCfgMapConverters(cfgMapConverters), WithConfigUnmarshaler(configUnmarshaler))...)
should I create a function that converts config maps to []ConfigProviderOption
and appends them to provided options
to avoid reused code or it's not that big deal?
func AppendConfigMapProvider(
opts []ConfigProviderOption,
configMapProviders map[string]configmapprovider.Provider) []ConfigProviderOption {
// Convert map[string]configmapprovider.Provider to []ConfigProviderOption
for scheme, provider := range configMapProviders {
opts = append(opts, WithConfigMapProvider(scheme, provider))
}
return opts
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Change configmapprovider.Provider to have a
Scheme()
func on it.
I think I prefer this approach. We require that providers have a scheme anyways, so why not a way to determine what they think their scheme is?
should I create a function that converts config maps to []ConfigProviderOption and appends them to provided options to avoid reused code or it's not that big deal?
An unexported helper function to do this might be useful, but at least service.MustNewConfigProvider()
is expected to go away in the near future, so I'm not sure how big a deal it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I prefer this approach. We require that providers have a scheme anyways, so why not a way to determine what they think their scheme is?
After more thoughts on this, I think is the right thing to do, since this will allow us to use the same pattern in the builder to support more providers - builder will look for NewProvider in the given import (similar to NewFactory for components.
Per @Aneurysm9 comment the service.MustNewConfigProvider()
is going away, and the other one is a test. I would rather look into an example how a distribution with extra providers will use this. Or an example written for this case.
} | ||
} | ||
|
||
func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption { | |
func WithConfigMapConverters(c []config.MapConverterFunc) ConfigProviderOption { |
Consistency is important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption { | ||
return func(opts *configProvider) { | ||
opts.cfgMapConverters = c | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption { | |
return func(opts *configProvider) { | |
opts.cfgMapConverters = c | |
} | |
} | |
func WithConfigMapConverters(c ...config.MapConverterFunc) ConfigProviderOption { | |
return func(opts *configProvider) { | |
opts.cfgMapConverters = append(opts.cfgMapConverters, c...) | |
} | |
} |
I think I would prefer to see these append to the config, allowing for multiple invocations of the options, possibly provided by separate packages. The invocation of NewConfigProvider()
ultimately controls the order in which they're applied. A small change would be required there to set the default values after applying options if the list is empty, rather than setting it first and allowing it to be overwritten.
The same applies to WithConfigMapProviders()
. There order is not important, so multiple maps can be merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am confused about your comment: I think I would prefer to see these append to the config, allowing for multiple invocations of the options, possibly provided by separate packages.
are you suggesting a global?
Even without the "default" problem, your suggestion does not trivially allow "no converters" case.
Also these append thing is unclear to me, I would rather provide only one "Converter" and a "MultiConverter" implementation if the list is a problem.
The title of this PR is no longer adequately descriptive, can you please update it? @open-telemetry/collector-approvers please review this PR as it has changed in scope and may have more significant impact than initially proposed. |
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Description:
As was said in #4734, this commit:
service.NewConfigProvider
to return an error when providedconfigLocations
length is equals to 0,service.MustNewConfigProvider
and makes itpanic
under the same condition as above,When the version 0.44 will come out I will undraft this PR.
Also I'm not sure is it possible to apply only third commit (the previous 2 are from my last PR) but I will remove them when my last PR will be merged.
Link to tracking Issue: #4730
Testing:
make all