+1 (binding) to start implementation. I see that all the changes have been incorporated in the FS https://cwiki.apache.org/CLOUDSTACK/base-image-updation-facility.html.
-abhi On 03/01/13 6:00 AM, "Hari Kannan" <hari.kan...@citrix.com> wrote: >I wish to restate this a bit differently - > >The orchestration being requested here is: >* (possibly) stop vm >* disconnect root disk >* destroy root disk >* create a new disk from (possibly new) template >* attach new disk as root disk to the vm >* (possibly) start vm. > >This is something we support for system vms already. >The existing api is restoreVm(vm_id) >The changed api is restoreVm(vm_id, new_template_id) > >In addition, I wish to add the following - > >A third parameter (a flag) can be specified whether to restart or not (or >we can assume always start after stop). i.e. have a method that resets a >VM on reboot. The use cases for this are: >- Secure environments that need a fresh start on every boot >- Desktops that should not retain state > >Hari Kannan > > >-----Original Message----- >From: Alex Huang [mailto:alex.hu...@citrix.com] >Sent: Friday, December 28, 2012 10:31 AM >To: cloudstack-dev@incubator.apache.org >Subject: RE: [DISCUSS] Virtual machine's Base Image Updatation Facility > > > >> -----Original Message----- >> From: David Nalley [mailto:da...@gnsa.us] >> Sent: Thursday, December 27, 2012 7:40 AM >> To: cloudstack-dev@incubator.apache.org >> Subject: Re: [DISCUSS] Virtual machine's Base Image Updatation >> Facility >> >> On Wed, Dec 26, 2012 at 3:47 PM, Chiradeep Vittal >> <chiradeep.vit...@citrix.com> wrote: >> > Templates should be immutable --if there is a new version created, >> > then it is another template. >> > The api should just take a reference to the new template and not try >> > to deal with trickiness around updating templates. That workflow >> > (versioning >> > templates) is a different ball of wax entirely. >> > >> >> Agreed. >> Templates should be immutable. >> Additionally - the sysadmin side of me doesn't understand why I'd want >> to do this at all. The template exists to get me to JEOS running - not >> to manage updates. I (should) have tools that handle keeping all of my >> deployed VMs in a consistent state, and updated to the proper version. >> Trying to turn CloudStack into a patch management/package management >> service seems a bit too much scope creep IMO. > >I would modify that just a little bit. Deployed templates are immutable. > So if someone updates a template, only new VMs are deployed with the >update. Original VMs are still based off the original. I see a ton of >problems if we try to rebase the VMs to the new template. To take care >of the corruption case (corruption of the base on the primary storage), >you can rebase but it's to the exact copy of the original template so >that shouldn't be a problem. > >I think this feature can only be used for operators who deployed links to >the templates and don't want to keep updating links when they update >templates, which makes sense. But it can be done with the following >small change. > >Feature implementation >- Provide an externally created unique id on vm template. >- Allow access to templates based on externally created ids. >NOTE: In the end that this really means is the uuid column can actually >be set by the caller as long as it's unique. > >For the operator >- someone creates the template with an externally created unique id. >- All references to that template is with the externally created unique >id. So if they put the link to that template on a page, it has to be >with their ids. >- When a template should be updated, just delete the old one and create a >new one with the same externally created id. > >Is there any other use case requirements? > >--Alex
