[META] Config: Tasks to reach agent config parity

[jackshirazi]

Tasks

Beta Give feedback

1. Config: Add a reconciliation test to reconcile the existing agent config with the new agent config so that nothing is missed and documentation is consistent #34
   +0
   
2. Config: Implement a couple of options to extend the configuration framework beyond reconciliation, including applying those to the agent through the delegated AutoConfigurationCustomizerProvider.addPropertiesSupplier() #35
   +0
   
3. Config: Implement (re-)loading options from properties #36
   +0
4. Config: Implement (re-)loading options from a properties file #37
   +0
5. Config: Implement (re-)loading options from env variables #38
   +0
6. Config: Implement remaining unimplemented options (needs multiple phases as there are over 100 options)
7. Add a new connection config option for central config: central_config_url #42
   +0
8. Config: Implement (re-)loading options from central config using v2 protocol #39
   +0
9. [OpAMP] implementation for central config #40
   +0
   

[jackshirazi]

Looking through a few of the configs, it's going to be an extensive task to get close to feature parity. Some issues

• The Otel agent is mainly architected for static configuration defined at startup and is really not designed dynamic changes. Retrofitting dynamic support will be extremely hard
• The AutoConfigurationCustomizerProvider is not really designed for resetting defaults, even though it claims to. Effectively the 2 config setters overwrite whatever is there, and provide something where nothing is. For example see this discussion on setting the server URL defaults
• otel.javaagent.enabled (which enables/disables the agent instrumentation) is read before agent initialization, so can't be set by an extension
• The otel equivalent of trace_methods is otel.instrumentation.methods.include which doesn't support wildcards. As the wildcard tracing is really really useful (so many customer and SA and support investigations have used it), we will need to either use our implementation or implement it into the otel one
• Changing sampling can be done dynamically and may be a useful mechanism to "turn off" the agent - but doesn't turn off metrics or log sending
• otel.javaagent.debug is true or false, so either all non-debug is output, or everything is output, rather than the various levels we have; additionally it's only read at startup before the properties can be set in an extension (it adds a logging span processor) so this looks yet again painful

[jackshirazi]

Closing this, next steps covered in #300