10:01 a.m.
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 :-)