[RESEND PATCH 0/3] libvirt-cim: Fix provider registration
The following series fixes two issues in the provider registration process of the libvirt-cim RPM package. First, the RPM scriptlets didn't properly reflect the invocation sequence during an RPM upgrade. This is fixed by the first patch. Further, the registration using wildcards (*.mof) failed because of an inter-MOF depedency. Fixed by the second patch. Finally, the class deletion sequence in provider-register.sh was prone to failure, resulting in residual entries in the Pegasus class repository. Addressed by third patch. Note: since the redhat.com mailing lists are bouncing my emails I am sending from a different account temporarily until this is resolved. Viktor Mihajlovski (3): build: Fix incorrect provider registration in upgrade path build: Fix provider registration issues schema: Fix class removal with Pegasus libvirt-cim.spec.in | 282 ++++++++++++++++++++++++++++++++++++++++---------- provider-register.sh | 8 +- 2 files changed, 231 insertions(+), 59 deletions(-) -- 1.7.9.5
The scriplet logic was incorrectly assuming that the superseded package's %postun script would be called before the superceding packages %pre/%post. This effectively broke upgrades of libvirt-cim because all the providers were deregistered. We are now checking whether we are in an upgrade situation and if so will not deregister the providers in postun. Another enhancement is that we do a full deregistration in the %post section for tog-pegasus now. This should make installs and upgrades more robust against potentially damaged repositories (e.g., on development systems). As a reminder here's a short description of RPM's scriptlet processing. action: install upgrade uninstall %pre 1 >1 - %post 1 >1 - %preun - 1 0 %postun - 1 0 Scriptlet invocation order on upgrade 1. %pre(new_package) 2. %post(new_package) 3. %preun(old_package) 4. %postun(old_package) Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> --- libvirt-cim.spec.in | 115 ++++++++++++++++++++++++++++++--------------------- 1 file changed, 68 insertions(+), 47 deletions(-) diff --git a/libvirt-cim.spec.in b/libvirt-cim.spec.in index 459650c..b50cbd1 100644 --- a/libvirt-cim.spec.in +++ b/libvirt-cim.spec.in @@ -64,7 +64,6 @@ mkdir -p $RPM_BUILD_ROOT@INFO_STORE@ %clean rm -fr $RPM_BUILD_ROOT -%pre %define REGISTRATION %{_datadir}/%{name}/*.registration %define SCHEMA %{_datadir}/%{name}/*.mof @@ -77,24 +76,46 @@ rm -fr $RPM_BUILD_ROOT %define CIMV2_REG %{_datadir}/%{name}/{HostedResourcePool,ElementCapabilities,HostedService,HostedDependency,ElementConformsToProfile,HostedAccessPoint}.registration %define CIMV2_MOF %{_datadir}/%{name}/{HostedResourcePool,ElementCapabilities,HostedService,HostedDependency,RegisteredProfile,ComputerSystem,ElementConformsToProfile,HostedAccessPoint}.mof +%pre # _If_ there is already a version of this installed, we must deregister # the classes we plan to install in post, otherwise we may corrupt # the pegasus repository. This is convention in other provider packages -%{_datadir}/%{name}/provider-register.sh -d -t pegasus \ - -n @CIM_VIRT_NS@ \ - -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true +if [ $1 -gt 1 ] +then + if [ -x /usr/sbin/cimserver ] + then + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n @CIM_VIRT_NS@ \ + -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/interop \ + -r %{INTEROP_REG} -m %{INTEROP_MOF} -v >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/PG_InterOp \ + -r %{PGINTEROP_REG} -m %{PGINTEROP_MOF} -v >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/cimv2\ + -r %{CIMV2_REG} -m %{CIMV2_MOF} -v >/dev/null 2>&1 || true + fi # Remove open-pegasus-specific providers installed in sfcb repository # by older libvirt-cim packages -%{_datadir}/%{name}/provider-register.sh -d -t sfcb \ - -n root/PG_InterOp \ - -r %{PGINTEROP_REG} -m %{PGINTEROP_MOF} >/dev/null 2>&1 || true - + if [ -x /usr/sbin/sfcbd ] + then + %{_datadir}/%{name}/provider-register.sh -d -t sfcb \ + -n root/PG_InterOp \ + -r %{PGINTEROP_REG} -m %{PGINTEROP_MOF} >/dev/null 2>&1 || true + fi +fi %post /sbin/ldconfig -%{_datadir}/%{name}/install_base_schema.sh %{_datadir}/%{name} +if [ $1 -eq 1 ] +then +# Install the CIM base schema if this is the initial install + %{_datadir}/%{name}/install_base_schema.sh %{_datadir}/%{name} +fi %if 0%{?fedora} >= 17 || 0%{?rhel} >= 7 if [ "`systemctl is-active tog-pegasus.service`" = "active" ] @@ -112,65 +133,65 @@ rm -fr $RPM_BUILD_ROOT if [ -x /usr/sbin/cimserver ] then -%{_datadir}/%{name}/provider-register.sh -t pegasus \ + %{_datadir}/%{name}/provider-register.sh -t pegasus \ -n @CIM_VIRT_NS@ \ -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t pegasus \ - -n @CIM_VIRT_NS@ \ - -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t pegasus \ + %{_datadir}/%{name}/provider-register.sh -t pegasus \ -n root/interop \ -r %{INTEROP_REG} -m %{INTEROP_MOF} -v >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t pegasus \ + %{_datadir}/%{name}/provider-register.sh -t pegasus \ -n root/PG_InterOp \ -r %{PGINTEROP_REG} -m %{PGINTEROP_MOF} -v >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t pegasus \ + %{_datadir}/%{name}/provider-register.sh -t pegasus \ -n root/cimv2\ -r %{CIMV2_REG} -m %{CIMV2_MOF} -v >/dev/null 2>&1 || true fi if [ -x /usr/sbin/sfcbd ] then -%{_datadir}/%{name}/provider-register.sh -t sfcb \ - -n root/virt \ - -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t sfcb \ + %{_datadir}/%{name}/provider-register.sh -t sfcb \ -n root/virt \ -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t sfcb \ + %{_datadir}/%{name}/provider-register.sh -t sfcb \ -n root/interop \ -r %{INTEROP_REG} -m %{INTEROP_MOF} -v >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -t sfcb \ + %{_datadir}/%{name}/provider-register.sh -t sfcb \ -n root/cimv2\ -r %{CIMV2_REG} -m %{CIMV2_MOF} -v >/dev/null 2>&1 || true fi %preun -if [ -x /usr/sbin/cimserver ] +# The uninstall scriptlets are called after the install scriptlets +# in the upgrade case. Therefore we must only deregister the providers +# when $1 == 0 (final remove). +if [ $1 -eq 0 ] then -%{_datadir}/%{name}/provider-register.sh -d -t pegasus \ - -n root/virt \ - -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -d -t pegasus \ - -n root/interop \ - -r %{INTEROP_REG} -m %{INTEROP_MOF} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -d -t pegasus \ - -n root/PG_InterOp \ - -r %{PGINTEROP_REG} -m %{PGINTEROP_MOF} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -d -t pegasus \ - -n root/cimv2 \ - -r %{CIMV2_REG} -m %{CIMV2_MOF} >/dev/null 2>&1 || true -fi -if [ -x /usr/sbin/sfcbd ] -then -%{_datadir}/%{name}/provider-register.sh -d -t sfcb \ - -n root/virt \ - -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -d -t sfcb \ - -n root/interop \ - -r %{INTEROP_REG} -m %{INTEROP_MOF} >/dev/null 2>&1 || true -%{_datadir}/%{name}/provider-register.sh -d -t sfcb \ - -n root/cimv2 \ - -r %{CIMV2_REG} -m %{CIMV2_MOF} >/dev/null 2>&1 || true + if [ -x /usr/sbin/cimserver ] + then + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/virt \ + -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/interop \ + -r %{INTEROP_REG} -m %{INTEROP_MOF} >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/PG_InterOp \ + -r %{PGINTEROP_REG} -m %{PGINTEROP_MOF} >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t pegasus \ + -n root/cimv2 \ + -r %{CIMV2_REG} -m %{CIMV2_MOF} >/dev/null 2>&1 || true + fi + if [ -x /usr/sbin/sfcbd ] + then + %{_datadir}/%{name}/provider-register.sh -d -t sfcb \ + -n root/virt \ + -r %{REGISTRATION} -m %{SCHEMA} >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t sfcb \ + -n root/interop \ + -r %{INTEROP_REG} -m %{INTEROP_MOF} >/dev/null 2>&1 || true + %{_datadir}/%{name}/provider-register.sh -d -t sfcb \ + -n root/cimv2 \ + -r %{CIMV2_REG} -m %{CIMV2_MOF} >/dev/null 2>&1 || true + fi fi %postun -p /sbin/ldconfig -- 1.7.9.5
This commit addresses an issue with provider registration during RPM install or update. The schema registration by wildcard doesn't take into consideration that there are dependencies between the MOF files leading to a partially populated repository and a not working libvirt-cim provider. Fixed by explicitly stating the mof and registration files in the necessary order. Further a minor false error message coming from the systemd service detection was bound to cause irritation. This is suppressed now. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> --- libvirt-cim.spec.in | 167 ++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 157 insertions(+), 10 deletions(-) diff --git a/libvirt-cim.spec.in b/libvirt-cim.spec.in index b50cbd1..c96451b 100644 --- a/libvirt-cim.spec.in +++ b/libvirt-cim.spec.in @@ -64,17 +64,164 @@ mkdir -p $RPM_BUILD_ROOT@INFO_STORE@ %clean rm -fr $RPM_BUILD_ROOT -%define REGISTRATION %{_datadir}/%{name}/*.registration -%define SCHEMA %{_datadir}/%{name}/*.mof +%define REGISTRATION %{_datadir}/%{name}/ComputerSystem.registration \\\ + %{_datadir}/%{name}/LogicalDisk.registration \\\ + %{_datadir}/%{name}/NetworkPort.registration \\\ + %{_datadir}/%{name}/Memory.registration \\\ + %{_datadir}/%{name}/Processor.registration \\\ + %{_datadir}/%{name}/SystemDevice.registration \\\ + %{_datadir}/%{name}/VSSD.registration \\\ + %{_datadir}/%{name}/HostSystem.registration \\\ + %{_datadir}/%{name}/HostedDependency.registration \\\ + %{_datadir}/%{name}/VirtualSystemManagementService.registration \\\ + %{_datadir}/%{name}/VirtualSystemManagementCapabilities.registration \\\ + %{_datadir}/%{name}/EnabledLogicalElementCapabilities.registration \\\ + %{_datadir}/%{name}/AllocationCapabilities.registration \\\ + %{_datadir}/%{name}/SettingsDefineCapabilities.registration \\\ + %{_datadir}/%{name}/MemoryPool.registration \\\ + %{_datadir}/%{name}/ElementCapabilities.registration \\\ + %{_datadir}/%{name}/ProcessorPool.registration \\\ + %{_datadir}/%{name}/DiskPool.registration \\\ + %{_datadir}/%{name}/HostedResourcePool.registration \\\ + %{_datadir}/%{name}/ComputerSystemIndication.registration \\\ + %{_datadir}/%{name}/ResourceAllocationSettingDataIndication.registration \\\ + %{_datadir}/%{name}/SwitchService.registration \\\ + %{_datadir}/%{name}/ComputerSystemMigrationIndication.registration \\\ + %{_datadir}/%{name}/ResourceAllocationSettingData.registration \\\ + %{_datadir}/%{name}/ResourcePoolConfigurationService.registration \\\ + %{_datadir}/%{name}/ResourcePoolConfigurationCapabilities.registration \\\ + %{_datadir}/%{name}/VSSDComponent.registration \\\ + %{_datadir}/%{name}/SettingsDefineState.registration \\\ + %{_datadir}/%{name}/NetPool.registration \\\ + %{_datadir}/%{name}/ResourceAllocationFromPool.registration \\\ + %{_datadir}/%{name}/ElementAllocatedFromPool.registration \\\ + %{_datadir}/%{name}/HostedService.registration \\\ + %{_datadir}/%{name}/ElementSettingData.registration \\\ + %{_datadir}/%{name}/VSMigrationCapabilities.registration \\\ + %{_datadir}/%{name}/VSMigrationService.registration \\\ + %{_datadir}/%{name}/ElementConformsToProfile.registration \\\ + %{_datadir}/%{name}/VSMigrationSettingData.registration \\\ + %{_datadir}/%{name}/VirtualSystemSnapshotService.registration \\\ + %{_datadir}/%{name}/VirtualSystemSnapshotServiceCapabilities.registration \\\ + %{_datadir}/%{name}/ConcreteComponent.registration \\\ + %{_datadir}/%{name}/ConsoleRedirectionService.registration \\\ + %{_datadir}/%{name}/ConsoleRedirectionServiceCapabilities.registration \\\ + %{_datadir}/%{name}/ServiceAffectsElement.registration \\\ + %{_datadir}/%{name}/KVMRedirectionSAP.registration \\\ + %{_datadir}/%{name}/DisplayController.registration \\\ + %{_datadir}/%{name}/PointingDevice.registration \\\ + %{_datadir}/%{name}/GraphicsPool.registration \\\ + %{_datadir}/%{name}/InputPool.registration \\\ + %{_datadir}/%{name}/HostedAccessPoint.registration \\\ + %{_datadir}/%{name}/ServiceAccessBySAP.registration \\\ + %{_datadir}/%{name}/SAPAvailableForElement.registration \\\ + %{_datadir}/%{name}/FilterEntry.registration \\\ + %{_datadir}/%{name}/FilterList.registration \\\ + %{_datadir}/%{name}/EntriesInFilterList.registration \\\ + %{_datadir}/%{name}/NestedFilterList.registration \\\ + %{_datadir}/%{name}/AppliedFilterList.registration \\\ + %{_datadir}/%{name}/HostedFilterList.registration -%define INTEROP_REG %{_datadir}/%{name}/{RegisteredProfile,ElementConformsToProfile,ReferencedProfile}.registration -%define INTEROP_MOF %{_datadir}/%{name}/{ComputerSystem,HostSystem,RegisteredProfile,DiskPool,MemoryPool,NetPool,ProcessorPool,VSMigrationService,ElementConformsToProfile,ReferencedProfile,AllocationCapabilities}.mof +%define SCHEMA %{_datadir}/%{name}/ComputerSystem.mof \\\ + %{_datadir}/%{name}/LogicalDisk.mof \\\ + %{_datadir}/%{name}/NetworkPort.mof \\\ + %{_datadir}/%{name}/Memory.mof \\\ + %{_datadir}/%{name}/Processor.mof \\\ + %{_datadir}/%{name}/SystemDevice.mof \\\ + %{_datadir}/%{name}/Virt_VSSD.mof \\\ + %{_datadir}/%{name}/VSSD.mof \\\ + %{_datadir}/%{name}/HostSystem.mof \\\ + %{_datadir}/%{name}/HostedDependency.mof \\\ + %{_datadir}/%{name}/VirtualSystemManagementService.mof \\\ + %{_datadir}/%{name}/VirtualSystemManagementCapabilities.mof \\\ + %{_datadir}/%{name}/EnabledLogicalElementCapabilities.mof \\\ + %{_datadir}/%{name}/AllocationCapabilities.mof \\\ + %{_datadir}/%{name}/SettingsDefineCapabilities.mof \\\ + %{_datadir}/%{name}/MemoryPool.mof \\\ + %{_datadir}/%{name}/ElementCapabilities.mof \\\ + %{_datadir}/%{name}/ProcessorPool.mof \\\ + %{_datadir}/%{name}/DiskPool.mof \\\ + %{_datadir}/%{name}/HostedResourcePool.mof \\\ + %{_datadir}/%{name}/RegisteredProfile.mof \\\ + %{_datadir}/%{name}/ElementConformsToProfile.mof \\\ + %{_datadir}/%{name}/ComputerSystemIndication.mof \\\ + %{_datadir}/%{name}/ResourceAllocationSettingDataIndication.mof \\\ + %{_datadir}/%{name}/SwitchService.mof \\\ + %{_datadir}/%{name}/ComputerSystemMigrationIndication.mof \\\ + %{_datadir}/%{name}/Virt_ResourceAllocationSettingData.mof \\\ + %{_datadir}/%{name}/ResourceAllocationSettingData.mof \\\ + %{_datadir}/%{name}/ResourcePoolConfigurationService.mof \\\ + %{_datadir}/%{name}/ResourcePoolConfigurationCapabilities.mof \\\ + %{_datadir}/%{name}/VSSDComponent.mof \\\ + %{_datadir}/%{name}/SettingsDefineState.mof \\\ + %{_datadir}/%{name}/NetPool.mof \\\ + %{_datadir}/%{name}/ResourceAllocationFromPool.mof \\\ + %{_datadir}/%{name}/ElementAllocatedFromPool.mof \\\ + %{_datadir}/%{name}/HostedService.mof \\\ + %{_datadir}/%{name}/ElementSettingData.mof \\\ + %{_datadir}/%{name}/VSMigrationCapabilities.mof \\\ + %{_datadir}/%{name}/VSMigrationService.mof \\\ + %{_datadir}/%{name}/VSMigrationSettingData.mof \\\ + %{_datadir}/%{name}/VirtualSystemSnapshotService.mof \\\ + %{_datadir}/%{name}/VirtualSystemSnapshotServiceCapabilities.mof \\\ + %{_datadir}/%{name}/ConcreteComponent.mof \\\ + %{_datadir}/%{name}/ConsoleRedirectionService.mof \\\ + %{_datadir}/%{name}/ConsoleRedirectionServiceCapabilities.mof \\\ + %{_datadir}/%{name}/ServiceAffectsElement.mof \\\ + %{_datadir}/%{name}/KVMRedirectionSAP.mof \\\ + %{_datadir}/%{name}/DisplayController.mof \\\ + %{_datadir}/%{name}/PointingDevice.mof \\\ + %{_datadir}/%{name}/GraphicsPool.mof \\\ + %{_datadir}/%{name}/InputPool.mof \\\ + %{_datadir}/%{name}/HostedAccessPoint.mof \\\ + %{_datadir}/%{name}/ServiceAccessBySAP.mof \\\ + %{_datadir}/%{name}/SAPAvailableForElement.mof \\\ + %{_datadir}/%{name}/FilterEntry.mof \\\ + %{_datadir}/%{name}/FilterList.mof \\\ + %{_datadir}/%{name}/EntriesInFilterList.mof \\\ + %{_datadir}/%{name}/NestedFilterList.mof \\\ + %{_datadir}/%{name}/AppliedFilterList.mof \\\ + %{_datadir}/%{name}/HostedFilterList.mof -%define PGINTEROP_REG %{_datadir}/%{name}/{RegisteredProfile,ElementConformsToProfile,ReferencedProfile}.registration -%define PGINTEROP_MOF %{_datadir}/%{name}/{RegisteredProfile,ElementConformsToProfile,ReferencedProfile}.mof +%define INTEROP_REG %{_datadir}/%{name}/RegisteredProfile.registration \\\ + %{_datadir}/%{name}/ElementConformsToProfile.registration \\\ + %{_datadir}/%{name}/ReferencedProfile.registration -%define CIMV2_REG %{_datadir}/%{name}/{HostedResourcePool,ElementCapabilities,HostedService,HostedDependency,ElementConformsToProfile,HostedAccessPoint}.registration -%define CIMV2_MOF %{_datadir}/%{name}/{HostedResourcePool,ElementCapabilities,HostedService,HostedDependency,RegisteredProfile,ComputerSystem,ElementConformsToProfile,HostedAccessPoint}.mof +%define INTEROP_MOF %{_datadir}/%{name}/ComputerSystem.mof \\\ + %{_datadir}/%{name}/HostSystem.mof \\\ + %{_datadir}/%{name}/RegisteredProfile.mof \\\ + %{_datadir}/%{name}/DiskPool.mof \\\ + %{_datadir}/%{name}/MemoryPool.mof \\\ + %{_datadir}/%{name}/NetPool.mof \\\ + %{_datadir}/%{name}/ProcessorPool.mof \\\ + %{_datadir}/%{name}/VSMigrationService.mof \\\ + %{_datadir}/%{name}/ElementConformsToProfile.mof \\\ + %{_datadir}/%{name}/ReferencedProfile.mof \\\ + %{_datadir}/%{name}/AllocationCapabilities.mof + +%define PGINTEROP_REG %{_datadir}/%{name}/RegisteredProfile.registration \\\ + %{_datadir}/%{name}/ElementConformsToProfile.registration \\\ + %{_datadir}/%{name}/ReferencedProfile.registration + +%define PGINTEROP_MOF %{_datadir}/%{name}/RegisteredProfile.mof \\\ + %{_datadir}/%{name}/ElementConformsToProfile.mof \\\ + %{_datadir}/%{name}/ReferencedProfile.mof + +%define CIMV2_REG %{_datadir}/%{name}/HostedResourcePool.registration \\\ + %{_datadir}/%{name}/ElementCapabilities.registration \\\ + %{_datadir}/%{name}/HostedService.registration \\\ + %{_datadir}/%{name}/HostedDependency.registration \\\ + %{_datadir}/%{name}/ElementConformsToProfile.registration \\\ + %{_datadir}/%{name}/HostedAccessPoint.registration + +%define CIMV2_MOF %{_datadir}/%{name}/HostedResourcePool.mof \\\ + %{_datadir}/%{name}/ElementCapabilities.mof \\\ + %{_datadir}/%{name}/HostedService.mof \\\ + %{_datadir}/%{name}/HostedDependency.mof \\\ + %{_datadir}/%{name}/RegisteredProfile.mof \\\ + %{_datadir}/%{name}/ComputerSystem.mof \\\ + %{_datadir}/%{name}/ElementConformsToProfile.mof \\\ + %{_datadir}/%{name}/HostedAccessPoint.mof %pre # _If_ there is already a version of this installed, we must deregister @@ -118,12 +265,12 @@ then fi %if 0%{?fedora} >= 17 || 0%{?rhel} >= 7 - if [ "`systemctl is-active tog-pegasus.service`" = "active" ] + if [ "`systemctl is-active tog-pegasus.service 2> /dev/null`" = "active" ] then systemctl restart tog-pegasus.service fi - if [ "`systemctl is-active sblim-sfcb.service`" = "active" ] + if [ "`systemctl is-active sblim-sfcb.service 2> /dev/null`" = "active" ] then systemctl restart sblim-sfcb.service fi -- 1.7.9.5
In provider de-registration step, the provider-register.sh script is attempting to delete all libvirt-cim classes from the Pegasus repository. Pegasus refuses to delete classes if it still has child classes in the repository. While the MOF files are processed in reverse order, the classes were still deleted in their original order, which can fail due to inter-class dependencies. Changed to reverse the class deletion order on a per MOF file base. Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> --- provider-register.sh | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/provider-register.sh b/provider-register.sh index b730ef3..abe8e95 100755 --- a/provider-register.sh +++ b/provider-register.sh @@ -332,8 +332,12 @@ pegasus_uninstall() echo "Error: wbemexec not found" >&2 return 1 fi - CLASSES=`cat $mymofs 2> /dev/null | grep '^class'| cut -d ' ' -f 2 | uniq` - + for mof in $mymofs + do + # We must delete the classes in reverse order per MOF file + MOFCLASSES=`cat $mof 2> /dev/null | grep '^[[:space:]]*class' | sed 's/ \+/ /g' | tac | cut -d ' ' -f 2` + CLASSES="$CLASSES $MOFCLASSES" + done for _TEMPDIR in /var/tmp /tmp do if test -w $_TEMPDIR -- 1.7.9.5
On 11/05/2013 04:03 AM, Viktor Mihajlovski wrote:
The following series fixes two issues in the provider registration process of the libvirt-cim RPM package. First, the RPM scriptlets didn't properly reflect the invocation sequence during an RPM upgrade. This is fixed by the first patch. Further, the registration using wildcards (*.mof) failed because of an inter-MOF depedency. Fixed by the second patch. Finally, the class deletion sequence in provider-register.sh was prone to failure, resulting in residual entries in the Pegasus class repository. Addressed by third patch.
Note: since the redhat.com mailing lists are bouncing my emails I am sending from a different account temporarily until this is resolved.
Viktor Mihajlovski (3): build: Fix incorrect provider registration in upgrade path build: Fix provider registration issues schema: Fix class removal with Pegasus
libvirt-cim.spec.in | 282 ++++++++++++++++++++++++++++++++++++++++---------- provider-register.sh | 8 +- 2 files changed, 231 insertions(+), 59 deletions(-)
I'm much of an expert in these matters - in fact pre-novice would summarize my experience with RPM files :-) Things seem reasonable; however, I'm in a bit of a quandary now as I cannot get my libvirt-cim environment to work in order to test. This past Friday I did do a yum update and since that time I cannot seem to get the libvirt-cim provider and cimserver to talk - quite frustrating. I was actually hoping to spend this week reviewing and testing libvirt-cim patches... Now I'm just trying to figure out why two best friends won't speak to each other any more :-) John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11.11.2013 21:58, John Ferlan wrote:
On 11/05/2013 04:03 AM, Viktor Mihajlovski wrote:
The following series fixes two issues in the provider registration process of the libvirt-cim RPM package. First, the RPM scriptlets didn't properly reflect the invocation sequence during an RPM upgrade. This is fixed by the first patch. Further, the registration using wildcards (*.mof) failed because of an inter-MOF depedency. Fixed by the second patch. Finally, the class deletion sequence in provider-register.sh was prone to failure, resulting in residual entries in the Pegasus class repository. Addressed by third patch.
Note: since the redhat.com mailing lists are bouncing my emails I am sending from a different account temporarily until this is resolved.
Viktor Mihajlovski (3): build: Fix incorrect provider registration in upgrade path build: Fix provider registration issues schema: Fix class removal with Pegasus
libvirt-cim.spec.in | 282 ++++++++++++++++++++++++++++++++++++++++---------- provider-register.sh | 8 +- 2 files changed, 231 insertions(+), 59 deletions(-)
I'm much of an expert in these matters - in fact pre-novice would summarize my experience with RPM files :-)
Things seem reasonable; however, I'm in a bit of a quandary now as I cannot get my libvirt-cim environment to work in order to test. This past Friday I did do a yum update and since that time I cannot seem to get the libvirt-cim provider and cimserver to talk - quite frustrating.
I was actually hoping to spend this week reviewing and testing libvirt-cim patches... Now I'm just trying to figure out why two best friends won't speak to each other any more :-) Hi John,
could describe your libvirt-cim environment a bit more detailed (e.g. OS version, installed package versions of libvirt and libvirt-cim, cimserver, etc.)? Maybe we could figure out the error together.
John
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
- -- Mit freundlichen Grüßen / Kind regards Daniel Hansel IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSglrKAAoJEJszBMQcau4WQ3wP/1G1qsKhzOnPfW+joOcV+amd yDGrD+oKm7ivE64phe9YTfn69n5kyoPPLltgtGSSqNHHy6WAnBBi+r/HazSngWlQ K4QrPLPPyJIkHjtgVcNapx3hKSAhcAEqLvkUSn2SQAgv4YGpil3j31jh86fc52m8 meKx43834zASaDWjgEPBMJEM/aCqi++klmM1Hb7P5jwfdHkqwDmgyuIfBhwTAUfN 7BO66F8a1nEA4JUbpLy0tp9ajie9b8NxxPlzdUdx4KhWFytbhty/qG5Vr1sfkjYv HsKi+HG5HRJAnk8FdOLng7gwOTiOvReS7SSkgSwjznGX4PKJn2UzbXysK7Hm7mIx Siz8a9rw9WmF4IApTIf0IlPlQiAdBfa5TOglcjjRDyt4HioyAMNQdLqwTGNtcGJE cc0tDv7uQwMiAXmIqm4oEguNGi8iSQKIJlBjvJ7NcVe4d+3C/1Le/nTy6huPw/RS XPP6b2WeU8+7Irf1Pk+XfMMv0mXSJAPFWREUMcPETvK9VmQMI0I2hUaPo+50CHHp +p3uzcZEG9V3/XCD2JnxPhbYzAzbhYVTqXmE7HYDx9uk1bOZTxDNJeYRu8kAmieA HgkuyAhNrN7OkkSw5DJuD483bR48bDbrt7a7HLkPYwAm+/IAn+zRoDRpBQjdwdlx rK6VvRrYm6BvoEHIvwaH =sNd+ -----END PGP SIGNATURE-----
I'm much of an expert in these matters - in fact pre-novice would summarize my experience with RPM files :-)
Things seem reasonable; however, I'm in a bit of a quandary now as I cannot get my libvirt-cim environment to work in order to test. This past Friday I did do a yum update and since that time I cannot seem to get the libvirt-cim provider and cimserver to talk - quite frustrating.
I was actually hoping to spend this week reviewing and testing libvirt-cim patches... Now I'm just trying to figure out why two best friends won't speak to each other any more :-)
Hi John,
could describe your libvirt-cim environment a bit more detailed (e.g. OS version, installed package versions of libvirt and libvirt-cim, cimserver, etc.)?
Maybe we could figure out the error together.
Sure - I am running f19 on a lenovo t530 - it's my work supplied laptop I generally use the top of the libvirt and libvirt-cim tree, although those didn't change when this issue was discovered. Prior to 10/30/13, I'm not sure which version of tog-pegasus* was installed; however, as of that day the following was installed: Oct 30 08:00:41 Updated: 2:tog-pegasus-libs-2.12.1-8.fc19.x86_64 Oct 30 08:01:08 Updated: 2:tog-pegasus-2.12.1-8.fc19.x86_64 Oct 30 08:01:39 Updated: 2:tog-pegasus-devel-2.12.1-8.fc19.x86_64 a 'cimprovider -l' does not return any KVM_ modules a sure sign of things not working... In order to help dig, I enabled debugging: cimconfig -s traceLevel=4 -c cimconfig -s traceComponents=ALL -c Looking at the cimserver.trc file I find these (sorry about the formatting my auto line wrap is on): 1384276573s-184895us: Repository [7944:139824043710528:FileBasedStore.cpp:631]: Namespace: root#PG_InterOp ignored -- subdirectories are not correctly formed 1384276573s-186825us: L10N [7944:139824043710528:MessageLoader.cpp:418]: Message ID = Common.InternalException.CANNOT_OPEN_DIRECTORY 1384276573s-187030us: Repository [7944:139824043710528:FileBasedStore.cpp:1347]: Namespace: root#PG_InterOp ignored -- subdirectories are not correctly formed 1384276573s-194463us: ProviderManager [7944:139824043710528:ProviderRegistrationManager.cpp:1934]: nameSpace = root/interop; className = PG_ProviderModule I think you get the picture though - there's something about PG_InterOp which is different. Since it's one of those things that 2.12.1-8 release notes discusses as changing in 2.12.1-4, I have a feeling whatever it is the libvirt-cim.spec does in order to "link up" as a provider, does not work in the same way any more. Doing a : wbemcli ein http://root:password@localhost:5988/root/virt:KVM_VirtualSystemManagementSer... gets: 1384277180s-587013us: ProviderManager [9934:140222156466240:ProviderRegistrationManager.cpp:395]: nameSpace = root/virt; className = KVM_VirtualSystemManagementService; className = root/virtkvm_virtualsystemmanagementserviceinstance 1384277180s-587020us: ProviderManager [9934:140222156466240:ProviderRegistrationManager.cpp:406]: Provider capability has not been registered yet. 1384277180s-587028us: Dispatcher [9934:140222156466240:CIMOperationRequestDispatcher.cpp:1465]: Provider for KVM_VirtualSystemManagementService not found. But no output from the wbemcli command. I did try "going backwards" and installing an older rpm, but was not successful. So I borrowed another RHEL6.5 system and am testing over there today. John
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12.11.2013 18:34, John Ferlan wrote:
I'm much of an expert in these matters - in fact pre-novice would summarize my experience with RPM files :-)
Things seem reasonable; however, I'm in a bit of a quandary now as I cannot get my libvirt-cim environment to work in order to test. This past Friday I did do a yum update and since that time I cannot seem to get the libvirt-cim provider and cimserver to talk - quite frustrating.
I was actually hoping to spend this week reviewing and testing libvirt-cim patches... Now I'm just trying to figure out why two best friends won't speak to each other any more :-)
Hi John,
could describe your libvirt-cim environment a bit more detailed (e.g. OS version, installed package versions of libvirt and libvirt-cim, cimserver, etc.)?
Maybe we could figure out the error together.
Sure - I am running f19 on a lenovo t530 - it's my work supplied laptop
I generally use the top of the libvirt and libvirt-cim tree, although those didn't change when this issue was discovered.
Prior to 10/30/13, I'm not sure which version of tog-pegasus* was installed; however, as of that day the following was installed:
Oct 30 08:00:41 Updated: 2:tog-pegasus-libs-2.12.1-8.fc19.x86_64 Oct 30 08:01:08 Updated: 2:tog-pegasus-2.12.1-8.fc19.x86_64 Oct 30 08:01:39 Updated: 2:tog-pegasus-devel-2.12.1-8.fc19.x86_64
a 'cimprovider -l' does not return any KVM_ modules a sure sign of things not working...
In order to help dig, I enabled debugging:
cimconfig -s traceLevel=4 -c cimconfig -s traceComponents=ALL -c
Looking at the cimserver.trc file I find these (sorry about the formatting my auto line wrap is on):
1384276573s-184895us: Repository [7944:139824043710528:FileBasedStore.cpp:631]: Namespace: root#PG_InterOp ignored -- subdirectories are not correctly formed 1384276573s-186825us: L10N [7944:139824043710528:MessageLoader.cpp:418]: Message ID = Common.InternalException.CANNOT_OPEN_DIRECTORY 1384276573s-187030us: Repository [7944:139824043710528:FileBasedStore.cpp:1347]: Namespace: root#PG_InterOp ignored -- subdirectories are not correctly formed 1384276573s-194463us: ProviderManager [7944:139824043710528:ProviderRegistrationManager.cpp:1934]: nameSpace = root/interop; className = PG_ProviderModule
I think you get the picture though - there's something about PG_InterOp which is different. Since it's one of those things that 2.12.1-8 release notes discusses as changing in 2.12.1-4, I have a feeling whatever it is the libvirt-cim.spec does in order to "link up" as a provider, does not work in the same way any more.
Hi John, after investigating in this problem we have seen that with tog-pegasus version 2.12.1-5 the namespace for base classes was changed from root/PG_Interop to root/interop. tog-pegasus can be build using an option that changes this namespace to one of these 2 namespaces. As far as we could see RedHat is using this option (and the new namespace) in their build of tog-pegasus. The cim providers that should be installed have to use the correct namespace to find the right classes. This would lead to an incompatibility of cim providers AND clients. Therefore the pegasus community does NOT recommend the change to the new namespace until a backwards compatible way is implemented in tog-pegasus. Kind regards, Daniel
Doing a :
wbemcli ein http://root:password@localhost:5988/root/virt:KVM_VirtualSystemManagementSer...
gets:
1384277180s-587013us: ProviderManager [9934:140222156466240:ProviderRegistrationManager.cpp:395]: nameSpace = root/virt; className = KVM_VirtualSystemManagementService; className = root/virtkvm_virtualsystemmanagementserviceinstance 1384277180s-587020us: ProviderManager [9934:140222156466240:ProviderRegistrationManager.cpp:406]: Provider capability has not been registered yet. 1384277180s-587028us: Dispatcher [9934:140222156466240:CIMOperationRequestDispatcher.cpp:1465]: Provider for KVM_VirtualSystemManagementService not found.
But no output from the wbemcli command.
I did try "going backwards" and installing an older rpm, but was not successful. So I borrowed another RHEL6.5 system and am testing over there today.
John
- -- Mit freundlichen Grüßen / Kind regards Daniel Hansel IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShKXAAAoJEJszBMQcau4WLEEP/juXbDAah/EcsHahjBUT5PN6 oNnzVK0PJrbM5JAFszc7gp4N5gyxV50IVIexD8s3pqOvob7BlBYgIRuw3uzW9jcP UxMwsYz4StYPpGws4IjamisIHIeAwt3JfQapGdi5VJ0YJDRfsMacGdQbB8pmYbWT aiNQeQu6lu3i+KEBMbWzp9N210jMQwJJrG55I3VmxlbJsZpbHvTdRXXp4waQqArK sIHZgSRV0WY+pdG6QQuQ/I5lJQVjLuVUXd9wu/rX19Ii9S6U4Gequ+44/TIacsRV dAJEGpCrpuydl+RJn24RXACH5FwrnpKoVsdp23KpY+faq+Z1ICCLAUcpzVvgeUjl YB7I9HTrmvpQ16X6tDzPiNP7sZD03sZgnT5yqat8ZN9tb9Uju8ZVKLJtcSQfZ1LA M1qTwlwFtUSY/qFkBD07s5TLEDPfLucJWrHg5sNOUs1gB9nHW9rv9eUuIwSl114h doWwUhj1TtyfYu/SQFIjm7Y63UYr7i7+g7QlzL/jvKMpI0kUgZfU+m7bhSVFcVm0 DGZ14u2GXOQKam2YnsSb8DiUiOSO0y7qmNCh6bYhEuhxussdB8Ls7xdtN6lKF+Ej hAW3LRIdO3QgAj0vIOswFg9K46+EMvSIJglhah0poG1+xZ13zNxLTM3EOUYWS3Wm vzspVoxGLLagzog0ywy/ =TF+o -----END PGP SIGNATURE-----
On 11/14/2013 05:28 AM, Daniel Hansel wrote:
Hi John,
after investigating in this problem we have seen that with tog-pegasus version 2.12.1-5 the namespace for base classes was changed from root/PG_Interop to root/interop. tog-pegasus can be build using an option that changes this namespace to one of these 2 namespaces. As far as we could see RedHat is using this option (and the new namespace) in their build of tog-pegasus.
The cim providers that should be installed have to use the correct namespace to find the right classes. This would lead to an incompatibility of cim providers AND clients.
Therefore the pegasus community does NOT recommend the change to the new namespace until a backwards compatible way is implemented in tog-pegasus.
Kind regards, Daniel
So just to be sure - if I'm reading this right, tog-pegasus 2.12.1-5 and beyond have broken libvirt-cim? Do the tog-pegasus developers know this? Is there a bug to track? Was there some expectation that libvirt-cim "change" to using root/interop? I guess the hard part for me is that anyone getting the latest updates to f19 will run into this. It doesn't matter for RHEL6 since 6.5 at least since it's only up to 2.12.0-3. Tks, John
On 11/15/2013 01:29 AM, John Ferlan wrote:
On 11/14/2013 05:28 AM, Daniel Hansel wrote:
Hi John,
after investigating in this problem we have seen that with tog-pegasus version 2.12.1-5 the namespace for base classes was changed from root/PG_Interop to root/interop. tog-pegasus can be build using an option that changes this namespace to one of these 2 namespaces. As far as we could see RedHat is using this option (and the new namespace) in their build of tog-pegasus.
The cim providers that should be installed have to use the correct namespace to find the right classes. This would lead to an incompatibility of cim providers AND clients.
Therefore the pegasus community does NOT recommend the change to the new namespace until a backwards compatible way is implemented in tog-pegasus.
Kind regards, Daniel
So just to be sure - if I'm reading this right, tog-pegasus 2.12.1-5 and beyond have broken libvirt-cim?
Do the tog-pegasus developers know this? Is there a bug to track?
Was there some expectation that libvirt-cim "change" to using root/interop? I guess the hard part for me is that anyone getting the latest updates to f19 will run into this. It doesn't matter for RHEL6 since 6.5 at least since it's only up to 2.12.0-3.
Tks,
John
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim
John, looking a bit more at this I found that other provider libraries have been adjusted to the namespace change. I have put Vitezslav Crhonek on cc who provided the changes for the sblim-cmpi libraries. Here is an example (see changelog): http://s390pkgs.fedoraproject.org/koji/buildinfo?buildID=209208 Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
John, looking a bit more at this I found that other provider libraries have been adjusted to the namespace change. I have put Vitezslav Crhonek on cc who provided the changes for the sblim-cmpi libraries. Here is an example (see changelog): http://s390pkgs.fedoraproject.org/koji/buildinfo?buildID=209208
I took a stab at this considering it didn't seem "too difficult" - the main differences being 1. Using "root/interop" instead of "root/PG_InterOp" in provider-register.sh (if the installed cimserver >= 2.12.1) 2. Adjusting libvirt-cim.spec.in similarly with checks for version and dealing the PG_InterOp (although I'm less convinced it makes much of a difference other than perhaps cleaning something up). Anyway, a subsequent run of cimtest was "mostly" successful - I had some issues with FilterList again. It seems the code uses "InstanceID" in order to save the UUID from the filter and in my new environment that doesn't appear to be defined. Whether that's a CIM thing or not I'm still trying to figure out. So before I go digging too deep and taking too long to figure out what's up - does it seem plausible that by just changing from PG_InterOp to interop that we'd have to perhaps adjust the schema? Perhaps create a 'uuid' field? Could perhaps InstanceID be something we cannot write to? (See src/Virt_FilterList.c). Tks, John
On 11/05/2013 04:03 AM, Viktor Mihajlovski wrote:
The following series fixes two issues in the provider registration process of the libvirt-cim RPM package. First, the RPM scriptlets didn't properly reflect the invocation sequence during an RPM upgrade. This is fixed by the first patch. Further, the registration using wildcards (*.mof) failed because of an inter-MOF depedency. Fixed by the second patch. Finally, the class deletion sequence in provider-register.sh was prone to failure, resulting in residual entries in the Pegasus class repository. Addressed by third patch.
Note: since the redhat.com mailing lists are bouncing my emails I am sending from a different account temporarily until this is resolved.
Viktor Mihajlovski (3): build: Fix incorrect provider registration in upgrade path build: Fix provider registration issues schema: Fix class removal with Pegasus
libvirt-cim.spec.in | 282 ++++++++++++++++++++++++++++++++++++++++---------- provider-register.sh | 8 +- 2 files changed, 231 insertions(+), 59 deletions(-)
I've pushed this upstream John
On 11/13/2013 05:54 PM, John Ferlan wrote:
I've pushed this upstream
John
thanks for reviewing (and pushing) all the patches -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
participants (5)
-
Boris Fiuczynski -
Daniel Hansel -
Daniel Hansel -
John Ferlan -
Viktor Mihajlovski