10:19 p.m.
----- Original Message -----
On 01/20/2012 11:42 PM, Miki Kenneth wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim"<iheim(a)redhat.com>
>> To: "Ayal Baron"<abaron(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Friday, January 20, 2012 2:12:27 AM
>> Subject: Re: [Engine-devel] ovirt core MOM
>>
>> On 01/19/2012 11:58 AM, Ayal Baron wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> On 01/18/2012 05:53 PM, Livnat Peer wrote:
>>>>> Hi All,
>>>>>
>>>>> This is what we've discussed in the meeting today:
>>>>>
>>>>> Multiple storage domain:
>>>>> - Should have a single generic verb for removing a disk.
>>>>> - We block removing the last template disk - template is
>>>>> immutable.
>>>>
>>>> but it will be deleted when deleting the template, right?
>>>
>>> Of course.
>>> The point is that the template is an immutable object and should
>>> not change (until we support editing a template at which point
>>> the
>>> user would have to change the template to edit mode before being
>>> able to make such changes and maybe also be able to run it and
>>> make changes internally?).
>>
>> When i hear "edit a template" i don't expect replacing the files.
>> I expect a new edition of disks appearing as a new version of the
>> template. but they don't have to derive from same original
>> template.
>> say i want to create a "Fedora 16 template", then update it every
>> month
>> with latest "yum update".
>> it doesn't matter if i use a VM from same template or just create
>> a
>> new one.
>> then specify it is V2 of the "Fedora 16 template".
>> when someone creates a VM from this template, default version
>> would
>> be
>> latest (but we can let them choose specific older versions as
>> well)
> +1. Nicely put.
> And just to add another common use case is the pool usage.
> When we creating stateless VM pool from the template,
> it would be nice to be able to update the template to V2,
> and have all the newly created VMs dynamically based to the new
> template.
that is indeed where i was going with it as well, but not as trivial,
since need to wait for VMs to stop and return to pool and create new
ones and remove old ones.
also, creating new ones may involve an admin action of first boot +
take
of first snapshot
(hence i stopped the previous description before this part, but since
you opened the door...)
Yes, but this all goes to template versioning (which is great and we need).
For the user though, creating a new template version like you described would be a long
and wasteful process, and is not what I'm talking about.
Unless we support nested templates (second template would be a snapshot over the first
one), then we're likely to require way too much space and creation process would be
too slow (having to copy over all the bits).
I think the pool example is an excellent example where I would not want to have 2 copies
of the template where the only difference between them is a set of security patches
I've applied to the new template.
So the 2 options are for what I'm suggesting are:
1. decommission the old template by making in place changes
2. support template snapshots
Again, need to put the emphasis on fast provisioning of templates and VMs.
Applying updates to a pool should be a breeze (e.g. an automatic monthly process that
unseals the template, updates it and reseals it).