From 27b190091993e136e54cfc0dd0be846cbc221e02 Mon Sep 17 00:00:00 2001 From: Kamil Páral Date: Mar 26 2019 17:57:30 +0000 Subject: openqa sop: fix formatting for code sections --- diff --git a/docs/sysadmin-guide/sops/openqa.rst b/docs/sysadmin-guide/sops/openqa.rst index f7ee542..0314eab 100644 --- a/docs/sysadmin-guide/sops/openqa.rst +++ b/docs/sysadmin-guide/sops/openqa.rst @@ -174,28 +174,32 @@ cases of inter-dependent jobs correctly when restarting, but doesn't always mana when it goes wrong, the best thing to do is usually to re-run all jobs for that medium. To run or re-run the full set of tests for a compose or update, you can use the ``fedora-openqa`` -CLI. To run or re-run tests for a compose, use: +CLI. To run or re-run tests for a compose, use:: fedora-openqa compose -f (COMPOSE LOCATION) -where (COMPOSE LOCATION) is the full URL of the /compose subdirectory of the compose. This will -only work for Pungi-produced composes with the expected productmd-format metadata, and a couple -of other quite special cases. +where ``(COMPOSE LOCATION)`` is the full URL of the ``/compose`` subdirectory of the compose. This +will only work for Pungi-produced composes with the expected productmd-format metadata, and a +couple of other quite special cases. The ``-f`` argument means 'force', and is necessary to re-run tests: usually, the scheduler will refuse to re-schedule tests that have already run, and ``-f`` overrides this. -To run or re-run tests for an update, use: +To run or re-run tests for an update, use:: fedora-openqa update -f (UPDATEID) (RELEASE) -where (UPDATEID) is the update's ID - something like ``FEDORA-2018-blahblah`` - and (RELEASE) is the -release for which the update is intended (27, 28, etc). +where ``(UPDATEID)`` is the update's ID - something like ``FEDORA-2018-blahblah`` - and +``(RELEASE)`` is the release for which the update is intended (27, 28, etc). To run or re-run only the tests for a specific medium (usually a single image file), you must use -the lower-level web API client, with a more complex syntax. The command looks something like this: +the lower-level web API client, with a more complex syntax. The command looks something like this:: - /usr/share/openqa/script/client isos post ISO=Fedora-Server-dvd-x86_64-Rawhide-20180108.n.0.iso DISTRI=fedora VERSION=Rawhide FLAVOR=Server-dvd-iso ARCH=x86_64 BUILD=Fedora-Rawhide-20180108.n.0 CURRREL=27 PREVREL=26 RAWREL=28 IMAGETYPE=dvd LOCATION=http://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180108.n.0/compose SUBVARIANT=Server + /usr/share/openqa/script/client isos post \ + ISO=Fedora-Server-dvd-x86_64-Rawhide-20180108.n.0.iso DISTRI=fedora VERSION=Rawhide \ + FLAVOR=Server-dvd-iso ARCH=x86_64 BUILD=Fedora-Rawhide-20180108.n.0 CURRREL=27 PREVREL=26 \ + RAWREL=28 IMAGETYPE=dvd SUBVARIANT=Server \ + LOCATION=http://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180108.n.0/compose The ``ISO`` value is the filename of the image to test (it may not actually be an ISO), the ``DISTRI`` value is always 'fedora', the ``VERSION`` value should be the release number or 'Rawhide', the @@ -207,18 +211,18 @@ release number associated with Rawhide at the time the test is run, ``IMAGETYPE` image being tested (again, check a similar test for the correct value), ``LOCATION`` is the URL to the /compose subdirectory of the compose location, and ``SUBVARIANT`` again depends on the image being tested. Please ask for help if this seems too daunting. To re-run the 'universal' tests on a -given image, set the ``FLAVOR`` value to 'universal', then set all other values as appropriate to the +given image, set the ``FLAVOR`` value to 'universal', then set all other values as appropriate to the chosen image. The 'universal' tests are only likely to work at all correctly with DVD or netinst images. openQA provides a special script for cloning an existing job but optionally changing one or more -variable values, which can be useful in some situations. Using it looks like this: +variable values, which can be useful in some situations. Using it looks like this:: /usr/share/openqa/script/clone_job.pl --skip-download --from localhost 123 RAWREL=28 -to clone job 123 with the RAWREL variable set to '28', for instance. For interdependent jobs, you -may or may not want to use the ``--skip-deps`` argument to avoid re-running the cloned job's parent -job(s), depending on circumstances. +to clone job 123 with the ``RAWREL`` variable set to '28', for instance. For interdependent jobs, +you may or may not want to use the ``--skip-deps`` argument to avoid re-running the cloned job's +parent job(s), depending on circumstances. Manual updates @@ -232,13 +236,13 @@ for some reason. Here are some notes on those cases. For updating openQA and/or os-autoinst packages: ideally, ensure no jobs are running. Then, update all installed subpackages on the server. The server services should be automatically restarted as part of the package update. Then, update all installed subpackages on the worker hosts, and restart -all worker services. A 'for' loop can help with that, for instance: +all worker services. A 'for' loop can help with that, for instance:: for i in {1..10}; do systemctl restart openqa-worker@$i.service; done on a host with ten worker instances. -For updating the openQA tests: +For updating the openQA tests:: cd /var/lib/openqa/share/tests/fedora git pull (or git checkout (branch) or whatever) @@ -247,7 +251,7 @@ For updating the openQA tests: The templates steps are only necessary if there are any changes to the templates files. -For updating the scheduler code: +For updating the scheduler code:: cd /root/fedora_openqa git pull (or whatever changes) @@ -274,8 +278,8 @@ this back to 'info'. Occasionally the test execution logs may be useful in figuring out why all tests are failing very early, or some specific tests are failing due to an asset going missing, etc. Each job's -execution logs can be accessed through the web UI, on the 'Logs & Assets' tab of the job page; -the files are 'autoinst-log.txt' and 'worker-log.txt'. +execution logs can be accessed through the web UI, on the *Logs & Assets* tab of the job page; +the files are ``autoinst-log.txt`` and ``worker-log.txt``. Dynamic asset generation (createhdds)