Beaker-devel December 2014

beaker-devel@lists.fedorahosted.org

6 participants
11 discussions

Future directions for the Beaker test harness
by Nick Coghlan 12 Mar '18

12 Mar '18

A few weeks back, Amit put together a proof of concept for running the test harness in a container, rather than directly on the host (http://gerrit.beaker-project.org/#/c/3199) That proof of concept relies on restraint, the new reference harness, that is intended to eventually replace beah (https://beaker-project.org/dev/proposals/reference-harness.html) At the same time, I don't think restraint is currently getting the level of review and testing that it needs to mature into a plausible replacement for beah as the default harness. I think Amit's proposed patch provides a possible way forward: 1. Accept the initial approach where restraint is the *only* supported harness when running inside a container. Specifying both "contained_harness" and "harness" as ks_meta variables should be an error at this point (side note: 'harness' should also be documented along with all the other ks_meta variables, with a link to https://beaker-project.org/docs/alternative-harnesses/) 2. Recommend publishing both beah *and* restraint in the harness repos for Beaker installations. This will not only make restraint available for container based testing, but also make it readily available via "harness=restraint" for normal testing, without needing to add a custom repo definition. 3. Once we have container based testing working reliably with restraint, drop the restriction against using alternative harnesses in containers. The priority at the moment though is to get something working that can run on an Atomic Host, and still provide a relatively normal execution environment for the executed tasks. Supporting alternative harnesses *inside* containers is a nice-to-have that can wait until later - by flatly disallowing it, we ensure we don't have to spend any time working on container related issues that don't impact restraint. For the initial iteration, we can also ignore the question of choosing the base image used to run the harness, as well as being able to start and stop other containers on the host. I've filed an RFE for 0.18 on that basis: https://bugzilla.redhat.com/show_bug.cgi?id=1131388 As part of this, we may also want to move restraint from Bill's personal account on GitHub to the main Beaker project account, but I don't think that's particularly urgent at this point. Regards, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane HSS Provisioning Architect

5 10

Beaker inventory: smolt & lshw comparison
by Amit Saha 24 Apr '15

24 Apr '15

Hi all, As part of the migration to "lshw" for beaker's inventory task, I ran a comparison of the "smolt" based tasks with the "lshw" based task. The "raw" data is available in the "comparison.html" file under each arch sub-directory at: https://amitksaha.fedorapeople.org/beaker-inventory-comparison/comparison_d… Here are the summarized differences: ** i686/AMD/athlon (32-bit system) CPU flags ========= * lshw categorises "fpu_exception" as a CPU flag, adds "wp" as cpu flag too. (This is because we assume all the stuff lshw lists as CPU capabilities, we consider them flags) Others ====== * USBID retrieved by lshw with repetition, smolt didn't retrieve any * Same PCIID retrieved by lshw, however there is repetition of a device (for PCIID as well) * lshw is not able to detect the system model (same as smolt) * lshw sets arch to i686 instead of i386 by smolt * lshw fails to get the system vendor (same as smolt) * lshw fails to get the FORMFACTOR * CPUVENDOR obtained by smolt is AuthenticAMD, lshw sets it to "Advanced Micro Devices [AMD]" ** ia64 CPU flags ========= * No CPU flags retrieved by lshw Others ====== * Bulk of the USB IDs retrieved are 0000:0000s * lshw is not able to detect the system model * CPUFAMILY is reported by smolt as 1, by lshw as 2 * lshw fails to get the system vendor * lshw fails to get the FORMFACTOR, same as smolt * CPUVENDOR obtained by smolt is genuineintel, lshw sets it to "Intel corp." * CPU stepping obtained by smolt is 0, whereas it is None by lshw * PCIIDS retrieved by lshw contain one missing PCIID and a number of repetitions * Memory reported by smolt is 7863 MB, 8192 by smolt. (**Needs more investigation**) ** ppc64/Power 6 CPU flags ========= * No CPU flags retrieved by either Others ====== * USBID retrieved by lshw, none by smolt, contains one repetition * lshw is not able to detect the system model, same as smolt * lshw fails to get the system vendor * lshw reports a repeating PCIID (same as smolt) ** ppc64/Power 7 CPU flags ========= * CPU flags retrieved by lshw as "performance-monitor" Others ====== * No USB devices reported by either * lshw is not able to detect the system model, same as smolt * lshw fails to get the system vendor * lshw and smolt both doesn't report any PCIIDs ** s390 CPU flags ========= * CPU flags reported by lshw are each duplicated Others ====== * No USBIDs retrieved by lshw, none by smolt * lshw is not able to detect the system model, same as smolt * lshw fails to get the system vendor, same as smolt * lshw reports a repeating PCIID (same as smolt) * Memory is reported as 2001 MB by both, system has 2048 MB ** x86_64/amd CPU flags ========= * lshw uses x86-64 in place of lm * lshw categorises "fpu_exception" and "cpufreq" as a CPU flags (This is because we assume all the stuff lshw lists as CPU capabilities, we consider them flags) Others ====== * More USBID retrieved by lshw, however there is repetition of a device (for PCIID as well) * lshw is not able to detect the system model * lshw sets VIRT_IOMMU to False, whereas smolt has it to True * lshw sets arch to x86-64 instead of x86_64 * smolt gets CPUMODEL as " AMD Eng Sample, 1S256146U8K54_35/25/20_2/8 ", lshw gets it as "Opteron" * lshw fails to get the system vendor * lshw fails to get the FORMFACTOR * CPUVENDOR obtained by smolt is AuthenticAMD, lshw sets it to "Advanced Micro Devices [AMD]" * smolt gets 3811 MB of memory, lshw gets None on an 3919 MB system (**Needs more investigation**) ** x86_64/intel CPU flags ========= * lshw uses x86-64 in place of lm * lshw categorises "fpu_exception" and "cpufreq" as a CPU flags (This is because we assume all the stuff lshw lists as CPU capabilities, we consider them flags) Others ====== * More USBID retrieved by lshw, however there is repetition of a device * lshw is not able to detect the system model * lshw sets arch to x86-64 instead of x86_64 * smolt gets CPUMODEL as "Intel(R) Xeon(TM) CPU 3.60GHz", lshw gets it as "Xeon" * lshw fails to get the system vendor * CPUVENDOR/vendor obtained by smolt is GenuineIntel, lshw sets it to Intel Corp. * lshw gets 4096 MB of memory correctly ** x86_64/kvm guest CPU flags ========= * lshw uses x86-64 in place of lm * lshw categorises "fpu_exception" as a CPU flag (This is because we assume all the stuff lshw lists as CPU capabilities, we consider them flags) Others ====== * USBID retrieved by lshw, none by smolt * lshw is not able to detect the system model * lshw sets arch to x86-64 instead of x86_64 * lshw fails to get the system vendor * CPUVENDOR/vendor obtained by smolt is GenuineIntel, lshw sets it to Intel Corp. * lshw fails finds one device less (PCIID) * lshw gets 2048 MB of memory correctly ** Common to all archs For all the architectures, the devices list returned by the lshw task is fewer than those returned by smolt. The devices need to be individually compared to come up with a more accurate answer. PS: arm 32-bit and 64-bit comparison: Not possible, since we cannot run any smolt supported distro on these. The next plan of action is to fix the issues that we have found above - either in "beaker-system-scan" or "lshw" itself. Best, Amit. -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

3 7

Need improvements to template variables in workflow-installer-test
by Alexander Todorov 16 Feb '15

16 Feb '15

Hi guys, as pointed out at http://gerrit.beaker-project.org/#/c/3891/ I've been considering some improvements to the way workflow-installer-test processes its templates. Currently all kickstart templates have things like {% if OS_MAJOR > 5 %}%end{% endif %} or {% if OS_MAJOR == 5 %} key --skip {% endif %} which is relevant only for RHEL distros and not for Fedora. On top of that Rawhide snapshots are imported as FAMILY=Fedora, MAJOR=rawhide, MINOR=0. I suggest the following improvements in order to provide richer context and minimize template bloat and rewriting: 1) Provide a {% end FAMILY OS_MAJOR %} tag which will insert the closing %end (for %packages or %pre/%post) if needed. This will be implemented as a Jinja extension. 2) Provide filters like isRHEL, isFedora, isRawhide to help with template writing. These will be implemented as Jinja filters. Currently I even have a filter which supports a somewhat cryptic syntax: FAMILY|isRHEL - returns bool OS_MAJOR|isRHEL(FAMILY) > 5 - returns either OS_MAJOR if FAMILY is RHEL or 0 if FAMILY is something else. Additionally Dan Callaghan commented on Gerrit: > > Yes it sounds like this is a good time to re-think the template vars for workflow-installer-test. It would be really good to have them more consistent with the server side templates. I don't know how server side templates look like so Dan please comment how can we make both sides more consistent ? Additionally (see Gerrit) OS_MINOR can be either a digit (0, 1, 2, etc) or a string (Alpha, Beta, etc). My patch above changed the type of OS_MINOR, OS_MAJOR to string and so far things work but I suspect there will be issues with comparisons like 2 > 20 (different number of digits). Currently OS_MINOR doesn't seem to be used anywhere in the templates. Any other comments or ideas are welcome as well. Thanks, Alex

3 10

Beaker 19.1 released
by Dan Callaghan 21 Dec '14

21 Dec '14

The Beaker 19.1 maintenance release is now available from beaker-project.org [1]. This release includes an assortment of minor fixes and enhancements. Full details are in the release notes [2]. Since this is most likely our last release before the end of the year, let me take this opportunity to wish everyone a happy new year from the Beaker team. See you in 2015! [1] https://beaker-project.org/releases/ [2] https://beaker-project.org/docs/whats-new/release-19.html#beaker-19-1 -- Dan Callaghan <dcallagh(a)redhat.com> Software Engineer, Hosted & Shared Services Red Hat, Inc.

1 0

restraint: main.c used anymore?
by Amit Saha 21 Dec '14

21 Dec '14

Is the file src/main.c of any use anymore? -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

2 2

Updated road map & PTO
by Nick Coghlan 19 Dec '14

19 Dec '14

Hi folks, I've published the updated release road map at https://beaker-project.org/dev/release-roadmap.html, covering plans for the 19.2 maintenance release, and the planned focus for the next two major feature releases. Beaker 20 will be aimed at implementing the remaining Predefined Access Policy [1] component of the previously deferred access policies design proposal. Beaker 21 will focus on a new proposal Dan is working on to revamp the job details page to be less noisy and easier to use effectively. I'm also off on 3 weeks vacation, followed by a week at linux.conf.au 2015, so I'll catch y'all in 2015 :) Cheers, Nick. [1] https://beaker-project.org/dev/proposals/access-policies-for-systems.html#p… Cheers, Nick. -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane HSS Provisioning Architect

