Re: [RFC V8 2/3] libxl domain snapshot API design

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2014-11-12 at 20:07 -0700, Chun Yan Liu wrote:
> > > By "active" here, do you you mean "live" (vs paused)? 
> > Means the domain is started (no matter is running or paused). 
> > vs (libvirt defines a domain but not started). 
> > Here,  I should update this to: 
> > 3). take disk snapshot by qmp command 
> > libxl only handles active domain. 

I think the problem here is that different components in the system use
different terminology for things or even different concepts (e.g. libxl
has no inherent concept of inactive vs active domains, because it only
concerns itself with active domains).

Perhaps a glossary defining these things would help (also see below).

> > > >    libxl_domain_snapshot_delete:  
> > > >        1). check args validation  
> > > >        2). remove memory state file.  
> > > >        3). delete disk snapshot. (for internal disk snapshot, through qmp  
> > > >            command or qemu-img command)  
> > >   
> > > Out of curiosity, why is this necessary?  Is libxl keeping track of  
> > > the snapshots somewhere?  Or qemu?  
> > >   
> > > Or to put it a different way, since the caller knows the filenames,  
> > > why can't the caller just erase the files themselves? 
> >  
> > Ian asks the same question. The only reason I propose an API is: 
> > xl and libvirt can share the code. And in future, when support many other  
> > disk 
> > backend types, there is much repeated code. But as Ian mentioned in 
> > last version, for handling many disk backend types, maybe better placed in 
> > libxlu. Well, if both of you object, I'll remove this API. 

I think the reason we are having these same discussions over again is
that this proposal is focusing on the libxl API (e.g. the details of
what functions exist and what parameters they take) without an
introductory section which provides a broad overview of the
architecture, containing e.g. things like:

      * What the general requirements for domain snapshotting are;
      * What are the constraints which we are operating under; e.g.
        libvirt or xl design requirements
      * What the various components are (and which, possibly multiple,
        entities provide them) and where the various responsibilities
        lie.

I think we've teased a lot of this sort of thing out in past iterations
but without having it written down here I think we are all having
trouble agreeing (or remembering that we've agreed) that the API makes
sense because we all have different ideas about what the higher level
architecture/abstraction should look like.

See for example
http://xenbits.xen.org/people/dvrabel/event-channels-H.pdf or
http://lists.xen.org/archives/html/xen-devel/2014-10/msg03235.html (you
don't necessarily need to go all out on that level of formality, but
they provide some examples of the sorts of higher level design I'm
talking about)

I think it would also help with the glossary question above since it
would help define the terms.

I'm sorry for not observing this sooner.

Ian.