YAML config

[RickyCook]

There are a number of advantages to using YAML instead of JSON as your config file:

• superset of JSON, so nothing breaks
• nice things like references to other places in the YAML
• much nicer to read (see the example below)
• allows comments

YAML (auto generated)

command:
  redis-cli info:
    exit-status: '0'
    stdout: [redis_version]
file:
  /etc/redis.conf:
    contains: [bind 0.0.0.0]
    exists: true
    filetype: file
package:
  redis: {installed: true}
port:
  tcp:6379: {ip: 0.0.0.0, listening: true}
service:
  redis: {running: true}

JSON

{
    "package": {
        "redis": {
            "installed": true
        }
    },
    "file": {
        "/etc/redis.conf": {
            "exists": true,
            "filetype": "file",
            "contains": ["bind 0.0.0.0"]
        }
    },
    "port": {
        "tcp:6379": {
            "listening": true,
            "ip": "0.0.0.0"
        }
    },
    "service": {
        "redis": {
            "running": true
        }
    },
    "command": {
        "redis-cli info": {
            "exit-status": "0",
            "stdout": ["redis_version"]
        }
    }
}

[aelsabbahy]

YAML support would be nice. The only concern is comments. They would disapear when a goss add... is run. Would that be an issue?

[RickyCook]

Yeah that's true. That would be a problem. Not sure how to solve that one!

[mtpereira]

Hello!

What if the resource blocks had support for a name or comment field, similar to the name field on Ansbile tasks? It would be optional and, to avoid disrupting the current structure, would be bellow the actual resource name. For example:

command:
  name: Check that redis-cli info is available and executing ok
  redis-cli info:
    exit-status: '0'
    stdout: [redis_version]

This would pretty much kill the need for comments on this files, which I believe is a good workaroud and compromise.

[aelsabbahy]

@mtpereira That sounds great! I assume name would be nested under the redis-cli object, right?

---
command:
  redis-cli info:
    name: Check that redis-cli info is available and executing ok
    exit-status: '0'
    stdout: [redis_version]

[mtpereira]

@aelsabbahy Well, yeah, that does make much more sense! :+1: I've placed it outside because I was influenced by Ansible's tasks layout.

[aelsabbahy]

I think my next step would be to decouple the storage format (JSON) logic from the core logic and add a name, comment or description attribute. Once that's done it'll be easy to add more formats as needed.

I'm still not 100% sure that YAML can be pulled off without breaking goss add, since it would most likely break references.

• nice things like references to other places in the YAML

Thoughts?

[RickyCook]

Possibly you could use an _ prefix for metadata fields. In that case, you could just ignore anything you don't understand, so _comment, _todo, _for_service, etc are all equally valid but more descriptive because they're semi structured

[RickyCook]

And yeah, I think you're right @aelsabbahy; regenerating YAML is problematic when you do refs and comments.

Since you know the structure, and it's not complex you could always dump the new element separately and just append it to the file, but that seems like it could be error prone in cases where (for example) the root node is JSON, or the file structure is malformed

[aelsabbahy]

Yeah, that's the part I'm mentally struggling with. Refs are cool, but if goss add expands them out, then running it would remove the benefits of having refs in the first place.

Either way.. I'll keep this open and revisit after code de-coupling.

[aelsabbahy]

Waiting for the outcome of: https://github.com/go-yaml/yaml/issues/132

References are still a concern though.

[aelsabbahy]

Released in v0.1.0