[Libvirt-cim] [PATCH] Fix RASD provider unregistration

[Kaitlin Rupert]

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 at linux.vnet.ibm.com