Re: [libvirt] RFC: Add a 'reason' argument for domain events ?
On Fri, Nov 14, 2008 at 07:28:09AM -0500, Ben Guthro wrote:
To revisit the DEFINED, UNDEFINED topic - I have been giving this
some thought,
and it seems like it is redundant information to me.
Doesn't the existence of a config file define the difference between a transient
and a persistent domain?
Therefore this could be tracked solely with the enum values we have?
If a transient domain becomes persistent via adding a config file, the ADDED
event would be emitted, denoting a config file came into being, and by definition
changing this domain from transient, to persistent.
I'm not sure I understand the need for these events.
I see what you mean - if you have tracked a VM through its entire lifecycle
you can actually determine whether it was persistent or transient. The missing
piece is when you populate your initial list of domains at startup, by calling
virConnectListDomainIDs, you don't know which of those initial set of domains
is persistent. We can better solve that though by providing an explict API call
virDomainIsPersistent(virDomainPtr);
So, yes the extra events I suggested for this are redundant.
Moving on to the shutdown reason discussion -
I can certainly see the need to know why a domain stopped.
That said - would it not be more consistent with the API to introduce an
event "sub-type" enum to be passed alongside of the event-type, passed as
a second integer?
This would reduce the size of the wire protocol, not needing to pass the
full character string, as well.
This would trivially allow us finer grained notifications within a
particular event.
A downside is that it may become a bit noisy for clients who may not be
interested in all of the sub-events.
Perhaps we should add some sort of filtering mechanism?
Adding sub-events isn't really making it more chatty, just providing more
detail to existing set of events. I gues you could optimize to let people
only listen for specific sub-types, but I reckon that domain shutdown
events are not frequent enough to justify this extra complexity.
I'll have a go a making this adjustment...
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|