[Libvirt-cim] [RFC] Patches need no testcase

[Wenchao Xia]

于 2013-3-5 7:49, John Ferlan 写道:
> On 01/16/2013 12:46 AM, Wenchao Xia wrote:
>> Hi, Danial
>>    Happy new year!
>>    Could u have a look v3 serial of libcmpituil patches? It is simple
>> and need no test case, hope it can be merged if no problem found.
>>
>
> First off - let me introduce myself... I'm (relatively) new to Red Hat
> having joined in Dec 2012 from HP where I worked on Virtualization
> products at HP.  Primarily I was responsible for the API/CLI space of
> the HPVM product. I also was part of a project that created what HP
> calls VirtProvider which was a DSP2013 CIM Provider.  Since I knew how
> to spell CIM and had some history, I was asked to take a look at
> failures that Yanbing Du posted questions about back in October:
>
> https://www.redhat.com/archives/libvirt-cim/2012-October/msg00000.html
>
> Sorry in advance for the length of the rest of this...
>
    It is very nice to hear new people comes to libvirt-cim, although
the developement slows down but user are still there, it need to be
taken care of. Welcome the libvirt-cim project. :).

> While this won't be a full time endeavour, putting some cycles on
> libvirt-cim has been added to my list of things to do. I still need a
> bit of help - I'm not quite sure of the "proper procedure" to use when
> testing a local libvirt-cim build. The only way I was able to make
> things work was remove the libvirt-cim package (rpm -e) and then
> reinstall (yum localinstall from build rpm in a 'make rpm'). I tried the
> install/postinstall process with stopping/starting tog-pegasus, but
> couldn't quite get things to work.
>
   Using "rpm -e [old rpm]" and "rpm -ivh [new rpm]" should be enough to
test new libvirt-cim. I am not sure how you install/postinstall it, in
common case of test, these steps are not needed.

> Getting "up to speed" was a bit of a challenge as the libvirt CIM web
> pages seem to be a bit out of date and perhaps assume a few things along
> the way. I've taken some notes, but was eventually able to get things
> installed.  I'm still working through some of the "kinks".
>
> Setting up a CIMserver with tog_pegasus was not something I did at HP,
> so it was a bit of an adventure. Eventually I worked my way through
> things with lots of trial and error. Following the README instructions I
> ran into two issues during the post installation phase, which I'm
> somewhat curious if long time users would also hit (not that many are
> active any more):
>
   I haven't installed it either, always used the rpm. Can't you use
"rpm -ivh" to install/replace tog_pegasus?


> #1: The commit id '22022870d' to Makefile.am which essentially added
> "$(top_srcdir)/" in front of the "schema" directory path caused the
> 'make postinstall' to fail (at least on my fedora18 system).  The
> problem is that the path ends up as ".//usr/..." the "./" being the
> problem with respect to the ability to "find" the files. Stripping that
> off allows finding files to be found again.  The fix is to modify the
> various "$(subst schema" and replace them with "$(subst
> $(top_srcdir)/schema" - this allowed me to continue.
>
> #2: After that was solved, as things were scrolling past I noted that
> there was some sort of issue with "schema/SwitchService.registration".
> In looking at the file, it seems the blank line at the end of the file
> caused some sort of "issue", so I removed it and the registration was
> happier.
>
> After those changes I was able to run through the 'cimtest' using the
> most recent libvirt (what is looking to be 1.0.3).  I didn't see all the
> same errors, but did trip across a few.
>
> Figuring that perhaps some of those were fixed by patches that I knew
> were out there, I went back to start looking, applying, and running
> cimtest again for tests that failed for me.
>
> I downloaded and applied the Dec 2012 patches for libvirt-cim (v3 01 ->
> 11 and v4 DevicePool) and libcmpiutil (v3 1&2) as well as the Nov 2012
> patch submitted by Jirka. I believe that gets me "up to date".  Although
> it was a bit confusing as what I should have done for the v4 patches on
> 12/25/12 was to "replace" the 12/18/12 patches 6 and 10. Luckily it was
> a quick retrace of my steps.
>
   Sorry for the trouble of different versions, glad you replaced the
correct patches. :)