1 0

Setting up a new project in Beaker's git/gerrit infrastructure
by Amit Saha 16 Dec '14

16 Dec '14

Scenario: Create a fork of an upstream project whose source is on github Steps: 1. Fork the project as beaker-project's upstream on GitHub 2. Login to beaker-project.org 3. Init a bare git repo on /srv/git/: git init --bare --shared <project_name> 4. chown -R <username>:beakerdevs /srv/git/<project_name> 5. Setup the project on http://gerrit.beaker-project.org/#/admin/create-project/, inherit permissions from beaker project 6. Setup DENY permission for Fedorahosted replication authgroup 7. Push the master branch of upstream fork to gerrit: git push restraint-gerrit master -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

3 5

Creating a "Beaker Release Roadmap"
by Nick Coghlan 15 Dec '14

15 Dec '14

When I started the "Handling Large Installations" design proposal [1], it was intended to document a series of smaller steps towards the specific goal of implementing more automated usage constraints and other usability improvements in Beaker to reduce the level of training needed to use a large installation appropriately. Over time, it's usage morphed to become a running record of past Beaker releases, and our current plans for future releases. I actually quite like that usage style, so I'll be changing it to officially be that, and dropping it as a "design proposal". Cheers, Nick. [1] https://beaker-project.org/dev/proposals/handling-large-installations.html -- Nick Coghlan Red Hat Hosted & Shared Services Software Engineering & Development, Brisbane HSS Provisioning Architect

