On Tue, Oct 13, 2015 at 01:13:04PM +0200, Michal Privoznik wrote:
So I came across this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1156194
There's a request for us to automatically sync guest time on domain
resume (e.g. bare virDomainResume(), or virDomainRestore() or after
migration). I'd like to explore our options here and what would be
acceptable upstream. I can think of two possibilities:
1) Invent new flag to all APIs in question and let mgmt applications
call it. If the flag is set we would sync the guest time too. However,
this masks two different operations under single API. What should be
reported if resuming succeeded but syncing time did not? Success or
failure? Mgmt applications will end up calling two APIs to distinguish
error states anyway.
2) Do this as best effort. Unconditionally, whenever guest agent is
available just issue the time sync command (possibly without waiting for
reply). This, however, takes away control from users - they will no
longer have possibility to just resume domain without time sync.
There's of course the obvious solution - not change anything and have
mgmt apps calling two separate APIs - like they oughtta be doing today.
That's the right solution IMHO
What's your view?
I see no compelling reason to add anything to the API or implementation.
We provide enough functionality already to deal with this scenario. Trying
to overload multiple operations into a single API "for convenience" ends
up not being convenient at all, due to the error reporting scenarios you
mention. I don't see any real burden on applications to call these
existing APIs when they wish to.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|