
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 :|