> Unfortunately it didn't seem I was "using" the changes when I ran
> "make", "make preinstall", "make install", & "make postinstall". So, I
> figured I'd try to make a new distribution to see if that would work.  I
> got a bit further; however, the 'make distcheck' failed for me much in
> the same way the 'make postinstall' did above.  So I adjusted commit id
> '9f5e204f' to rather than "$(subst ./schema," use "$(subst
> $(top_srcdir)/schema" which resolve the issue I was running into. Once I
> did the 'rpm -e libvirt-cim', I was able to install the rpm I build and
> test the changes.
>
   I haven't try it on Fedora, but usually on RH I use "make rpm" from
source code to build a rpm, then replace the rpm and test. "make
install" seems have problem before and I am not sure if it works
now, so please use rpm replacing if it work on Fedora.

> The (partial) good news is between the fixes provided in the December
> patches and some of my own I can get a majority of cimtest to succeed.
> I've had to make other adjustments, but I figured that'd be par for the
> course anyway.
>
> So some comments about your changes. Now that I have a little more
> experience I'll look at the other changes more in depth, but these two
> popped out due to me running into "issues" with them.
>
> Patch 01/11:
>   * The change for 'bridge' networks and not allowing scripts is only for
> qemu domains.  Apparently Xen domains would still support the script.
> So while your change does effectively remove it for Qemu, doing so for
> Xen could be a regression (I have no way to test).
>
> See the following for my logic:
>
> http://www.redhat.com/archives/libvir-list/2012-January/msg00240.html
>
> Before I had applied your patches I had made a similar change except
> that I passed along the dominfo->type to the bridge_net_to_xml()
> function and then test in there whether or not the "script" should be
> added based on type of DOMAIN_XENPV or DOMAIN_XENFV.
   This seems a safer way, since we both lack a ENV to test for Xen, If
you wish you could form a patch for it, replace mine in the serial.


>
>
> Patch 09/11
>   * This change caused the 'make distcheck" to fail. The
> 'wait_for_event()' routine has a "ret" variable that is unused.
>
   My bad, this check is not done before.

>
> Some changes I've made to 'cimtest' in order to get things to work
>
>   * The test makes use of setting a MAC in quite a few places,
> unfortunately the MAC chosen for most (99:aa:bb:cc:ee:ff) is a Multicast
> Address.  We know this because the low bit of the first byte (e.g. "99")
> is set (in hex 0x10011001).  Changing those references to "88" works.
>
>   * ComputerSystemIndication and RASDIndications fail for me. After a
> long pause, I got a Python stack trace where it looks like it's trying
> to print testsuite results.  What that turns out to be is the
> 'os_status' being passed along is the errno value for 'ETIMEDOUT' (eg.
> 110).  Using 110 to index into the rc[] record in Reporter.py causes a
> KeyError exception.  I "fixed" that by checking if os_status was outside
> of the valid range and if so, set it to FAIL, but log that I did so.
>
>   * Profile/04_verify_libvirt_cim_slp_profiles.py has a bug.  It only
> checks for "slp" when it should check "slp=true".
>
   Yes, this test case seems need slp server configured correctly and
it never passed on my machine, but user of libvirt-cim with slp=true
works fine, suggest ignore this case.

>   * Looking for the NFS Server at /sbin/init.d/nfs doesn't work any more
> with the usage of systemd in order to start/stop daemons. I adjusted the
> code accordingly
>
>   * The ResourcePoolConfigurationService tests 08, 09, & 15 try to create
> a pool pointing at /var/lib/libvirt/images which causes a failure
> because cimtest-diskpool already exists and uses it.  Not sure if this
> is a new check or not (remember I haven't been here that long).
   Fails also in mine machine, seems a error in cimtest code.

>
> My current results have 173 of 192 tests passing. There are 4 FAIL, 4
> XFAIL, and 11 SKIP (mostly migration which I haven't figured out yet).
> 2 of the SKIP's are because I already had a domains and storage pools
> defined on my system.
>
   This is really nice, I have 8 FAIL. Before I ignored them because
in error message it shows as testcase issue not libvirt-cim's problem.
If you can form patches for cimtest and verify it on RH, pls post
them on maillist, they will be very helpful, fixing the problems
remains in cimtest for a long time.

   I am working on qemu dev now but will still pay time for libvirt-cim
for bug/patches. If you like you can post your patches and let me
review. We really need new libvirt-cim 0.6.2 release fast to eliminate
bug reports for old 0.6.1.

>
> John
>
>
>
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim
>


-- 
Best Regards

Wenchao Xia