Open Stack

Russell,

Please try to see why there is a disagreement on the scheduling concern. I'm not trying to start an argument. I'm presenting an alternate viewpoint.

On May 1, 2013, at 12:46 PM, Russell Bryant <rbryant at redhat.com>
 wrote:

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

Specifically, scheduling (of any event) is beyond the scope of what Heat does now. It is contemplated as part of Convection, where most of us agree it should evolve.

The "Cloud Cron" concept is also useful for other problems currently at hand, such as the scheduled scale-up/down of resources that is currently being worked within Heat.

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

We are in violent agreement. What I am saying is that the scheduling capability should start as an API extension for Nova to support the snapshot scheduling feature, and that when a generalized scheduling component is made available (in Oslo, or as an API controlled service) that the extension should be adapted to use that.

I'm even willing to write up a Wiki to describe a proposed scheduler API, and we can iterate on making that a general purpose tool for addressing these sorts of needs. Where that should live is not clear yet, but it could not hurt to continue discussing the utility.

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

Yes, I agree.

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


Thanks,

Adrian