Open Stack

What about people just wanting a backup solution but not Heat? Having to
use Heat for only doing the snapshotting/backup may be overkill as Agnus
also pointed out.

Heat isn't that easy(Not in Horizon yet) and backups are also important for
people who don't use Heat, it's one of the most important things imo.
Nobody likes to loose data.

Would it be possible to use heat in the background for all instances
without having to use heat templates? So people using horizon to launch
instance will also get automatic backups? If yes I think heat is the right
place.


On Wed, May 1, 2013 at 8:33 PM, Day, Phil <philip.day at hp.com> wrote:

>  +1****
>
> Depending on the OS image being used it may be necessary to shutdown the
> GuestOS before taking the snapshot to get a recoverable image.   That kind
> of logic doesn’t belong in Nova.****
>
> ** **
>
> Phil****
>
> ** **
>
> *From:* Doug Davis [mailto:dug at us.ibm.com]
> *Sent:* 01 May 2013 05:00
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Nova][Heat] scheduled-images blueprint****
>
>  ** **
>
> +1
> I tend to look at this blueprint from a more abstract level and so to me
> this is really just asking for a set of Openstack APIs to be invoked
> automatically.  That really isn't that fundamentally different than what a
> user of Heat will be trying to do - execute a set of Openstack APIs.
>  Whether its to stand-up an application or to perform a backup of a VM, the
> infrastructure to deal with the execution of those APIs shouldn't really
> know or care.  Especially when you consider that these set of operations
> could very well not be trivial in nature (ie. blindly do this, then this,
> then this...) but rather could require some "smarts" to them (e.g.
> conditional execution of certain steps), and at that point the problem
> become much harder than just a cron job of VM.createSnapshot().  I would
> hope that Heat would be able to help with these types of usecases.
>
>   Now, time-based execution instead of just user initiation execution
> might be a twist, but I see no reason why that couldn't be added to Heat if
> its not already there.
>
> thanks
> -Doug
> ________________________________________________________
> STSM |  Standards Architect  |  IBM Software Group
> (919) 254-6905  |  IBM 444-6905  |  dug at us.ibm.com
> The more I'm around some people, the more I like my dog.
>
> [image: Inactive hide details for Russell Bryant ---04/30/2013 05:49:28
> PM---Greetings, The following blueprint was proposed for the ha]Russell
> Bryant ---04/30/2013 05:49:28 PM---Greetings, The following blueprint was
> proposed for the havana series:
>
> From: Russell Bryant <rbryant at redhat.com>
> To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>,
>
> Date: 04/30/2013 05:49 PM
> Subject: [openstack-dev] [Nova][Heat] scheduled-images blueprint****
>  ------------------------------
>
>
>
>
> Greetings,
>
> The following blueprint was proposed for the havana series:
>
>    https://blueprints.launchpad.net/nova/+spec/scheduled-images
>
> Based on the current design, I think the nova part of this needs to be
> deferred.  It does not seem appropriate to add an API extension that
> talks to a service that is not an integrated project, or at least
> incubated.
>
> Beyond that, I'm curious about the choice to implement this as a new
> service.  I definitely agree that this is not something that should be
> implemented inside of Nova.  However, I wonder if it makes sense as a
> feature in Heat.  It seems like an orchestration feature.
>
> Thoughts?
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ****
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/e687bc8e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/e687bc8e/attachment.gif>