7:01 p.m.
On 22/01/12 17:09, Itamar Heim wrote:
On 01/22/2012 09:26 AM, Livnat Peer wrote:
> On 20/01/12 17:21, Itamar Heim wrote:
>> On 01/20/2012 12:01 PM, Livnat Peer wrote:
>>> On 20/01/12 09:35, Ayal Baron wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> Top Posting:
>>>>>
>>>>> From user POV I think that option 2 is the only one that make
>>>>> sense.
>>>>> We try to do as much as we can,
>>>>> and on each "problematic" case, we make him aware and let
him decide.
>>>>>
>>>>
>>>> Yep, +1.
>>>>
>>>
>>> Trying to get to a conclusion here,
>>> 3 different people said on this thread that they think that from the
>>> user perspective leaving the shared devices plugged is what they think
>>> is the best behavior to the user. (Omer, Kolesnik, Yair)
>>>
>>> On the other hand we have 2 people who think that protecting the
>>> user is
>>> more important than leaving the VM configuration as it was in the
>>> original VM (Miki, Ayal).
>>>
>>> Ayal/Miki can you please specify what are we protecting the user from?
>>>
>>>
>>> I think that because we are not snapshotting the shared disk and the
>>> direct LUN they should not be part of the VM configuration (in the
>>> snapshot) at all. we can not promise the user that the disk will be
>>> there and if it is there we can not guarantee it is in the same
>>> state as
>>> it was when we took the snapshot.
>>>
>>>
>>> Another issue,
>>>
>>> I can not see a reason to limit this feature to creating a VM from
>>> snapshot and not a template? Almost no extra work is needed for
>>> supporting templates as well.
>>
>> I assume you meant, creating a VM from another VM (if it is down)?
>> It should be supported.
>
> Actually I meant creating a Template from Snapshot.
>
> What you suggested is creating a VM from VM.
> Although I see how the two are connected, I think they should be modeled
> as two different API calls.
> There is a difference in the flow, behavior, locks and parameters
> between the two.
>
> Behavior:
> - Original VM has to be down for creating a VM from VM, not the case for
> creating a VM from snapshot.
>
> parameters:
> - Creating VM from snapshot should support getting a snapshot-ID,
> Creating VM from VM get a VM id
>
> Locks:
> - When creating a VM from VM, we need to lock the original VM as a
> whole, we can not edit the VM, take snapshot or any other VM level
> action while such operation is active.
> While for creating the VM from snapshot we can take more fine-grained
> locks (only image related locks).
>
> Implementation:
> Well it is simply another implementation.
These would be the "technical details", but from user perspective, I'd
argue cloning a snapshot is just cloning an older version of the VM.
i.e., i may pass to clone_vm an optional parameter to request cloning an
older version (specific snapshot), vs. cloning the latest down or
running VM.
for a running VM, ayal mentioned a possible flow (live snapshot, clone,
live merge).
implementing this doesn't have to be in same phase, but the question is
what is the right level of modeling for the API for the action.
I agree that modeling the API should drive the decision here and not the
implementation.
I argue that because of the different behavior of the two actions we
should model it as two different operations.
If we force the VM to be down and we are locking the VM through out the
operation of cloning VM from VM while we don't have to do the above for
cloning VM from snapshot we should separate the two.
I think there are flaws with the flow Ayal suggested, I'll detailed them
in the context of his reply.