Jay Gagnon wrote:
This is still pretty rough around the edges but it seems functional
enough that it's worth showing, and I've got a few spots where I could use some
input. Right now it does in fact notice a domain that changes and fires an indication.
The "previous instance" embedded object has it's Name and UUID fields filled
in; I couldn't find any other fields that seemed terribly relevant to fill in.
The places where I could use some advice:
In _lifecycle_indication, the get_typed_instance args are mostly hardcoded. This seems
rather bad, but I'm not quite sure where I should get them. It's not like I have
a reference being passed in to pull that out of.
The entire sys_name_from_xml feels like an abomination, but sscanf falls short and full
xml parsing seems way overkill. Any suggestions on how to make it safer/more sane are
welcome.
In async_ind, I once again use some hardcoded values because I'm not sure where to
get them.
In lifecycle_thread, I use lv_connect because I don't think I have the requisite info
for the preferred method, but AFAIK lv_connect usage is frowned upon now. I also am not
sure what to do here when I get errors. Should I terminate the event loop? Where would I
even return an error message to the client?
_______________________________________________
Libvirt-cim mailing list
Libvirt-cim(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-cim
One thing I think I forgot to mention here (and any rate haven't seen
any comments on) is what I should do when the indication event loop is
doing its thing, it doesn't really know what to do with an error. Say
for example, that it fails at getting the xml description for a domain.
In most providers, I would use cu_statusf and bail, but here I've got
nobody to give my status to and nowhere to bail to, other than what
amounts to an untimely death.
Is there a mechanism for indications reporting errors, beyond
CU_DEBUG'ing "help" and hoping to recover?
--
-Jay