Decide what configuration lives in "root" of schema

[jack-berg]

Let's try to get consensus on a small piece of the initial target configuration conversation by talking about whether configuration should lean towards being more nested or flat.

Option 1: Everything in root Put everything in root and use prefixes to keys to disambiguate where similar concepts exist (i.e. both traces and logs have processors so call them span_processors and log_record_processors. Results in flatter configuration that is less organized because configuration for a signal isn't necessarily grouped together (i.e. I can configure span processors, then metric views, then span limits). Not clear where configuration of SDK starts / stops versus instrumentation.

Example:

resource: ...
limits: ...
propagators: ...
logging:
  level: info
exporters: # Array of named exporters to be referenced in processors / readers
  - ...
  - ...
span_processors:
  - ...
  - ...
span_limits: ...
metric_readers:
 - ...
 - ...
metric_views:
  - ...
  - ...
log_record_processors:
  - ...
  - ...
log_limits: ...
http_client_request_headers: ...
http_client_response_headers: ...
...

Option 2: Nest everything

The opposite of option 1. Nest everything under respective sections. Results in more nesting but clear organization and boundaries (i.e. all trace configuration will always be grouped together, all metric configuration will be grouped together, etc).

Example:

sdk:
  resource: ...
  logging:
    level: info
  limits: ...
  exporters: # Array of named exporters to be referenced in processors / readers
    - ...
    - ....
  tracer_provider:
    span_processors:
      - ...
      - ...
    span_limits: ...  
  meter_provider:
    metric_readers:
      - ...
      - ...
    views:
       - ...
       - ....  
  logger_provider:
    log_record_processors:
      - ...
      - ...
    span_limits: ...  
instrumentation:
  http:
     client:
       request_headers: ...
       response_headers: ...

Option 3: Something in between

Separate SDK configuration from instrumentation, but minimize nesting within those sections. Try to strike a balance between organizing related concepts without excessive nesting.

Example:

sdk:
  resource: ...
  logging:
    level: info
  limits: ...
  exporters: # Array of named exporters to be referenced in processors / readers
  span_processors:
    - ...
    - ...
  span_limits: ...  
  metric_readers:
    - ...
    - ...
  metric_views:
     - ...
     - ....  
  log_record_processors:
    - ...
    - ...
  span_limits: ...  
instrumentation:
  http_client_request_headers: ...
  http_client_response_headers: ...

[codeboten]

As a starting point, I would suggest we use option #2. More nesting makes it a little bit more clunky to use, but i also think it removes some ambiguity as to what should and shouldn't be nested. This should allow us to move forward without getting hung up on implementation details for the initial version of this work.

We can always re-iterate in future versions.