[libvirt] [RFC] New domain job control and stat APIs

[Daniel P. Berrangé]

On Thu, Jul 25, 2019 at 01:52:01PM +0200, Pavel Hrdina wrote:
> On Wed, Jul 24, 2019 at 03:43:14PM +0100, Daniel P. Berrangé wrote:
> 
> [...]
> 
> > > +typedef struct _virDomainJob virDomainJob;
> > > +typedef virDomainJob *virDomainJobPtr;
> > > +struct _virDomainJob {
> > > +    char *name;
> > > +    virDomainJobType type;
> > > +    virDomainJobState state;
> > > +
> > > +    /* possibly overkill? - currently empty*/
> > > +    virTypedParameterPtr data;
> > > +    size_t ndata;
> > > +};
> > 
> > I'd have a preference for keeping this as an opaque
> > struct not exposed in the public header, and making
> > it a first class object. So instead have accessors
> > 
> >   char * virDomainJobGetName(virDomainJobPtr job);
> >   virDomainJobType virDOmainJobGetType(virDomainJobPtr job);
> >   virDomainJobState virDOmainJobGetState(virDomainJobPtr job);
> > 
> > which fetch from the local struct. The local struct would
> > also need to contain a reference to the virDomainPtrpass over
> > 
> > This avoids the query you have about virTypedParameterPtr
> > inclusion, as we can ignore it now, and if we get a compelling
> > need, we then just add a remotable method:
> > 
> >    virDomainJobGetStats(virDomainJobPtr job,
> >                         virTypedParameterPtr **params,
> > 			unsigned int *nparams);
> 
> Agreed to make it first class object.  Shouldn't we rename it to
> virJob* as well or do we want to have it tied to domains only?

I guess the obvious use case would be in the storage pool APIs
which already have long running background tasks where this would
be useful.

The difficulty though is that we then need APIs for the job
dispatched to different drivers depending on the instance of
the job. eg one job needs to be processed by QEMU driver
whle the next job needs to be processed by the storage driver.
This could get quite fugly with the way we do API dispatch.
We already have this with the virStream APIs of course, but
I think they are one of the more horrible parts of our internal
framework.

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 :|