incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [DISCUSS] Virtual machine's Base Image Updatation Facility
Date Fri, 28 Dec 2012 18:31:12 GMT


> -----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
> 
> 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.
> >
> 
> 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

Mime
View raw message