Sensu-go: Finalize configuration file format

[portertech]

The Sensu Go agent and backend services will support configuration via several means, by command arguments, environment variables, and a SINGLE configuration file. We have yet to declare what the configuration file format is.

Some possible formats:

• TOML
• JSON
• YAML

Me must keep in mind "custom" nested configuration options (attributes).

One we settle on a configuration file format, the Sensu Go services must be updated to support it (if necessary).

[jamesdphillips]

re. format: I guess with viper we could support all three formats but it would make sense to only _openly support_ one format to simply documentation and customer support.

• json
  
  
  
  • simple
  
  
  • too simple; no support for comments
  
  
  • commas always trip people up
  
  
• yaml
  
  
  
  • not as simple
  
  
  • supports comments
  
  
  • indentation can throw people off /shrug
  
  
• TOML
  
  
  
  • simple enough
  
  
  • looks like INI format but actually has a strict definition
  
  
  • supports comments and deeply nested structures (unlike INI)
  
  
  • becoming more popular with new projects (cargo, etc.)
  
  
  • imho TOML is the porridge that is not too hot, nor too cold.
  
  

my two cents.

[portertech]

[portertech]

YAML :heart:

JSON :tada:

TOML :+1:

OTHER :-1:

[amdprophet]

• JSON
  
  
  
  • Not sure JSON is the right choice for Sensu 2.0 as installs won't always be driven by CM
  
  
  • Works great with deeply nested data
  
  
• YAML
  
  
  
  • Tidy, easy to read, supports comments
  
  
  • I've seen indentation problems cause a lot of support grief on other open source projects
  
  
• TOML
  
  
  
  • Seems great for sensu-cli config / profiles
  
  
  • Worried about what deeply nested structures look like
  
  

I think we should be open to using TOML for the cli tool but another language for agent / backend. Sensu cli will use user / local configurations stored in ~/.config/sensu.

[portertech]

One reason I consider TOML is Habitat's use https://github.com/habitat-sh

[portertech]

Only because Habitat reminded me that some people still like TOML.

[jamesdphillips]

TOML... Worried about what deeply nested structures look like

It would be pretty messy if things got deep. For instance: I wouldn't want to write a docker compose file if compose used TMOL.

[cwjohnston]

Seems like the only con wrt JSON is lack of comments?

I've read that YAML 1.2 spec is compatible with JSON as a subset, so if we can do both by adopting YAML I would be in favor. Otherwise, moving away from JSON seems unnecessary.

[grepory]

Well, also the mechanics of actually writing JSON--especially non-trivial JSON structs (see CloudFormation Templates).

[grepory]

I like YAML because it's an easy to parse visual representation of the layout of configuration data. That's why, using @jamesdphillips's example above, a docker-compose file is so much easier to read in YAML. Also, it has better support for arrays. Arrays in toml are kind of ridiculous:

[[things]]
field=value1

[[things]]
field=value2

Again, the principle selling point for YAML is UX. The UX for YAML is, frankly, better than any of the other options. And this isn't Ruby YAML that we're talking about either--so it's not insanely allowing you to insert arbitrary code.

[grepory]

^ E.g. a checks array.

[portertech]

We've chosen to use YAML.

Notes:

• It's not the Ruby YAML
• Amount of configuring is minimal (we are not configuring Sensu beyond the service)
• A configuration format that is human friendly is most important