Yaml Based Configuration

Within an empty directory the following command can be used to generate an initial edi configuration:

edi config init my-project debian-bookworm-amd64

This command generates a configuration with four placeholder use cases:

  • my-project-run.yml: This configuration file covers the run use case. It is the configuration that the customer will get.

  • my-project-test.yml: The test use case shall be as close as possible to the run use case. A few modifications that enable efficient testing will differentiate this use case from the run use case.

  • my-project-build.yml: The build use case covers the requirements of a build server deployment.

  • my-project-develop.yml: The develop use case satisfies the requirements of the developers.

Please note that the above use cases are just an initial guess. edi does not at all force you to build your project upon a predefined set of use cases. It just helps you to modularize your different use cases so that they do not diverge over time.

The configuration is split into several sections. The following command will dump the merged and rendered configuration of the use case develop for the given command:

edi lxc configure --config my-container my-project-develop.yml
--config

Dump the merged configuration instead of running the command.

general Section

The general section contains the information that might affect all other sections.

edi supports the following settings:

bootstrap Section

This section tells edi how the initial system shall be bootstrapped. The following settings are supported:

Please note that edi will automatically do cross bootstrapping if required. This means that you can for instance bootstrap an armhf system on an amd64 host.

If you would like to bootstrap an image right now, you can run the following command:

sudo edi image bootstrap my-project-develop.yml

Ordered Node Section

In order to understand the following sections we have to introduce the concept of an ordered node section. In Unix based systems it is quite common to split configurations into a set of small configuration files (see e.g. /etc/sysctl.d). Those small configuration files are loaded and applied according to their alphanumerical order. edi does a very similar thing in its ordered node sections. Here is an example:

Example 1
dog_tasks:
  10_first_task:
    job: bark
  20_second_task:
    job: sleep
Example 2
dog_tasks:
  20_second_task:
    job: sleep
  10_first_task:
    job: bark

In both examples above the dog will first bark and then sleep because of the alphanumerical order of the nodes 10_first_task and 20_second_task. The explicit order of the nodes makes it easy to add or modify a certain node using Overlays.

Plugin Node

Most of the ordered node sections contain nodes that specify and parametrize plugins.

A typical node looks like this:

lxc_profiles:
  10_first_profile:
     path: path/to/profile.yml
     parameters:
       custom_param_1: foo
       custom_param_2: bar

Such nodes accept the following settings:

--dictionary

Dumps the load time dictionary instead of running the command.

To learn more about plugins please read the chapter Plugins.

lxc_templates Section

The lxc_templates section is an ordered node section consisting of plugin nodes. Please consult the LXD documentation if you want to write custom templates.

lxc_profiles Section

The lxc_profiles section is an ordered node section consisting of plugin nodes. Please consult the LXD documentation if you want to write custom profiles.

playbooks Section

The playbooks section is an ordered node section consisting of plugin nodes. Please consult the Ansible documentation if you want to write custom playbooks.

postprocessing_commands Section

The postprocessing_commands section is an ordered node section consisting of plugin nodes. The post processing commands can be written in any language of choice. In contrast to the other plugin nodes the post processing command nodes require an explicit declaration of the generated artifacts. Please read the chapter Plugins for more details.

shared_folders Section

The shared_folders section is an ordered node section that can be used to specify shared folders between LXC containers and their host.

Shared folders are very convenient for development use cases. Please note that edi will automatically turn any container that uses shared folders into a privileged container. This will facilitate the data exchange between the host and the target system. It is advisable to use shared folders together with the development_user_facilities playbook plugin.

A shared folder section can look like this:

shared_folders:
  edi_workspace:
    folder: edi-workspace
    mountpoint: edi-workspace

Let us assume that the name of the current development user is johndoe and that his home directory is /home/johndoe. The development_user_facilities playbook plugin will automatically make sure that the user johndoe will also exist within the container. The shared_folders section will then make sure that the host folder /home/johndoe/edi-workspace (folder) will be shared with the container using the container directory /home/johndoe/edi-workspace (mountpoint).

The shared folder nodes accept the the following settings:

documentation_steps Section

The documentation_steps section is an ordered node section consisting of plugin nodes. The documentation_steps section is being processed by the edi documentation render ... command. This command is independent of the command pipeline but it can be easily integrated as a postprocessing command. (See edi-pi for a possible implementation.)

The command that renders the documentation gets executed as follows:

edi documentation render PATH_TO_USR_SHARE_DOC_FOLDER OUTPUT_FOLDER CONFIG.yml

From PATH_TO_USR_SHARE_DOC_FOLDER/edi the files build.yml (optional), packages.yml and packages-baseline.yml (optional) will be retrieved. Based on the content of this files the documentation_steps plugins will get executed.

A documentation step can look like this:

documentation_steps:
  ...
  400_changelog:
    path: documentation_steps/rst/templates/changelog.rst.j2
    output:
      file: changelog.rst
    parameters:
      edi_doc_include_changelog: True
      edi_doc_changelog_baseline: 2019-12-01 00:00:00 GMT
      edi_doc_replacements:
      - pattern: '(?i)[#]*(Closes:\s[#])([0-9]{6,10})'
        replacement: '`\1\2 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=\2>`_'
      - pattern: '(?i)[#]*(LP:\s[#])([0-9]{6,10})'
        replacement: '`\1\2 <https://bugs.launchpad.net/ubuntu/+source/nano/+bug/\2>`_'
  ...

path points to a Jinja2 template that will get used to render the file declared under output/file.

The documentation steps can be fine tuned using the following parameters: