On 02/01/2012 02:16 PM, Miki Kenneth wrote:
----- Original Message -----
From: "Ayal Baron"<[email protected]>
To: "Itamar Heim"<[email protected]>
Cc: "Miki Kenneth"<[email protected]>, [email protected]
Sent: Wednesday, February 1, 2012 12:26:12 PM
Subject: Re: [Engine-devel] ovirt core MOM
----- Original Message -----
----- Original Message -----
From: "Ayal Baron"<[email protected]>
To: "Itamar Heim"<[email protected]>
Cc: "Miki Kenneth"<[email protected]>, [email protected]
Sent: Wednesday, February 1, 2012 11:41:43 AM
Subject: Re: [Engine-devel] ovirt core MOM
----- Original Message -----
On 01/23/2012 11:01 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Ayal Baron"<[email protected]>
To: "Itamar Heim"<[email protected]>
Cc: [email protected], "Miki
Kenneth"<[email protected]>
Sent: Sunday, January 22, 2012 11:19:03 AM
Subject: Re: [Engine-devel] ovirt core MOM
----- Original Message -----
On 01/20/2012 11:42 PM, Miki Kenneth wrote:
----- Original Message -----
From: "Itamar Heim"<[email protected]>
To: "Ayal Baron"<[email protected]>
Cc: [email protected]
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.
Not sure I understand how you do that while vms are still
running
on
the original template?
They either:
1. wouldn't be (if changes are in place)
2. if we support template over template (from snapshot) then
no
issue at all.
Once all VMs stop running on previous template we can
live
merge the 2.
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
Not sure how this will work and what use case it serves?
number 1: changing the template for stateless pools.
number 2: for anything you want including template
versioning.
Template versioning should have 2 flavours:
1. my golden image is outdated and I would like to
decommission
it
and replace with a new one created from scratch (i.e. same
name,
new VMs would be derived from new template, no data dedup).
2. my golden image is outdated and I would like to update it
internally - create a VM from it, make the changes, seal this
VM
as the new version of the template (not using the process we
have
today which copies all the data, just change it to be
immutable).
The latter requires supporting trees.
use case wise, #1 is easier, and covers both use cases - it
only
varies
in amount of IO/Space, so when someone tackles this
implementation
wise,
I'd vote for doing #1 first.
No, it varies in amount of time and complexity for user.
It might also be quite complex to create the same image again.
To this I can only say 'provisioning provisioning provisioning'.
The point is to make the user's life easier and making
provisioning
a
breeze, forcing #1 is going in the opposite direction.
#2 does not solve #1.
#2 allows doing part of #1 in a more efficient way.
so there is no reason to not do #1.
(there is also no reason to not do #2)
I agree, that is why I said template versioning should have both.
Decision?
decision about what? this is a theoretical discussion until someone will
actively work on the template versioning feature.
both modes should be supported. which one first would probably depend on
the priorities of the one sending the patches.
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
