[Beaker-devel] Simplify inventorying systems in Beaker

Dan Callaghan dcallagh at redhat.com
Mon May 4 05:27:41 UTC 2015


Excerpts from Amit Saha's message of 2015-05-04 14:56 +10:00:
> So, the key step is to figure out which distro to use. RHEL6/CentOS6 
> would cover most
> of the hardware, but there may be exceptions for older/newer hardware 
> archs. So, here is
> what I am thinking:
> 
> 1. Start with RHEL6/CentOS6, and check if the system is compatible 
> with it. If yes, go to step 4, else go to step 2.
> 
> 2. Is the system compatible with RHEL7/CentOS7? If yes, go to step 4, 
> else go to step 3.
> 
> 3. Is the system compatible with RHEL5/CentOS5? If yes, go to step 4, 
> else error out.
> 
> 4. Submit a job with the chosen distro and /distribution/install and 
> /distribution/inventory tasks.
> (The job will use the <hostRequires force = .. /> element so that all 
> non-removed systems can be inventoried
> as long as the job owner has the sufficient rights on the system)

Yes, this sounds good. Beaker will need to pick the family based on what 
is not excluded and also what is available in the lab. RHEL should be 
preferred over CentOS. So I guess the priority list is:

RedHatEnterpriseLinux6
CentOS6
RedHatEnterpriseLinux7
CentOS7
RedHatEnterpriseLinux5
CentOS5

Can we also add Fedora (any release I suppose) to the bottom of the 
list? lshw will be there, albeit without our patches, but what about 
beaker-system-scan? Can we add it to our Fedora harness repos? I am just 
thinking of e.g. beaker.fedoraproject.org which only has Fedora trees.

> One immediate drawback of this is using hard coded distro names above. 
> 
> Another idea I can think of is have a system level ksmeta variable 
> defined such as "inventory_distro=MyOSMajor"
> and use that. But that is asking of system owners/beaker admins to 
> have to do that explicitly. It would also vastly simplify the 
> implementation.

Allowing the admin/system owner to specify might be handy but I don't 
think we can use ksmeta for it. All the current ksmeta computation 
assumes you already have a distro tree to start with, whereas here we 
would be using the ksmeta to actually pick a distro tree. I suspect the 
implementation would actually be very messy.

I think having some hardcoded rules in Beaker is fine, if someone wants 
to use a different distro they can always construct a job explicitly 
(using bkr machine-test or workflow-simple or any other way).

-- 
Dan Callaghan <dcallagh at redhat.com>
Software Engineer, Products & Technologies Operations
Red Hat, Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/beaker-devel/attachments/20150504/54046e8d/attachment.sig>


More information about the Beaker-devel mailing list