5:03 p.m.
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
5:03 p.m.
New subject: [PATCH 1/3] build: Fix incorrect provider registration in upgrade path
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(a)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
5:03 p.m.
New subject: [PATCH 2/3] build: Fix provider registration issues
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(a)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
5:03 p.m.
New subject: [PATCH 3/3] schema: Fix class removal with Pegasus
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(a)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
4:58 a.m.
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
12:43 a.m.
-----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(a)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-----
1:34 a.m.
>
> 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_VirtualSystemManagement...
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
6:28 p.m.
-----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_VirtualSystemManagement...
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-----
8:29 a.m.
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
8:17 p.m.
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(a)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
6:12 a.m.
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
12:54 a.m.
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
12:59 a.m.
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
3946
days inactive
3959
days old
12 comments
5 participants
participants (5)
-
Boris Fiuczynski -
Daniel Hansel -
Daniel Hansel -
John Ferlan -
Viktor Mihajlovski