Bug 915815

Summary:	FEAT: add a locally hosted option for kernelinfo.xml
Product:	[Retired] Red Hat Hardware Certification Program	Reporter:	Rob Landry <rlandry>
Component:	Test Suite (harness)	Assignee:	Greg Nichols <gnichols>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	1.7	CC:	bbrock, chorn, czhang, mfuruta, myamazak, rlandry
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	hwcert-client-1.7.0-R26	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	918739 918741 (view as bug list)		Environment:
Last Closed:	2013-04-12 03:12:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	918739, 918741

Description Rob Landry 2013-02-26 15:07:44 UTC

Use case:

Users behind a firewall or other restricted access lab could use an updated kernelinfo.xml and we would prefer not to spin a new package for the sole purpose of a new kernel has been released.

Expected results:

A kernelinfo.xml could be hosted on an internal server similar to the fv images allowing the info test to verify the GA kernel version info.

Additional info:

We could add a signature check to verify remove files including this xml (which is a reasonable idea anyway).  The purpose isn't security as in saftey but more to verifying it's the content we expect/know since we do not have rpm verify to use.  This could apply to fv images too or anything else we call home to retrieve.  (Should this be a separate bug/feature?)

We can also allow for a manually edited version with a warning or error the catalog/review team can catch but also provide a warning to the local user so they can address it before they do a bunch of testing against a bad file.

Comment 1 Christian Horn 2013-02-26 15:31:23 UTC

Looks ok to me, although I think the "hosting on the intranet" part is overcomplicating things. Just having a defined location on the local filesystem where an updated kernelinfo.xml might exist would be easier to use.

Comment 2 Rob Landry 2013-02-27 22:13:28 UTC

(In reply to comment #1)
> Looks ok to me, although I think the "hosting on the intranet" part is
> overcomplicating things. Just having a defined location on the local
> filesystem where an updated kernelinfo.xml might exist would be easier to
> use.

This already exists in a way but it will cause the rpm -V of v7 to fail.  I think if we just fully mimic the fv structure; which supports, RH hosted, $server hosts, and local hosted images; we'll cover all of the bases.

Greg, should I open another bug for local filesystem provided kernelinfo.xml?

Should the signing infrastructure be in it's own bug?

Comment 3 Christian Horn 2013-02-28 15:59:31 UTC

Singning and verifying the signature with a gpg pubkey which is part of the v7 suite sounds like a sane method indeed. Alternatively we could put the updated kernelinfo.xml into a separate rpm (but I favor the signature piece).

Comment 4 Greg Nichols 2013-04-08 14:47:56 UTC

We've split off kernelInfo.xml into it's own package: hwcert-client-info.   The info test verifies both hwcert-client and hwcert-info.   I believe this satisfies the locally-hosted option, as the packages can be locally-hosted.

Comment 6 Rob Landry 2013-04-10 20:17:30 UTC

Should this bug be retitled?

Comment 7 Caspar Zhang 2013-04-11 09:01:07 UTC

I think so.