Configuration design: Wrong format: list vs mapping

[malex984]

Note: this is a separation of super-issue #13

General: 1.2 The format is wrong. If you want to list people you do:

- name: john
  phone: 5411-2222
- name: peter
  phone: 3838-1111

or

john:
  phone: 5411-2222
peter:
  phone: 3838-1111

not

- john:
  phone: 5411-2222
- peter:
  phone: 3838-1111

because that is equivalent to

[
  {john: 
    {phone: 5411-2222}
  },
  {peter:
    {phone: 3838-1111}
  }
]

[porst17]

Is this still under discussion? To me,

john:
  phone: 5411-2222
peter:
  phone: 3838-1111

seems to be the way to go, i.e. you would define the IDs john and peter in the map that can then be used elsewhere.

[malex984]

Alex said:
Fixed - see update: https://gist.github.com/malex984/59d2b62c5098eb1005100f9249719505#file-all_flat_update-yml

[malex984]

@here is a general structure of a config file with YAML:

---
version: 123 # version of config file format
...
table_of_objects_of_some_type_i: # implicitly defines the type for all objects below
  object_id_i_1: # String ID, used to reference the corresponding object
    field_1: value_i_1
    ...
    field_n: value_i_1
  ...
  object_id_i_ki: { ... } # optional fields may be omitted
...
table_of_objects_of_some_other_type_j: {...}

Note:

• Types of objects correspond to the table ID (e.g. table_of_objects_of_some_type_i should be known for our configuration interpreter to contain objects of the same type: some_type_i, defined by {field_1, ..., field_n}). Specifically to our use case:
  • values in global mapping stations should be of type Station,
  • profiles -> Profile,
  • services -> DockerComposeService,
  • applications -> DockerComposeApplication
• Object IDs (e.g. object_id_i_1 etc.) should be valid globally UNIQUE identifiers (no spaces). They will be used as references to corresponding objects from other parts of the config file

See #27 for a possible problem due to silent overrides.

[porst17]

version should be a semantic version. Right now we are at initial development, i.e. version 0.MAJOR.MINOR. I'd argue that we don't need MAJOR.MINOR.PATCH since PATCH usually only changes implementation details which are irrelevant to the user of the config.

Without semantic versioning it's hard to tell wether a new version breaks current config. Also, we can provide converters between to MAJOR versions, if necessary.

[malex984]

Most recent minimal YAML sample is at https://gist.github.com/malex984/59d2b62c5098eb1005100f9249719505#file-mini_sample-yml

[elondaits]

@malex984 Did you mean to post this comment in this issue? Because it's the second comment I see today, from you, that would seem to answer something we wrote somewhere else. Are you commenting through some mechanism that might be mixing up issues?

[malex984]

@elondaits Are you sure? The comment above is 3 days old... It points to the latest minimal sample illustrating the file structure with semantic versioning according to the comment by @porst17