+1, we also have same issue, had to pending new version deploy.
Message: 1
Date: Mon, 20 May 2019 05:39:40 +0000
From: Larry Shen <
larry.shen@nxp.com>
To: "
lava-users@lists.lavasoftware.org"
<
lava-users@lists.lavasoftware.org>
Subject: [Lava-users] Why make the decision to limit job context in
lava master?
Message-ID:
<
DBBPR04MB63291E1DC4F5F202DEDFE16699060@DBBPR04MB6329.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
For 2019.04 version, we see next:
Job context
-----------
The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
* `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
* `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`
Jobs using keys that are not listed in this list will be rejected.
We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters.
After this limit, all things break!
So, my question is:
lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users?
And additional, and workaround for my scenario?
Regards,
Larry