Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Abhinandan.Prateek@citrix.com
 designates 203.166.19.134 as permitted sender)
From: Abhinandan Prateek <Abhinandan.Prateek@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Fri, 18 Jan 2013 14:17:23 +0530
Subject: Re: [DISCUSS] Virtual machine's Base Image Updatation Facility
Thread-Topic: [DISCUSS] Virtual machine's Base Image Updatation Facility
Thread-Index: Ac31WHLMRED/CawVTj+bJG1xR4/zmw==
Message-ID: <CD1F094B.1D64A%abhinandan.prateek@citrix.com>
In-Reply-To: 
 <6E004C34C1C59E45A35B4338808BC315013014D312C4@SJCPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.5.121010
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


+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=20

On 03/01/13 6:00 AM, "Hari Kannan" <hari.kannan@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.Huang@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:david@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
>>=20
>> On Wed, Dec 26, 2012 at 3:47 PM, Chiradeep Vittal
>> <Chiradeep.Vittal@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.
>> >
>>=20
>> 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