+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
Hello,
we had to enforce the content of the context dictionary in order to fix a security issue that we found recently. The full details of the security issue will be disclosed when a CVE is available.
We know that this is annoying for many people so we tried to collect all the valid use cases before the previous release.
Which variables are you setting in the context? Is the corresponding code upstreamed?
Cheers
Le lun. 20 mai 2019 à 10:49, cnspring2002 cnspring2002@aliyun.com a écrit :
+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
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
lava-users@lists.lavasoftware.org
-
cnspring2002 -
Remi Duraffort