Should ConfigValidator be in confmap?

[bogdandrutu]

Is your feature request related to a problem? Please describe.

Currently the ConfigValidator is part of the component package, and for example in mdatagen where we use confmap it is a bit strange to depend on the component.ConfigValidator for config validation.

Describe the solution you'd like

Provide the configuration Validator as part of the confmap repository, and probably make it part of Conf.Unmarshal (configurable) to also do validation.

Describe alternatives you've considered

Leave where it is right now.

[TylerHelmuth]

Is it correct to say from a component developer perspective it doesn't matter where it lives?

[sfc-gh-bdrutu]

Is it correct to say from a component developer perspective it doesn't matter where it lives?

Yes, but if we want to use confmap in other places like I said in mdatagen it is confusing.

[dmitryax]

I agree confmap seems like a better place for it

[mx-psi]

I don't have a strong opinion on this (which makes me lean slightly into "leave it as it is")

[TylerHelmuth]

probably make it part of Conf.Unmarshal (configurable) to also do validation.

Today I believe that otelcol is our collector's use of ConfigValidator. What problem would we be solving by adding something configurable to Conf.Unmarshal?

[mx-psi]

Thinking about this again, I feel like it makes sense to move this to confmap since this should evolve with confmap and if we do a confmap/v2 we would want to be able to change this interface alongside it

[mx-psi]

@bogdandrutu If we were to move this, what would we do with component.ValidateConfig?

[dmitryax]

Do we even need component.ValidateConfig? I can't see any value in it...

[mx-psi]

@dmitryax Here are the places where this is used: https://github.com/search?q=org%3Aopen-telemetry+language%3AGo+component.ValidateConfig&type=code

There are a lot of usages that could be avoided/converted, but I am not confident that we would be able to remove all of them.

[atoulme]

We discussed this issue during the stability SIG meeting of 1/6 and came up with the following suggestions:

1. Move the validation code out of component to an experimental package (prefixed with x)
2. Look at whether this validation code should be moved to stable, or use a new approach, using for example https://github.com/go-playground/validator so we don't implement our own validation framework. A new issue for this will be cut to continue the work.