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
(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:
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
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
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(a)redhat.com>
Software Engineer, Products & Technologies Operations
Red Hat, Inc.