[openstack-dev] [Nova][Heat] scheduled-images blueprint
Russell Bryant
rbryant at redhat.com
Wed May 1 19:46:56 UTC 2013
On 05/01/2013 03:04 PM, Adrian Otto wrote:
> Like Gabe, I'd like to also -1 the idea of packing everything new into Heat.
I did not propose putting everything into Heat. I'm talking about a
very specific feature. Comments like this are silly and not helpful to
the discussion.
> The Snapshot scheduling concern is a feature specific to Nova, and should be handled as such. That's what API extensions are for. If they are demonstrated to be widely used, then they become community extensions, and then finally core. If there are similar solutions requires across projects, they should be moved into Oslo, and when it makes sense, API services should be offered to front-end them.
I disagree. Snapshots are important to Nova. Scheduling policy around
snapshots is about how Nova gets used and belongs elsewhere.
> It would be convenient if we had a generalized scheduling mechanism, but we don't yet. Not even in Heat. For Heat to be successful, we'll need to resist some temptations to creep up scope there. I think this is probably one of those times.
I think if we end up with a more general scheduling mechanism, it will
be a valuable resource type to integrate with Heat. That was discussed
elsewhere in this thread.
> The concept in https://wiki.openstack.org/wiki/Convection expressed as "A persistent job/process (for example an Auto-Scale policy) that remains running until manually terminated" is a component that could be used as the basis for a generalized event scheduler, but it does not yet exist. When that concept materializes, we can collect a few things around Openstack, and consolidate them on a common solution in order to simplify matters overall. This same concept may be used to create an event scheduling API that could be exposed not only to OpenStack projects but to openstack users (along the lines of a Cloud Cron). I see persistent task flows as a reasonable prerequisite for going down that path.
--
Russell Bryant
More information about the OpenStack-dev
mailing list