Open Stack

On May 1, 2013, at 6:50 AM, Steven Hardy <shardy at redhat.com>
 wrote:

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

Hey Steven,

It makes total sense to me to provide a way to snapshot an entire stack.  I would just say there is no reason to push scheduling into Heat.  Lets keep that separate, and have it "snapshot" a stack at a particular time, if that use case makes sense.  It does  seem to me though that there is a difference between using Heat to define what you want a stack to look like at a given point in time, and a workflow that uses the various APIs to accomplish its goal.  There is a proposal up for such a workflow service that can follow complicated logic to make decisions about what to do (https://wiki.openstack.org/wiki/Convection) and it makes a lot of sense to use an eventual service like this to achieve various goals, including both relatively simple snapshots of servers and complicated snapshots of entire stacks.

Gabe

> 
>> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev