On 08/27/2018 04:29 PM, John Ferlan wrote:
On 08/27/2018 09:29 AM, Michal Prívozník wrote:
> On 08/27/2018 12:57 PM, Yi Wang wrote:
>> When doing some job holding state lock for a long time,
>> we may come across error:
>> "Timed out during operation: cannot acquire state change lock"
>> Well, sometimes it's not a problem and users wanner continue
s/wanner/want to/
or "prefer to"... Perhaps users is too vague - this essentially sets
the "default timeout policy" for everyone. Setting it too short could be
dangerous considering it's impact.
If "a user" wanted or preferred to wait longer than the default job
timeout for a specific command, then we'd need to add some option for
various commands/API's that allowed setting a unique timeout value for a
specific job.
Another thought would be to have an API that allowed changing the
timeout programmatically. Of course there's the admin interface that is
another area to consider altering since you're adjusting a configuration
value like this.
If anything, this is a job for virt-admin. I don't think we need an API
that would live next to virDomainDeviceUpdate() for instance. We don't
have one for max_jobs, nor for lock_manager, ... In fact, I don't think
we have any API to change anything from qemu.conf.
Michal