Open Stack

On Mon, Jan 6, 2014 at 7:59 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Tue, Jan 7, 2014 at 7:50 AM, Jon Bernard <jbernard at tuxion.com> wrote:
>>
>> Hello all,
>>
>> I would like to propose instance-level snapshots as a feature for
>> inclusion in Nova.  An initial draft of the more official proposal is
>> here [1], blueprint is here [2].
>>
>> In a nutshell, this feature will take the existing create-image
>> functionality a few steps further by providing the ability to take
>> a snapshot of a running instance that includes all of its attached
>> volumes.  A coordinated snapshot of multiple volumes for backup
>> purposes.  The snapshot operation should occur while the instance is in
>> a paused and quiesced state so that each volume snapshot is both
>> consistent within itself and with respect to its sibling snapshots.
>>
>> I still have some open questions on a few topics:
>>
>> * API changes, two different approaches come to mind:
>>
>>   1. Nova already has a command `createImage` for creating an image of an
>>      existing instance.  This command could be extended to take an
>>      additional parameter `all-volumes` that signals the underlying code
>>      to capture all attached volumes in addition to the root volume.  The
>>      semantic here is important, `createImage` is used to create
>>      a template image stored in Glance for later reuse.  If the primary
>>      intent of this new feature is for backup only, then it may not be
>>      wise to overlap the two operations in this way.  On the other hand,
>>      this approach would introduce the least amount of change to the
>>      existing API, requiring only modification of an existing command
>>      instead of the addition of an entirely new one.
>>
>>   2. If the feature's primary use is for backup purposes, then a new API
>>      call may be a better approach, and leave `createImage` untouched.
>>      This new call could be called `createBackup` and take as a parameter
>>      the name of the instance.  Although it introduces a new member to the
>>      API reference, it would allow this feature to evolve without
>>      introducing regressions in any existing calls.  These two calls could
>>      share code at some point in the future.
>
>
> Note there already is a createBackup/create_backup API call implemented in
> the admin_actions
> extension (in V3 API it is being separated into its own extension
> https://review.openstack.org/#/c/62280/)
> It doesn't do the all volumes snapshot that you want though. There's a small
> window (basically end of icehouse) to make an incompatible change in the V3
> API if that would be the best way to do it.
>
> Chris
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

In general seems reasonable but there are some things that I think
should be considered (comments below).  Also I would point out that if
persistent instances is what folks are looking for there's already
mechanisms in place to do boot from cinder volume which has come a
long way in the past release.

>From Cinder's perspective we've always discouraged using snapshots as
backups, particularly in the case of the LVM driver, snapshots have
some significant performance impacts on the parent volume and having
multiple snaps of a volume sitting around long term isn't such a great
idea.  Much of this problem is eliminated via the use of LVM Thin,
however that's not available on all platforms yet, and there's a
consideration of existing installs that should be considered.  So that
would mean something like your proposal would be snapshot--->backup,
but unfortunately there's a heavy price to pay when you decide to
build the instance and have to go through the restore.

This exact scenario is why folks use things like bootable cinder
volumes as templates.  There are a number of production cases in which
bootable volumes are created as templates, then those templates can be
cloned, booted, and used then thrown away when a user is done with
them.  If they want to spin the environment back up again, simply
clone the volume again and repeat.  This also eliminates the need to
download/build the image every time (granted some backends do
efficient, fast clones better than others).

For the most part we've viewed cinder snapshots as tools to do things
like create backups, clones, migration operations or create-image
without having to take volumes offline for long periods of time.  I
think there are good reasons to continue with this strategy even if
it's not the most popular with some.

I'd like to make sure we look into this a bit before making a quick
submission/change.  Particularly I think we need to consider what our
long term goals/use model is.

Thanks,
John

Thanks,
John