feat(config): add additionalProperties support to generated config models

[MikeGoldsmith]

Description

Adds support for JSON Schema additionalProperties to the generated config dataclasses. This is the foundation for plugin/custom component loading in declarative file configuration — unknown component names (e.g. my_custom_sampler, my_custom_exporter) can now flow through typed dataclasses without being silently dropped.

Problem

The OTel configuration JSON schema defines additionalProperties on 12 types (Sampler, SpanExporter, TextMapPropagator, ExperimentalResourceDetector, LogRecordExporter, PushMetricExporter, etc.) to allow plugin component names as keys. However, datamodel-codegen ignores additionalProperties when generating plain Python dataclasses — there's no stdlib mechanism for it. Unknown kwargs are rejected by the dataclass __init__.

Solution

A custom datamodel-codegen template (opentelemetry-sdk/codegen/dataclass.jinja2) conditionally adds two things to affected classes:

1. @_additional_properties_support decorator — wraps the dataclass __init__ to route unknown kwargs into an additional_properties instance attribute instead of raising TypeError
2. additional_properties: ClassVar[dict[str, Any]] annotation — satisfies type checkers without creating a dataclass field, so additional_properties doesn't appear in __init__ signature, dataclasses.fields(), asdict(), or repr()

The decorator preserves the original inspect.signature() (for IDE autocompletion) and appends **kwargs to signal extras are accepted.

How it works

The template checks additionalPropertiesType, a context variable that datamodel-codegen sets for schema types where additionalProperties is a type object (e.g. {"type": ["object", "null"]}). This is how the OTel schema defines it for plugin-capable types.

Usage

from opentelemetry.sdk._configuration.models import Sampler

# Known sampler — works as before
s = Sampler(always_on={})
assert s.always_on == {}
assert s.additional_properties == {}

# Plugin sampler — unknown name captured
s = Sampler(my_custom_sampler={"ratio": 0.5})
assert s.additional_properties == {"my_custom_sampler": {"ratio": 0.5}}

Codegen

No changes to the codegen workflow — tox -e generate-config-from-jsonschema picks up the custom template via the custom-template-dir config in pyproject.toml.

Tests

• TestAdditionalPropertiesSupport — 5 unit tests for the decorator (known fields, unknown fields, mixed, empty, signature preservation)
• TestGeneratedModelsHaveAdditionalProperties — 6 regression tests verifying the key generated models accept unknown kwargs (guards against datamodel-codegen changing how it passes the template variable)

[herin049]

Something that I've been thinking about is if we want file configuration to be its own package entirely. I'm not sure if you have measured the code size yet, but I would imagine that as more features are added, it won't be insignificant. It would be good to at least provide users the option to not install file-based configuration, perhaps in very simple/minimal environments.

[MikeGoldsmith]

I understand the concern, but I don't think we're adding too much bloat here. Also, if we move to a separate package, the user experience of "it just works" will be broken.

The models are generated at dev-time and source controlled. The deps to build the models (JSON schema and jinja template) won't be included in the dist package either.

I hope to unify the env var & file config paths to leverage these generated models if I can so they'll be useful for both scenarios.

Does that help?