[openstack-dev] [Nova][Heat] scheduled-images blueprint

Russell Bryant rbryant at redhat.com
Wed May 1 18:46:56 UTC 2013


On 05/01/2013 06:50 AM, Steven Hardy 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.

Cool stuff.  The addition here would be applying a policy to a stack
that says that you want a snapshot done of a stack every so often.

>> Not sure if _everyone_ wants (or should be forced) to use Heat?

Probably not.  Of course, snapshots are already supported.  Now the
question is, what higher level things can we do with that, and where
should they live.  Snapshots of an entire stack would be really
interesting.  Does the periodic aspect live there?  Maybe ... probably
not ... that's what I wanted to talk about, though.

>> It comes down to where we want the seperation of duties. Currently
>> when in doubt put-it-in-nova... Lucky you;)

Yeah.  The way I've been thinking about it is whether it's a compute
primitive that *must* be done by nova, or is it implementation of policy
or orchestration around those primitives.  The latter I'm trying to push
away to be done in external tools.

"I want a snapshot once a day" seems like something that shouldn't touch
nova at all, to me.

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

That's pretty interesting.  That is pretty much taking the scheduling
service as proposed and exposing it as a resource type in Heat.  Makes
good sense ...

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

This is what I had in mind when I initially started the conversation.
Is Heat the right service to be in charge of scheduled tasks?  Or is it
really something that belongs elsewhere completely and is just another
resource type that you can add to your stack?  I'm thinking the latter
is making more sense to me now.

-- 
Russell Bryant



More information about the OpenStack-dev mailing list