<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Mark,
<div><br>
<div>
<div>On May 2, 2013, at 8:20 AM, Mark Washenberger <<a href="mailto:mark.washenberger@markwash.net">mark.washenberger@markwash.net</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div class="im"><br>
> This is a workflow (not orchestration) feature and would be solidly in-scope for a WFaaS API (e.g. the proposed
<a href="https://wiki.openstack.org/wiki/Convection" target="_blank">https://wiki.openstack.org/wiki/Convection</a> mentioned several times in this thread) in the form of a much more generic "cloud cron" type feature.<br>
</div>
</blockquote>
<div><br>
</div>
<div style="">Tangentially related, but I just want to get out ahead of the usage of "cron" to describe this type of feature. I think its a bit of a hazard to expose a cron-like interface for clouds, because cron gives the job submitter too much control over
the scheduling of their action. This results in problems where a majority of users just pick the default time, or midnight, or 4 AM, which causes strange load spikes in the underlying system.</div>
<div style=""><br>
</div>
<div style="">A better alternative is to express a frequency for the action only, (say 1/day, 1/week, 1/hour, whatever). You can still implement this interface as a cron-like schedule under the covers. But now schedules can be initially randomized, and a cloud
administrator can take action if needed to redistribute load.</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div>I agree completely. It's obvious that there's enough interest in this subject to splinter it off into a separate thread, and start designing something that works as a general purpose scheduling tool/resource/service. We have experience with the pitfalls
of hosting a very large scale cron system, and understand very well about the situation you've described.</div>
<div><br>
</div>
<div>Here is the new thread with a link to a wiki describing a possible Event Scheduling service:</div>
<div><br>
</div>
<div><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/008510.html">http://lists.openstack.org/pipermail/openstack-dev/2013-May/008510.html</a></div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Adrian</div>
</body>
</html>