From e3a654c9a08ee849e418eec2b6ac0c3804cc6db3 Mon Sep 17 00:00:00 2001 From: ybonatakis Date: Tue, 4 Aug 2020 14:40:20 +0200 Subject: [PATCH] Update documentation for supportserver generation --- how_to_create_a_support_server.md | 21 +++------------- schedule/supportserver_generator.yaml | 36 --------------------------- 2 files changed, 4 insertions(+), 53 deletions(-) delete mode 100644 schedule/supportserver_generator.yaml diff --git a/how_to_create_a_support_server.md b/how_to_create_a_support_server.md index 5f8ba28abdbb..d34b8e547e4f 100644 --- a/how_to_create_a_support_server.md +++ b/how_to_create_a_support_server.md @@ -6,10 +6,9 @@ ## How to generate a supportserver -There are two ways to create a supportserver. The first one is using a job called -*supportserver_generator* and the second leveraging the *create_hdd* +There are two ways to create a supportserver. The first one is using a job called *supportserver_generator* using an Autoyast and the second leveraging the *create_hdd* -We are also obliged to generate two images based on the desktop that the test is used on. Thus we need separate qcow image to support test with gnome and another for textmode. +We are also obliged to generate two images based on the desktop that the test is used on. Thus we need separate qcow image to support test with gnome and another one for textmode. ## Using autoyast @@ -37,23 +36,11 @@ openqa_support_server_sles15sp2_aarch64_textmode_202007.qcow2 ## Using create_hdd -The disadvantage with the Autoyast is that you need to get a working xml for your needs. The xml might change from build to build. Also the autoyast_supportserver_generator works for the textmode but there is provided xml for gnome. In the other side we have `create_hdd_gnome` and `create_hdd_textmode` which can be used as normal jobs with some extra tweaking, to add particular configuration. For this we can use the `support_server/configure.pm` which is scheduled in `schedule/supportserver_generator.yaml` yaml scheduler. The simpliest way to trigger the generation, per se, is cloning the job with the scheduler yaml or with an isos POST request - -for gnome -```bash -openqa-cli api --osd -X POST isos TEST=create_hdd_gnome YAML_SCHEDULE=schedule/supportserver_generator.yaml PUBLISH_HDD_1=openqa_support_server_sles15sp2_%ARCH%_%BUILD%@%MACHINE%_%DESKTOP%.qcow2 {...} -``` - -for textmode -```bash -openqa-cli api --osd -X POST isos TEST=create_hdd_textmode YAML_SCHEDULE=schedule/supportserver_generator.yaml PUBLISH_HDD_1=openqa_support_server_sles15sp2_%ARCH%_%BUILD%@%MACHINE%_%DESKTOP%.qcow2 {...} -``` - -where {...} are all the specific variables for the arch, build, etc +The disadvantage with the Autoyast is that you need to get a working xml for your needs. The xml might change from build to build. In the other side we have `create_hdd_gnome` and `create_hdd_textmode` which can be used as normal jobs with some extra tweaking, to add particular configuration. The above mentioned job publish an qcow that we can leverage, boot into it and run the configuration that we want, and publish again under the corresponding name. ## supportserver_generator_from_hdd -To accelerate the creation we can chain the jobs between create_hdd_gnome/create_hdd_textmode and a job that is scheduled with the `schedule/supportserver_generator_from_hdd.yaml`. The chained job has to be in accordance with the DESKTOP variable that it is used in the create_hdd(ex: DESKTOP=gnome if publish image is coming from create_hdd_gnome). The chained job has to have enabled the BOOT_HDD_IMAGE, HDD_1 and BOOTFROM. At the end we need to define the PUBLISH_HDD_1 with the new name of the supportserver. +To accelerate the creation we can chain the jobs between create_hdd_gnome/create_hdd_textmode and a job that is scheduled with the `schedule/supportserver_generator_from_hdd.yaml` yaml scheduler. The chained job has to be in accordance with the DESKTOP variable that it is used in the create_hdd(ex: DESKTOP=gnome if publish image is coming from create_hdd_gnome). The chained job has to have enabled the BOOT_HDD_IMAGE, HDD_1 and BOOTFROM. At the end we need to define the PUBLISH_HDD_1 with the new name of the supportserver. ```bash openqa-cli api --osd -X POST isos TEST=supportserver_generator_from_hdd YAML_SCHEDULE=schedule/supportserver_generator_from_hdd.yaml PUBLISH_HDD_1=openqa_support_server_sles15sp2_%ARCH%_%BUILD%@%MACHINE%_%DESKTOP%.qcow2 DESKTOP=textmode START_AFTER_TEST=create_hdd_gnome:aarch64 BOOTFROM=c _SKIP_CHAINED_DEPS=1 CONSOLE_JUST_ACTIVATED=0 HDD_1=SLES-15-SP2-%ARCH%-Build%{BUILD}%@%ARCH%-%DESKTOP%.qcow2 {...} diff --git a/schedule/supportserver_generator.yaml b/schedule/supportserver_generator.yaml deleted file mode 100644 index c24fe4aacf7d..000000000000 --- a/schedule/supportserver_generator.yaml +++ /dev/null @@ -1,36 +0,0 @@ ---- -name: supportserver_generator -description: | - image creation job used as parent for other jobs testing based on existing installation. - use of create_hdd_gnome and create_hdd_textmode to configure supportserver image for MM tests. -schedule: - - installation/bootloader_start - - installation/welcome - - installation/accept_license - - installation/scc_registration - - installation/addon_products_sle - - installation/system_role - - installation/partitioning - - installation/partitioning/no_separate_home - - installation/partitioning_finish - - installation/installer_timezone - - installation/hostname_inst - - installation/user_settings - - installation/user_settings_root - - installation/resolve_dependency_issues - - installation/installation_overview - - installation/disable_grub_timeout - - installation/start_install - - installation/await_install - - installation/logs_from_installation_system - - installation/reboot_after_installation - - installation/grub_test - - installation/first_boot - - console/system_prepare - - console/sle15_workarounds - - console/hostname - - console/force_scheduled_tasks - - support_server/configure - - shutdown/grub_set_bootargs - - shutdown/cleanup_before_shutdown - - shutdown/shutdown