Product properties vs config

[joseivanlopez]

Right now there are at least 3 different ways of configuring a product in Agama:

• Applying the initial config indicated in the product file (e.g., products.d/tumbleweed.yaml).
• Loading some config from a json file (agama config load myconfig.json).
• Setting some config by calling to dbus (e.g., Agama/Storage1/Proposal.Calculator#Calculate).

For each one, the possible settings are slightly different, and there is not 100% equivalence in all cases. It would be nice to have a unique way of configuring the product, using always the same settings and format.

Product file (yaml)

The product file is mixing two different things: the product definition and the initial default config. For example, the storage section indicates the definition of the volumes (a.k.a. templates) and some settings to calculate the initial proposal:

storage:
  space_policy: delete
  volumes:
    - "/"
    - "swap"
  volume_templates:
    ...

Ideally, this file should only have the "read-only" information about a product, for example: description, translations, volume templates, software repositories, mandatory packages, available LSMs, etc. The rest should go to a config file.

Config file (json)

Configuring a product (e.g., select a disk, add a package, create a user, etc) could be always done by applying some json config, independently on it is the default product config or a custom config requested by a user. Even for the D-Bus API, there is no a real need of having a specific API for configuring the different product settings like the user, locale, etc. The D-Bus services could simply allow loading a serialized json:

$ busctl call org.opensuse.Agama.Storage1 /org/opensuse/Agama/Storage1 org.opensuse.Agama.Storage1 Load s { "storage": { "drives": [{ "device": "/dev/vda" }] } }

# Or loading a file:

busctl call org.opensuse.Agama.Storage1 /org/opensuse/Agama/Storage1 org.opensuse.Agama.Storage1 Load s ${cat myconfig.json}

The services (e.g., storage) would receive the serialized json which is then deserialized and validated through the schema, returning a D-Bus error if the settings are not valid.

Note that our D-Bus services are designed for IPC and they are not expected to be directly used by users. Moreover, there is no special difference between passing a "a{sv}" and a serialized json.