Offering lshw based inventory scans for new architectures

[Nick Coghlan]

As we add new experimental architectures, we're in the situation where
we don't currently have a working inventory scan for those systems,
since newer versions of the operating system that support those
architectures are also missing smolt.

So, here's my question: would it be possible to tweak beaker-system-scan
such that, if smolt is available, we use it in preference to lshw, but
otherwise, we just rely on lshw?

My idea here is that, for existing architectures, we would run the
inventory task on an OS with smolt, to make sure we continue to supply
the same data we always have, until we're sure we have lshw to the point
where it's a suitable replacement.

But for new architectures, supplying whatever lshw can give us today
(along with the rest of the info beaker-system-scan collects) would be
better than nothing, so it makes sense to at least do that, and skip the
parts that depend on smolt.

Does this approach make sense to anyone else? Would it be reasonably
easy to just skip the smolt-based components of the scan when it wasn't
available?

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect

[Dan Callaghan]

Excerpts from Nick Coghlan's message of 2014-07-21 16:29 +10:00:
>  As we add new experimental architectures, we're in the situation
> where
>  we don't currently have a working inventory scan for those systems,
>  since newer versions of the operating system that support those
>  architectures are also missing smolt.
>  
>  So, here's my question: would it be possible to tweak beaker-system-scan
>  such that, if smolt is available, we use it in preference to lshw, but
>  otherwise, we just rely on lshw?
>  
>  My idea here is that, for existing architectures, we would run the
>  inventory task on an OS with smolt, to make sure we continue to supply
>  the same data we always have, until we're sure we have lshw to the point
>  where it's a suitable replacement.
>  
>  But for new architectures, supplying whatever lshw can give us today
>  (along with the rest of the info beaker-system-scan collects) would be
>  better than nothing, so it makes sense to at least do that, and skip the
>  parts that depend on smolt.
>  
>  Does this approach make sense to anyone else? Would it be reasonably
>  easy to just skip the smolt-based components of the scan when it wasn't
>  available? 
It's a nice idea, but it would require some re-work of the lshw patch 
(which just wholesale replaces all usages of smolt). I don't think it's 
worth the effort -- I would rather we just bite the bullet and get the 
migration done.

We still need to see a summary of the gaps in lshw's coverage compared 
to smolt. I think Amit has scripts for this, it's just a matter of 
finding the time to get a hold of a representative sample of systems and 
run the comparison on them all and examine the results.

Once we see that comparison, we will at least have some idea of how much 
work is still needed on lshw. If it turns out there are lots of big 
gaps, we can go ahead with this approach of using smolt otherwise 
falling back to lshw.

-- 
Dan Callaghan <dcallagh(a)redhat.com&gt;
Software Engineer, Hosted & Shared Services
Red Hat, Inc.

[Amit Saha]

----- Original Message -----
>  From: "Dan Callaghan" <dcallagh(a)redhat.com&gt;
>  To: "beaker-devel" <beaker-devel(a)lists.fedorahosted.org&gt;
>  Sent: Tuesday, July 22, 2014 6:06:01 PM
>  Subject: Re: [Beaker-devel] Offering lshw based inventory scans for new	architectures
>  
>  Excerpts from Nick Coghlan's message of 2014-07-21 16:29 +10:00:
>  > As we add new experimental architectures, we're in the situation where
>  > we don't currently have a working inventory scan for those systems,
>  > since newer versions of the operating system that support those
>  > architectures are also missing smolt.
>  > 
>  > So, here's my question: would it be possible to tweak beaker-system-scan
>  > such that, if smolt is available, we use it in preference to lshw, but
>  > otherwise, we just rely on lshw?
>  > 
>  > My idea here is that, for existing architectures, we would run the
>  > inventory task on an OS with smolt, to make sure we continue to supply
>  > the same data we always have, until we're sure we have lshw to the point
>  > where it's a suitable replacement.
>  > 
>  > But for new architectures, supplying whatever lshw can give us today
>  > (along with the rest of the info beaker-system-scan collects) would be
>  > better than nothing, so it makes sense to at least do that, and skip the
>  > parts that depend on smolt.
>  > 
>  > Does this approach make sense to anyone else? Would it be reasonably
>  > easy to just skip the smolt-based components of the scan when it wasn't
>  > available?
>  
>  It's a nice idea, but it would require some re-work of the lshw patch
>  (which just wholesale replaces all usages of smolt). I don't think it's
>  worth the effort -- I would rather we just bite the bullet and get the
>  migration done. 
Indeed. The current approach that we have is a wholesale replacement. A conditional
use of smolt or lshw *can* be done, however.

>  
>  We still need to see a summary of the gaps in lshw's coverage compared
>  to smolt. I think Amit has scripts for this, it's just a matter of
>  finding the time to get a hold of a representative sample of systems and
>  run the comparison on them all and examine the results. 
That's right. I do have some scripts that generate a HTML table listing the
comparative results which should give us a good indication of the gaps between
smolt and lshw. I will try to get those up somewhere along with some results as
soon as I can.

>  
>  Once we see that comparison, we will at least have some idea of how much
>  work is still needed on lshw. If it turns out there are lots of big
>  gaps, we can go ahead with this approach of using smolt otherwise
>  falling back to lshw. 
Sounds like a good approach.


-- 
Amit Saha 
SED, Hosted & Shared Services
Red Hat, Inc.