[Kimchi-devel] RFC: Domain snapshots (backend)

[Crístian Viana]

On 03-11-2014 12:36, Aline Manera wrote:
>>
>>
>>       Update a domain snapshot
>>
>
> We can postpone it.
> I think the most important operations are: create, delete and revert a 
> snapshot. When we have those 3 operations done we can work on update.

OK.

>>
>>       CHANGE: List the current snapshot in a domain
>>
>
> I'd say to use the API /vms/<name>/snaphosts to provide this information.
> You can do it by a parameter or using a specific API for it: GET 
> /vms/<name>/snaphosts/current

OK. We can use the new API you proposed above or we can add a field 
"current" when listing a snapshot, and then we can find out which one is 
the current one.

I'll stick with your proposal, if there's no problem with it.

>>  1. When creating a snapshot in a running domain, should we try to
>>     minimize the domain's downtime? There's a libvirt flag for that
>>     but it increases the memory dump file size.
>>
>
> As Kimchi can not deal well with paused domains yet, I suggest to use 
> the libvirt flag to avoid this state.
> But of course, we can revert it when we properly support paused state.
>

OK. We could investigate later if the increase in file size is actually 
that big. Otherwise, we can continue creating a live snapshot even when 
we support suspend/resume. That's better from the user's perspective IMO.

>> 1.
>>
>>
>>  2. When deleting a snapshot, should we keep their children or should
>>     we only delete that snapshot? Keep in mind that snapshots follow
>>     a tree-like structure. This feature is already implemented by
>>     libvirt, it makes no difference for us in the implementation
>>     (it's just a different flag), but we need to think if the user
>>     would expect that the snapshot's children will be deleted as well
>>     when deleting one snapshot.
>>
>
> I'd say to only remove the snapshot itself. But we could provide a 
> check box to user select or not to remove all its children
> In that case we need to accept a parameter on DELETE request
>
> DELETE /vms/<name>/snapshots/<snap>  {mode: node|all}
>

OK, using a parameter seems nice.

>> 1.
>>
>>
>>  2. The properties returned by the action "Look up one domain
>>     snapshot" are just the ones I thought it might be useful for now.
>>     A snapshot has more properties than that but I'm not sure if we
>>     should just dump everything.
>>
>
> No. We should provide and expose only the information needed by user 
> otherwise they do not make sense.

OK.

>
>> 1.
>>
>>
>>
>>  2. The property updated by the action "Update a domain snapshot"
>>     (i.e. "name") is the only one I thought it might be relevant.
>>     Other properties can be updated as well if we want to.
>>
>
> I only can think on name as well.

Well, we're postponing the update method for now anyway :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20141103/cc6b2d31/attachment.html>