On Mon, Sep 17, 2007 at 08:51:26PM +0100, Daniel P. Berrange wrote:
On Mon, Sep 17, 2007 at 03:35:19PM -0400, Daniel Veillard wrote:
> Expectations will vary according to environments. But 15mn is *way* over
> what I would accept in a distributed system environment. On the other hand
> when ssh resumes the connection fine if I suspend my laptop for 30mn is
> a a feature. That's why I ask for a way to set the timeout, I don't think
> we will be able to find a value which will please everybody.
I'm not in favour of providing a configurable timeout to individual apps using
libvirt because it'll lead to inconsistent behaviour between apps/ ie scenarios
where one libvirt app will continue to work while another will prematurely
fail. It'll also mean that every app using libvirt will have to find a way
to expose this setting to the user.
> I'm not too fond of using an extension to the URI, I think this gets over
> what URI were designed for. Either giving an access to the socket descriptor
> (beware this may generate a future Windows portability problem), or provide
> a specific tuning API (not nice but relatively safe). Since calls are
> synchronous the app may change the Connection timeout before issuing some
> calls like Create or Migrate.
Yep, a timeout isn't really part of an address which is what we're using
URIs for. Exposing new APIs for this to the apps isn't nice because of the
need for all apps to then expose it to the user as i mention above.
Other possibilities are a libvirt client side config file or environment
variables but the latter isn't too nice.
I'd probably go for config file unless people have other ideas.
Well a config file forces the same timeout for the whole duration of the
program and for every connection, I'm not sure it's the right thing to do
in this case.
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/