Daniel P. Berrangé writes: >> > >> >> The reason for this timeout is that we originally promised something >> that we cannot deliver - a synchronous device detach API, while the >> operation itself is asynchronous. I'm not a fan of exposing it and >> making it configurable. > > I'm especially *not* a fan because the commit messages says this is > a problem on certain architectures. Since we know what those arches > are, we should use a larger timeout for those arches out of the box. > Requiring admin to set a config param to fix the architectures is > super unpleasant out of the box experiance. True, but also notice that 5 seconds is also already close to the attention span time limit for users [1]. So increasing it to 10s might bring people to believe things are stuck, unless you provide some sort of feedback that this is normal. https://www.nngroup.com/articles/response-times-3-important-limits/ > > > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Cheers, Christophe de Dinechin (IRC c3d) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