1 0

Docker based workflow for working on restraint
by Amit Saha 15 Dec '14

15 Dec '14

In case you don't want a few additional packages on your system, here is a script which will build a docker image installing all dependencies needed to run restraint's tests: #!/bin/bash # ./restraint.sh <image_name> <docker_base_image> uid=`id -u` user=`id -un` cat <<EOF > Dockerfile FROM $2 RUN yum -y install make glib2 glib2-devel glibc-devel libarchive-devel libsoup-devel gcc pkgconfig gettext libselinux-devel openssl-devel perl-XML-Parser selinux-policy-devel zlib-devel git git-daemon tar thttpd RUN yum -y install emacs-nox RUN useradd -u $uid $user USER $uid EOF docker build -t $1 . mv Dockerfile Dockerfile.$1 echo "$1 created. Entering: /home/$user" docker run -v /home/$user:/home/$user -ti $1 bash Assuming you have docker setup: ./restraint.sh fedora21_restraint fedora:21 Will build the docker image and also start the container: Successfully built a8f0f98cb2f2 fedora21_restraint created. Entering: /home/asaha Couple of things are worth noting: 1. It creates a user of the same username, uid and gid of the user you execute docker as 2. Assuming you are *not* using docker as root/sudo, this means, an user of the same uid/gid is created in the container. Hence, since /home/$user is volume mounted, you should have r+w access to your host's home directory (only if you turn off selinux or may be set it to permissive). If you have a clone of restraint already in your home, you can directly start working on it, or just clone it and run "make check". You will need http://gerrit.beaker-project.org/#/c/3869/ for all the tests to pass. -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

1 1

Hostname for the docker container
by Amit Saha 11 Dec '14

11 Dec '14

Hi all, While investigating an issue with running the test harness in a container, I realized the if hostname is used anywhere in the harness, it really will be the container's hostname (container ID) and not the test system's. Should we stick to that? Or should we set it to the host's $HOSTNAME? Perhaps, we should keep it as it is, since we may move to multi-container testing, etc where container ID would be how we address another container. Best, Amit. -- Amit Saha SED, Hosted & Shared Services Red Hat, Inc.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Beaker-devel December 2014