On 5/12/22 17:22, Daniel P. Berrangé wrote:
On Thu, May 12, 2022 at 05:17:37PM +0200, Michal Privoznik wrote:
> After seeing previous commit one might think that
> virDomainRestoreParams() would get the similar treatment. Well,
> it can't. The problem here is: without any indication what domain
> to restore we don't really know what domain to restore (shocking,
> right?). Therefore, we have to require path to restore domain
> from, at which point, we can save callers couple of lines and let
> them pass the path as a regular argument instead of requiring it
> in typed params.
Currently for managed save restore, it happens magically
during virDomainCreate.
We don't have a way to pass parameter so that though,
so can parallelize, etc.
We could make a virDomainCreateParams to handle this,
or we could make virDOmainRestore handle this by
adding a 'domain-uuid' parameter as an alternative
to the path.
IOW, it is possibly a good thing for future proofing that
the path is a typed param rather than positional param.
Fair enough. But so far I don't think there's anything that
virDomainRestoreParams() offers that can't be achieved with already
existing APIs. So let me drop this patch and post another one that
merely requires path. And if we ever want this to work as
virDomainCreateParams we can introduce new typed param (to capture that
dom UUID) and just revert my patch.
Michal