Skip to content

Decide on one (or more) formats for configuration files #564

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ocelotl opened this issue Apr 8, 2020 · 10 comments
Closed

Decide on one (or more) formats for configuration files #564

ocelotl opened this issue Apr 8, 2020 · 10 comments
Assignees
Labels
api Affects the API package. discussion Issue or PR that needs/is extended discussion. enhancement New feature or request

Comments

@ocelotl
Copy link
Contributor

ocelotl commented Apr 8, 2020

This issue is related to #555

#466 introduced a configuration manager. Currently, it only reads from environment variables. For configuration files to be read, then it is necessary to define a few things first:

  1. Where the configuration file would be located?
  2. Do we want several formats to be supported or only one?
  3. Which format or formats do we want to support?

Here are some formats for consideration:

  1. JSON
  2. YAML
  3. TOML
  4. Python (like Django does for its settings file)
  5. INI

Please leave your thoughts about this in the comments below.

@ocelotl ocelotl added enhancement New feature or request discussion Issue or PR that needs/is extended discussion. api Affects the API package. labels Apr 8, 2020
@ocelotl ocelotl self-assigned this Apr 8, 2020
@mauriciovasquezbernal
Copy link
Member

mauriciovasquezbernal commented Apr 13, 2020

My 2cents: Supporting more than 1 format is a bad idea, users will be confused about with one is the correct one and what are the differences, we should also maintain them...

About the formats, I'd discard JSON because it doesn't support comment, I'd also discard INI because it only supports one level hierarchy tree. About the remaining ones I think yaml is the most used, so what would be my choice.

@codeboten
Copy link
Contributor

codeboten commented Jun 11, 2020

Would love to see some progress on this discussion.... could we vote:

👍 JSON
❤️ YAML
🎉 TOML
🚀 Python (like Django does for its settings file)
😄 INI

@toumorokoshi
Copy link
Member

I thing I'll call out that json and ini files I'd explicitly vote against.

ini files have no ability to do nested data structures, and as a result you end up writing a hacky way to express them.

json is hard to read and fairly error-prone (the fact that trailing commas are not allowed and error messages don't make that clear has made hand-editing json a trial, IME).

@codeboten
Copy link
Contributor

worth nothing the collector uses yaml

@majorgreys
Copy link
Contributor

Seems like the decision is between toml or yaml. Consistency across OpenTelemetry projects would be nice but I give more weight to the one more commonly used in each language. Given that I would vote for toml with it's ini style syntax.

@aabmass
Copy link
Member

aabmass commented Jun 12, 2020

I voted YAML but I don't want to be the tie breaker lol

@Renz2018
Copy link

yaml is the most used

@ocelotl
Copy link
Contributor Author

ocelotl commented Jun 17, 2020

Does this mean that we can decide for YAML?

@lzchen
Copy link
Contributor

lzchen commented Jun 19, 2020

+1 for YAH-mal

@ocelotl
Copy link
Contributor Author

ocelotl commented Jul 10, 2020

@lzchen @toumorokoshi

It seems like YAML is the chosen one. Can we close this issue?

srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this issue Nov 1, 2020
…metry#564)

* docs: add usage for mongodb-core plugin open-telemetry#543

* Update packages/opentelemetry-plugin-mongodb-core/README.md

Co-Authored-By: Mayur Kale <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Affects the API package. discussion Issue or PR that needs/is extended discussion. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

8 participants