Add Python prototype

[ocelotl]

This is a configuration prototype in Python.

AFAIK, other prototypes currently parse the configuration file into a certain, language-specific model, then use if/elses to query this model, depending on what is found in the model with this querying actual objects are created.

This approach has a few disadvantages:

1. It requires manual if/else querying.
2. It doesn't guarantee a complete implementation of all the possible scenarios that any configuration file may have.

The previous point 2 requires a bit more explanation. For example, a configuration implementation that manually does if/else querying of the model may miss a possible scenario that is included in the configuration file but is not implemented. For example, a tracer provider may have batch and simple span processors, but maybe the implementation only queries the configuration model for batch, forgetting about simple. For someone implementing the configuration model in this way, it is easy to make this kind of mistake because it is not obvious from any configuration file or the schema which are all the possible configuration scenarios.

This prototype implements configuration in a different way.

It first resolves the schema, by replacing all the external $defs in the schema with their actual definition. This produces a complete tree representation of the schema.

Then it recursively traverses the schema tree to find all the possible paths. With this information, it writes a Python file with one function per schema path. The arguments that these functions receive are taken from the schema. All these functions are associated with their schema path in a Python dictionary.

Now, I implemented the content of these functions (so far I have only implemented the content of the functions that are related to Resource and TracerProvider creation). It is important to mention here that this means that this prototype can also have an incomplete implementation (as mentioned in point 2 above), but in this case it is clear for whoever is implementing this what is missing from the implementation: the functions whose content has not been implemented yet.

Finally, this prototype takes the configuration file, parses it into a Python dictionary (which is another tree representation). It recursively traverses this tree and when it finds a node it this tree it calls the function associated with this node path. For example, to create a resource:

It first finds the resource node in the configuration tree. It traverses through all the attributes and finds that first it needs to create the object for attributes, so it recursively keeps traversing the configuration tree until it finds the resource/attributes node. Since all the attributes for resource/attributes are terminal (strings, ints, floats, booleans), they can be used right away to create the attributes object. This object is recursively returned to the resource node which can now complete the creation of the Resource object which is finally returned.

To try this prototype, install nox, go to the opentelemetry-configuration/prototypes/python directory and run:

nox -- -s -vvvv -k test_create --pdb

This will run this test case which uses a "kitchen sink" configuration file (without samplers, more about that later). In that test case a Resource object is created first, followed by a TracerProvider object. The execution will stop in every function that is called to create those objects. Use c to move forward. Type the name of any function attribute to check its value.

The current schema has a recursive definition for the Samplers. This doesn't work with this implementation because it is not possible to define the paths for a sampler if the sampler can include infinite other samplers. I think that we don't need a recursive definition of the samplers (I don't think anyone needs to define a sampler that includes an arbitrarily long sequence of nested samplers). I think to solve this situation we can separate the definition of samplers into samplers that can contain one sampler and terminal samplers which are contained by other samplers.

[jack-berg]

Closing since this repository is not meant to house implementations of file configuration.