Future directions for the Beaker test harness
by Nick Coghlan
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
6 years
Adding custom initrds to beaker tftp boot
by Don Zickus
Hi Dan,
I am playing with some KernelCI stuff and one of the topics is fast
booting/installs of a new kernel. The thought is waiting 20-25 minutes to
install Anaconda is too long, when you are resource constrained and need to
run 30-40 tests/day on the same hardware.
An idea came up about creating a custom kernel and initrd with a testsuite
builtin. Currently I don't think beaker supports that, only pre-loaded
distro kernels/initrds.
How hard is it to add that to the LabController? Or some other alternative?
Cheers,
Don
6 years, 7 months
Adding system firmware to system details
by Don Zickus
Hi Dan,
Shawn is working with Jon and myself to add system firmware/bios info to the
beaker database to be displayed on the system details page.
The idea was to make it easy to find how old a bios is on our lab machines
and see which ones need an update.
Shawn made all the front end changes in the inventory job, but the backend
work is becoming a challenge.
It seems like we are going to have to add a table entry to the database in
server/model/inventory.py? Which would probably cause a database migration
event.
For now, we are using numa_nodes as our template to copy the output of lshw
(from the inventory script) into the database and onto the webpage.
Are we going in the right direction? Is this more work than we thought?
Then as a follow-on, we are assuming the database has to be updated to add
this entry, would it make sense to convert the whole database to a generic
key/value table to dynamically support new fields without having to migrate
the whole database all the time? And then to prevent random junk from being
added by the inventory script (or other script), have a whitelist filter
that only allows certain keys to be added/updated. Maintaining the
whitelist would be easier on the database then adding table entries.
This is just us trying to understand the architecture a little more and
trying to see where we can add some value to make it easier to maintain our
tests.
Cheers,
Don
6 years, 7 months
Re: Adding system firmware to system details
by Subhendu Ghosh
Nic firmware, hba firmware, gpu firmware..
Lots of devices with firmware that could be tracked.
Subhendu
On Jul 17, 2017 18:36, "Dan Callaghan" <dcallagh(a)redhat.com> wrote:
Excerpts from Shawn Doherty's message of 2017-07-14 09:17 -04:00:
> Hello all.. apologies if zombie thread is inappropriate but I'd like to
> revisit this conversation regarding firmware information being included.
>
> We have started a patch to display firmware and date and are hoping to get
> some input on progressing. What we were last discussing was to update the
> device table. I'm also curious about a migration script. Here is what
we
> have so far.
>
>
> Thanks for looking. Shawn.
Might be easier to read this if you post it to Gerrit. There is no harm
in posting a WIP or draft patch to Gerrit and asking for reviews on
there.
> diff --git a/Server/bkr/server/controllers.py
> b/Server/bkr/server/controllers.py
> index cece8db..32dc0d4 100644
> --- a/Server/bkr/server/controllers.py
> +++ b/Server/bkr/server/controllers.py
> @@ -123,9 +123,11 @@ def default(self, *args, **kw):
> widgets.PaginateDataGrid.Column(name='driver',
> getter=lambda x: x.driver, title='Driver', options=dict(sortable=True)),
> widgets.PaginateDataGrid.Column(name='vendor_id',
> getter=lambda x: x.vendor_id, title='Vendor ID',
> options=dict(sortable=True)),
> widgets.PaginateDataGrid.Column(name='device_id',
> getter=lambda x: x.device_id, title='Device ID',
> options=dict(sortable=True)),
> -
> widgets.PaginateDataGrid.Column(name='subsys_vendor_id', getter=lambda x:
> x.subsys_vendor_id, title='Subsys Vendor ID',
options=dict(sortable=True)),
> + widgets.PaginateDataGrid.Column(name='subsys_vendor_id',
> getter=lambda x: x.subsys_vendor_id, title='Subsys Vendor ID',
> options=dict(sortable=True)),
>
> widgets.PaginateDataGrid.Column(name='subsys_device_id', getter=lambda x:
> x.subsys_device_id, title='Subsys Device ID',
options=dict(sortable=True)),
> - ])
> +
> widgets.PaginateDataGrid.Column(name='subsys_device_id', getter=lambda x:
> x.fw_version, title='Firmware Version', options=dict(sortable=True)),
> ++
> widgets.PaginateDataGrid.Column(name='subsys_device_id', getter=lambda x:
> x.fw_date, title='Firmware Date', options=dict(sortable=True)),
> + ])
You'll want to fix the column name and title on these. Name can be
anything but by convention it should match the db column. It's used for
sorting inside the widget.
> return dict(title="Devices",
> grid = devices_grid,
> search_bar=None,
> diff --git a/Server/bkr/server/model/inventory.py
> b/Server/bkr/server/model/inventory.py
> index ecbc073..88301ae 100644
> --- a/Server/bkr/server/model/inventory.py
> +++ b/Server/bkr/server/model/inventory.py
> @@ -297,6 +297,8 @@ class System(DeclarativeMappedObject, ActivityMixin):
> kernel_type_id = Column(Integer, ForeignKey('kernel_type.id'),
> default=select([KernelType.id],
> limit=1).where(KernelType.kernel_type==u'default').correlate(None),
> nullable=False)
> + fw_version = Column(String(32))
> + fw_date = Column(DateTime, default=None)
> kernel_type = relationship('KernelType')
> devices = relationship('Device', secondary=system_device_map,
> back_populates='systems')
It looks like these are new columns on System, but they should actually
be new columns on Device, right?
> @@ -2362,6 +2371,8 @@ class Device(DeclarativeMappedObject):
> device_class = relationship(DeviceClass)
> date_added = Column(DateTime, default=datetime.utcnow,
nullable=False)
> systems = relationship(System, secondary=system_device_map,
> back_populates='devices')
> + fw_version = Column(String(32))
> + fw_date = Column(DateTime, default=None)
... oh never mind, they are here too. :-) So I guess just remove the
ones above on System.
We probably want Date not Datetime as the type for the fw_date column (I
assume no firmware reports its build date down to the second).
Is 32 chars enough for the version string? We can always expand it
later. Does lshw itself have any length limits/expectations for the
firmware version?
> diff --git a/systemscan/main.py b/systemscan/main.py
> index 64b9312..41895f2 100755
> --- a/systemscan/main.py
> +++ b/systemscan/main.py
> @@ -286,6 +286,14 @@ def read_inventory(inventory, arch = None,
> proc_cpuinfo='/proc/cpuinfo'):
>
> #Break the xml into the relevant sets of data
> cpuinfo = inventory.xpath(".//node[@class='processor']")[0]
> +
> + #system firmware info
> + sysfwinfo = inventory.xpath('.//node[@id="firmware"]')[0]
> + #create dictionary with key-values for version and date
> + SystemFirmware = dict(version = sysfwinfo.findtext('version'), date =
> sysfwinfo.findtext('date'))
> + #add to data
> + data['SystemFirmware'] = SystemFirmware
> +
I guess this is not quite the right place... There is a loop starting
line 492:
for device in devices:
where it compiles the list of devices with the properties for each one.
I guess you would just fill in fw_version and fw_date there, whenever
the values exist.
--
Dan Callaghan <dcallagh(a)redhat.com>
Senior Software Engineer, Products & Technologies Operations
Red Hat
_______________________________________________
Beaker-devel mailing list -- beaker-devel(a)lists.fedorahosted.org
To unsubscribe send an email to beaker-devel-leave(a)lists.fedorahosted.org
6 years, 8 months