In the current dispatcher, it is an all-or-nothing setting and there is no way of doing conditional replacements. Sorry.
In the refactoring, we are using jinja2 which is closely related to the templating engine used in Django, so is familiar to the developers and relatively easy to pickup. This allows logic to be used inside templates which test writers don't need to know about. It also allows the template to conditionally override elements of a larger block from individual settings, either in the device configuration or in the job submission.
This leads to:
{% extends = "base.yaml" %} {% set console_device = console_device | default('ttyO0') %} nfs: commands: {{ base_uboot_commands }} {{ base_uboot_addr_commands }} {{ base_tftp_commands }} # Always quote the entire string if the command includes a colon to support correct YAML. - "setenv nfsargs 'setenv bootargs console={{ console_device }},{{ baud_rate }}n8 root=/dev/nfs rw {{ base_nfsroot_args }} ip=dhcp'" {{ base_nfs_uboot_bootcmd }}
https://git.linaro.org/lava/lava-server.git/blob_plain/HEAD:/etc/dispatcher-...
(Note: also via the refactoring, all this configuration lives on the master, not on the dispatcher (which just gets the final output of the template alongside the job definition which requires that configuration.)
There are also tools provided to test the output of the templating and ensure it matches what is required. https://validation.linaro.org/static/docs/pipeline-admin-example.html?highli...
For the test writers, there is a job context which allows nominated values to be replaced. The structure is being worked on currently ( https://review.linaro.org/#/c/7746/) and there will be a balance between what the device configuration needs to specify (and therefore cannot be overridden by the job) and what can be specified in the job context.
On 15 September 2015 at 22:40, Kevin Hilman khilman@linaro.org wrote:
Hello,
How does one do a partial-override of boot_cmds from the device file?
I have a panda and want to use the shipping device-type, except that I need to 'setenv usbethaddr ...' before any of the other commands.
I can fix this by copy/paste'ing the whole boot_cmds_ramdisk section from the device-type into my device file, but what I really want to do to is just use the ones from the device-type with minor modifications (and ensure I get updates to the production device-type when they happen)
Something like this (assuming python ConfigParser style formatting) in the device file would be useful:
boot_cmds_ramdisk = setenv usbethaddr <MAC addr>, %(boot_cmds_ramdisk)s
Is there a good way of doing that?
Kevin