Hide Forgot
Description of problem: Enumerating instances of LMI_Chassis via pywbem-yawn results in "CSCreationClassName is empty" error with sfcb Version-Release number of selected component (if applicable): How reproducible: Always Did not happen with openlmi-providers 0.4.0 Steps to Reproduce: 1. Install sfcb and openlmi-tools-0.9-1.noarch openlmi-providers-0.4.1-1.x86_64 openlmi-networking-0.2.1-1.x86_64 openlmi-hardware-0.4.1-1.x86_64 openlmi-fan-0.4.1-1.x86_64 openlmi-service-0.4.1-1.x86_64 openlmi-indicationmanager-libs-0.4.1-1.x86_64 openlmi-python-base-0.4.1-1.noarch openlmi-python-providers-0.4.1-1.noarch openlmi-software-0.4.1-1.noarch openlmi-powermanagement-0.4.1-1.x86_64 openlmi-logicalfile-0.4.1-1.x86_64 openlmi-realmd-0.4.1-1.x86_64 openlmi-account-0.4.1-1.x86_64 on openSUSE 12.3 2. Run pywbem-yawn 3. Get instance of LMI_Chassis 4. Click on "Object Associated with this Instance" Actual results: "CSCreationClassName is empty" error Expected results: List of associated instances Additional info:
Oh, sorry for not looking for the obvious. A similar bug was already reported in https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-October/001811.html While version 0.4.1 is not crashing for me, the check for CSCreationClassName (and CSName) in src/logicalfile/file.c might just be wrong for associations.
The call to lmi_check_required comes from src/logicalfile/LMI_FileIdentityProvider.c:172 in its references() implementation.
Patch sent for review: http://reviewboard-openlmi.rhcloud.com/r/1242/
And another one: https://reviewboard-openlmi.rhcloud.com/r/1245/
Both are now upstream as https://git.fedorahosted.org/cgit/openlmi-providers.git/commit/?id=fd36206ba36e169eaad9421b0e624feb02b5abff
Works perfectly now, thanks a lot !
I pushed a fix to 0.4-fixes and master branches and it will be available in next OpenLMI release.