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

Return an error in service.NewConfigProvider if there is no configLocations (v0.45) #4762

Closed
wants to merge 3 commits into from

Conversation

noisersup
Copy link
Contributor

Description:
As was said in #4734, this commit:

  • changes service.NewConfigProvider to return an error when provided configLocations length is equals to 0,
  • deprecates service.MustNewConfigProvider and makes it panic under the same condition as above,
  • changes back all references in code from "Must" version to normal and handles error.

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

@noisersup noisersup changed the title Return an error in service.NewConfigProvider if there is no configLocations Return an error in service.NewConfigProvider if there is no configLocations (v0.45) Jan 28, 2022
@bogdandrutu
Copy link
Member

Plese rebase.

@bogdandrutu bogdandrutu added this to the v0.45.0 milestone Feb 1, 2022
@codecov
Copy link

codecov bot commented Feb 1, 2022

Codecov Report

Merging #4762 (e55d31a) into main (89e0d42) will decrease coverage by 0.11%.
The diff coverage is 87.50%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
service/command.go 73.91% <87.50%> (-8.44%) ⬇️
service/config_provider.go 90.44% <87.50%> (-3.96%) ⬇️
service/collector.go 71.14% <0.00%> (-4.03%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 89e0d42...e55d31a. Read the comment docs.

@noisersup noisersup marked this pull request as ready for review February 6, 2022 08:41
@noisersup noisersup requested review from a team and bogdandrutu February 6, 2022 08:41
@noisersup
Copy link
Contributor Author

Should I add entry to changelog?

In my last PR Skip Changelog flag was added.

@bogdandrutu
Copy link
Member

@noisersup yes add a changelog entry, and rebase so we can merge this.

@noisersup
Copy link
Contributor Author

done

@bogdandrutu
Copy link
Member

@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

func NewConfigProvider(locations []string, opts ...ConfigProviderOption) (ConfigProvider, error) {
}

@bogdandrutu
Copy link
Member

@noisersup looks like we have an agreement here, do you mind implementing that change?

@noisersup
Copy link
Contributor Author

@bogdandrutu Sure, I'll implement that.

@noisersup
Copy link
Contributor Author

I hope I understood the requirements

Copy link
Member

@bogdandrutu bogdandrutu left a 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.

Comment on lines 90 to 94
func WithConfigMapProviders(c map[string]configmapprovider.Provider) ConfigProviderOption {
return func(opts *ConfigProviderOptions) {
opts.configMapProviders = c
}
}
Copy link
Member

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
	}
}

Copy link
Contributor Author

@noisersup noisersup Feb 21, 2022

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
}

Copy link
Member

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.

Copy link
Member

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.

service/config_provider.go Outdated Show resolved Hide resolved
service/config_provider.go Outdated Show resolved Hide resolved
service/config_provider.go Outdated Show resolved Hide resolved
service/config_provider.go Outdated Show resolved Hide resolved
}
}

func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption {
func WithConfigMapConverters(c []config.MapConverterFunc) ConfigProviderOption {

Consistency is important.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

service/config_provider.go Show resolved Hide resolved
Comment on lines +88 to +92
func WithCfgMapConverters(c []config.MapConverterFunc) ConfigProviderOption {
return func(opts *configProvider) {
opts.cfgMapConverters = c
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Member

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.

@Aneurysm9
Copy link
Member

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.

@github-actions
Copy link
Contributor

github-actions bot commented Mar 9, 2022

This PR was marked stale due to lack of activity. It will be closed in 14 days.

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 this pull request may close these issues.

3 participants