first off, thanks for the patch!
if you haven't already, please send a signed CLA[1] to
off...@proxmox.com, and include a "Signed-Off-By" tag in your
commits/patches!
On Mon, Mar 12, 2018 at 04:06:47PM +0200, Lauri Tirkkonen wrote:
> busy pools can easily take more than 5 seconds for eg. zfs create
> ---
> PVE/Storage/ZFSPoolPlugin.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/PVE/Storage/ZFSPoolPlugin.pm b/PVE/Storage/ZFSPoolPlugin.pm
> index e864a58..7ba035f 100644
> --- a/PVE/Storage/ZFSPoolPlugin.pm
> +++ b/PVE/Storage/ZFSPoolPlugin.pm
> @@ -167,7 +167,7 @@ sub path {
> sub zfs_request {
> my ($class, $scfg, $timeout, $method, @params) = @_;
>
> - my $default_timeout = PVE::RPCEnvironment->is_worker() ? 60*60 : 5;
> + my $default_timeout = PVE::RPCEnvironment->is_worker() ? 60*60 : 30;
unfortunately, this is not the way to solve this. our API has a timeout
per request, so things that (can) take a long time should run in a
worker (the API then returns the ID of the task, which can be queried
over the API to retrieve status and/or output).
one long-standing issue in this areas is actually listing content of
storages, which can take quite a while with some storage technologies
(e.g. Ceph, ZFS, ..). there were some ideas on how to solve this
(add an async flag to the involved API calls that allows to opt-into the
worker behaviour and cache the content client side in our web
interface), but no implementation so far.
maybe a similar approach can be taken for allocating and freeing images
(of course without the caching ;))?
guest create/restore/migrate already all run inside workers, so this
issue should not trigger there..
@Thomas, Dominik:
I am not sure what would need to be done to accomodate such an async
flag for API2::Storage::Content POST and DELETES? the CLI side is
trivial since workers run sync there anyway..
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
