[libvirt] [PATCH] domain_conf: fix graphics parsing

[Cole Robinson]

On 04/11/2016 11:59 AM, Laine Stump wrote:
> On 04/11/2016 09:44 AM, Cole Robinson wrote:
>> On 04/11/2016 07:37 AM, Pavel Hrdina wrote:
>>> +  <devices>
>>> +    <emulator>/usr/bin/qemu</emulator>
>>> +    <disk type='block' device='disk'>
>>> +      <driver name='qemu' type='raw'/>
>>> +      <source dev='/dev/HostVG/QEMUGuest1'/>
>>> +      <target dev='hda' bus='ide'/>
>>> +      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
>>> +    </disk>
>> When adding new tests I think we should shoot for dropping as many redundant
>> devices as possible... it's just extra time spent in the test suite. Not a
>> blocker, just a general comment
> 
> I was thinking the same thing the last time I was messing with the tests. A
> bit of redundancy can be a good thing, but we're testing the same paths of the
> same code hundreds of times in many cases, which not only takes extra runtime,
> but also makes for much larger patches when there is an expected/correct
> change, and can lead to failures in seemingly unrelated tests when there is an
> unintentional change.
> 
> The problem (well, not really a problem in itself, but it's what leads to all
> the redundancy) is that we all make new tests by copying an old one in order
> to start out with something that is by definition correct - that's quicker
> than starting from scratch. In the most recent set of tests I added (for pxb)
> I tried removing as much obviously non-essential stuff as possible. Maybe
> having a "minimal" case for each test that could be pointed at in
> documentation as a template would be a help? (Or maybe they would be just more
> extra redundancy that would be ignored, not sure)
> 

a minimal test/template would be nice. but also we have too many test cases
anyways... many of the tests for qemu argv generation could be consolidated,
like testing multiple disk configs in a single XML file for example. But part
of that is checking gcov output to make sure we don't regress our coverage. I
plan to come up with a few sample commits for things like that and then link
them on BiteSizedTasks wiki page as a new contributor idea

- Cole