Open Stack

On Wed, May 01, 2013 at 04:43:34PM +1000, Angus Salkeld wrote:
> On 30/04/13 15:23 -0400, Russell Bryant wrote:
> >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.
> 
> I'll point out some blueprints in a similar realm:
> 
> 1) https://blueprints.launchpad.net/heat/+spec/stack-snapshot
>    This is to snapshot the whole stack which is quite chalanging. But
>    this together with a periodic/workflow service could give you the
>    same functionality.

Yes, as Angus says, this appears to cover some of the same/similar
functionality - I've not yet got into the details on this, but if we can
make it work it should be a pretty cool feature IMO :)

Basic idea is:
- Provide interface which allows a coordinated point-in-time snapshot of
  all Heat stack resources (e.g heat stack-snapshot mystack)
- This would snapshot the Heat template, all resource metadata, all
  instances, attached volumes, and state of any other resources where
  applicable.
- We'd use something similar to our existing Rollback functionality, to
  allow reverting a stack to a previous snapshot

Obviously the challenge here will be providing some way of getting an
"atomic" snapshot when we'll be sending lots of individual API calls to do
the snapshots.  Initially I think this will be impossible, so we can get
the orchestration of non-atomic snapshots working, then consider if e.g the
nova group-scheduling idea could be extended such that you could specify a
co-ordinated snapshot of groups of instances.

> 2) https://blueprints.launchpad.net/heat/+spec/instance-resize-update-stack
>    implement UpdateStack support for the InstanceType property,
>    such that an instance can be resized after it has been launched.
> 3) https://blueprints.launchpad.net/heat/+spec/rolling-updates
>    Roll out changes in topology and/or configuration to a limited
>    percentage of these instances and then wait to see if those initial
>    rollouts produced failures or successes before deploying a larger
>    percentage.

rolling-updates is more to do with phased rollout of new resource
(instance) metadata AFAIK, so probably not that useful in the context of
backups?

There is also https://blueprints.launchpad.net/heat/+spec/volume-snapshots
which I guess could be relevant

> Not sure if _everyone_ wants (or should be forced) to use Heat?
> 
> It comes down to where we want the seperation of duties. Currently
> when in doubt put-it-in-nova... Lucky you;)
> 
> One way to implement this in Heat would be to have a Resource type
> provided by https://github.com/rackspace-titan/qonos/ (or similar)
> that can do the scheduling/snapshotting:
> 
> "my_cool_server" {
>   "Type": "AWS::EC2::Instance",
>   ... bla bla ...
> },
> MyBackups {
>   "Type": "OS::QONOS::TimedServerSnapshot",
>   "Properties": {
>     "Servers": [{"Ref": "my_cool_server"}],
>     "PeriodInHours": 24
>   }
> }
> 
> In the TimedServerSnapshot resource plugin we could send a job to qonos to run the
> snapshot. - Just an idea.

Interesting.  I guess another idea along similar lines is to add a resource
definition to the snapshot features mentioned above, such that you could
let heat (which already has to handle periodic tasks) trigger periodic
snapshots in addition to supporting user-triggered snapshots via the API.

Steve