DV> The question really is is it a good interface ? In theory it
DV> sounds like it could help us, but I wonder how that actually works
DV> in practice.
In practice, it's almost impossible to write a client that works with
a given provider model (at more than a very basic level) without any
a priori knowledge of the implementation. The intent is for this to
be possible, but it never seems to follow through in the execution of
a client. Some clients are better about it than others, but grow
significantly in complexity because they have to do more discovery of
the model.
My initial feeling is that adding a CIM client to libvirt wouldn't
achieve the desired "silver bullet" effect of providing support for
multiple CIM-enabled platforms, so you'd end up writing different
drivers for each anyway. You would be able to share some common CIM
client code, but not the whole driver.
There are some other potential gotchas here, too. Like, what happens
if the CIM provider returns a job instead of completing an action
right away? Most of the SVPC profiles allow the provider to delay any
action indefinitely by returning a job object for you to monitor.
That doesn't fit very well into the libvirt API semantics, IMHO :)
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com