[PATCH] Fix RASD provider unregistration
# HG changeset patch # User Kaitlin Rupert <karupert@us.ibm.com> # Date 1225926818 28800 # Node ID 6f62d6165aa6f5b60156c2c56c2d72a12a021886 # Parent 16aa18cf5325f5e689c4967d35288d15825fc2be Fix RASD provider unregistration. Since <>_ResourceAllocationSettingData is listed first in the mof, it doesn't get properly unregistered because <>_ProcResourceAllocationSettingData (etc) hasn't been unregistered yet. This patch forces the ResourceAllocationSettingData unregistration to be run twice, which isn't ideal, but ensures the classes are properly cleaned up. Signed-off-by: Kaitlin Rupert <karupert@us.ibm.com> diff -r 16aa18cf5325 -r 6f62d6165aa6 Makefile.am --- a/Makefile.am Wed Nov 05 15:09:49 2008 -0800 +++ b/Makefile.am Wed Nov 05 15:13:38 2008 -0800 @@ -112,6 +112,10 @@ schema/ElementConformsToProfile.registration \ schema/ReferencedProfile.registration +# This definition is needed during provider unregistration +RASD_MOF = schema/ResourceAllocationSettingData.mof +RASD_REG = schema/ResourceAllocationSettingData.registration + pkgdata_DATA = $(MOFS) $(REGS) $(INTEROP_MOFS) $(INTEROP_REGS) pkgdata_SCRIPTS = provider-register.sh @@ -134,6 +138,7 @@ preuninstall: sh provider-register.sh -v -d -t @CIMSERVER@ -n @CIM_VIRT_NS@ -r $(REGS) -m $(MOFS) + sh provider-register.sh -v -d -t @CIMSERVER@ -n @CIM_VIRT_NS@ -r $(RASD_REG) -m $(RASD_MOF) sh provider-register.sh -v -d -t @CIMSERVER@ -n root/interop -r $(INTEROP_REGS) -m $(INTEROP_MOFS) rpm: clean
KR> Since <>_ResourceAllocationSettingData is listed first in the mof, KR> it doesn't get properly unregistered because KR> <>_ProcResourceAllocationSettingData (etc) hasn't been KR> unregistered yet. Is this sfcb or Pegasus-related? KR> +# This definition is needed during provider unregistration KR> +RASD_MOF = schema/ResourceAllocationSettingData.mof KR> +RASD_REG = schema/ResourceAllocationSettingData.registration Perhaps we should call this "REREG_MOF" and "REREG_REG" or some such? We could potentially have this hit us in schema other than the RASDs. In fact, I think we probably should have had an intermediate class in most of our schema, where we have a Virt_Foo and inherit the LXC_, Xen_, KVM_, etc classes from that. If we move to that in the future, we'll have this problem everywhere. Maybe moving the intermediate abstract classes to their own MOF would be better than re-running the deregistration step? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> Since <>_ResourceAllocationSettingData is listed first in the mof, KR> it doesn't get properly unregistered because KR> <>_ProcResourceAllocationSettingData (etc) hasn't been KR> unregistered yet.
Is this sfcb or Pegasus-related?
Pegasus.
KR> +# This definition is needed during provider unregistration KR> +RASD_MOF = schema/ResourceAllocationSettingData.mof KR> +RASD_REG = schema/ResourceAllocationSettingData.registration
Perhaps we should call this "REREG_MOF" and "REREG_REG" or some such? We could potentially have this hit us in schema other than the RASDs.
True.. although, REREG sounds misleading here.. we're no reregistering the MOF. The intention here is to unregister the classes that couldn't be unregistered until their children are unregistered.
In fact, I think we probably should have had an intermediate class in most of our schema, where we have a Virt_Foo and inherit the LXC_, Xen_, KVM_, etc classes from that. If we move to that in the future, we'll have this problem everywhere.
Maybe moving the intermediate abstract classes to their own MOF would be better than re-running the deregistration step?
That's a good idea, although you still have the problem of order. The intermediate abstract class needs to be first in the list (so that is is registered before its subclasses). When you unregister, the subclass MOF need to be in list before the intermediate abstract class MOF. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
KR> That's a good idea, although you still have the problem of order. The KR> intermediate abstract class needs to be first in the list (so that is KR> is registered before its subclasses). It's probably a good idea to unregister the classes in the opposite order anyway, don't you think? That way if you have dependencies that you have to maintain, you can do that in the list. If we modify provider_register.sh to reverse the list if we're doing a de-register, then it should be good, right? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> That's a good idea, although you still have the problem of order. The KR> intermediate abstract class needs to be first in the list (so that is KR> is registered before its subclasses).
It's probably a good idea to unregister the classes in the opposite order anyway, don't you think? That way if you have dependencies that you have to maintain, you can do that in the list. If we modify provider_register.sh to reverse the list if we're doing a de-register, then it should be good, right?
Yeah, that'd work. Good idea =) -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (2)
-
Dan Smith -
Kaitlin Rupert