[Engine-devel] ovirt core MOM
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. - We add a shared logic for multiple actions of cloning a disk. Clone VM from Snapshot: - Shared disk and direct LUN are open issues, Yair will start a discussion on this upstream. - The suggestion was to mark direct LUN and shared disk as unplugged disks when taking a snapshot. - We had no time to discuss setup networks and stable device addressed, we'll discuss this on the next meeting. Thanks, Livnat
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?
----- 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?).
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@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. _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 01/20/2012 11:42 PM, Miki Kenneth wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Ayal Baron"<abaron@redhat.com> Cc: engine-devel@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...)
----- Original Message -----
On 01/20/2012 11:42 PM, Miki Kenneth wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Ayal Baron"<abaron@redhat.com> Cc: engine-devel@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).
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org, "Miki Kenneth" <mkenneth@redhat.com> 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"<iheim@redhat.com> To: "Ayal Baron"<abaron@redhat.com> Cc: engine-devel@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. Not sure I understand how you do that while vms are still running on the original 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 Not sure how this will work and what use case it serves?
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).
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org, "Miki Kenneth" <mkenneth@redhat.com> 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"<iheim@redhat.com> To: "Ayal Baron"<abaron@redhat.com> Cc: engine-devel@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. Not sure I understand how you do that while vms are still running on
----- Original Message ----- 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.
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).
On 01/23/2012 11:01 PM, Ayal Baron wrote:
----- Original Message -----
From: "Ayal Baron"<abaron@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: engine-devel@ovirt.org, "Miki Kenneth"<mkenneth@redhat.com> 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"<iheim@redhat.com> To: "Ayal Baron"<abaron@redhat.com> Cc: engine-devel@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. Not sure I understand how you do that while vms are still running on
----- Original Message ----- 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.
----- Original Message -----
On 01/23/2012 11:01 PM, Ayal Baron wrote:
----- Original Message -----
From: "Ayal Baron"<abaron@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: engine-devel@ovirt.org, "Miki Kenneth"<mkenneth@redhat.com> 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"<iheim@redhat.com> > To: "Ayal Baron"<abaron@redhat.com> > Cc: engine-devel@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. Not sure I understand how you do that while vms are still running on
----- Original Message ----- 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.
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Miki Kenneth" <mkenneth@redhat.com>, engine-devel@ovirt.org 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 -----
From: "Ayal Baron"<abaron@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: engine-devel@ovirt.org, "Miki Kenneth"<mkenneth@redhat.com> 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"<iheim@redhat.com> >> To: "Ayal Baron"<abaron@redhat.com> >> Cc: engine-devel@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. Not sure I understand how you do that while vms are still running on
----- Original Message ----- 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)
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Miki Kenneth" <mkenneth@redhat.com>, engine-devel@ovirt.org 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 -----
From: "Ayal Baron"<abaron@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: engine-devel@ovirt.org, "Miki Kenneth"<mkenneth@redhat.com> 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"<iheim@redhat.com> >>> To: "Ayal Baron"<abaron@redhat.com> >>> Cc: engine-devel@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. Not sure I understand how you do that while vms are still running on
----- Original Message ----- 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.
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Miki Kenneth" <mkenneth@redhat.com>, engine-devel@ovirt.org Sent: Wednesday, February 1, 2012 12:26:12 PM Subject: Re: [Engine-devel] ovirt core MOM
----- Original Message -----
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Miki Kenneth" <mkenneth@redhat.com>, engine-devel@ovirt.org 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"<abaron@redhat.com> > To: "Itamar Heim"<iheim@redhat.com> > Cc: engine-devel@ovirt.org, "Miki > Kenneth"<mkenneth@redhat.com> > 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"<iheim@redhat.com> >>>> To: "Ayal Baron"<abaron@redhat.com> >>>> Cc: engine-devel@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. 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?
On 02/01/2012 02:16 PM, Miki Kenneth wrote:
----- Original Message -----
From: "Ayal Baron"<abaron@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: "Miki Kenneth"<mkenneth@redhat.com>, engine-devel@ovirt.org Sent: Wednesday, February 1, 2012 12:26:12 PM Subject: Re: [Engine-devel] ovirt core MOM
----- Original Message -----
----- Original Message -----
From: "Ayal Baron"<abaron@redhat.com> To: "Itamar Heim"<iheim@redhat.com> Cc: "Miki Kenneth"<mkenneth@redhat.com>, engine-devel@ovirt.org 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"<abaron@redhat.com> >> To: "Itamar Heim"<iheim@redhat.com> >> Cc: engine-devel@ovirt.org, "Miki >> Kenneth"<mkenneth@redhat.com> >> 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"<iheim@redhat.com> >>>>> To: "Ayal Baron"<abaron@redhat.com> >>>>> Cc: engine-devel@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. > 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.
participants (4)
-
Ayal Baron -
Itamar Heim -
Livnat Peer -
Miki Kenneth