<html><body>
<p><font size="2" face="sans-serif">I think this conversation is better served by talking about it in a more abstract way rather than talking about the specific operation (e.g. snapshot) itself - and I think the way Russell described it in an earlier note made sense to me.  Nova should contain the primitive operations of compute.  Orchestration around those operations is probably best left to something outside of Nova.  </font><br>
<br>
<font size="2" face="sans-serif">Now, to some people they may not need anything more complex than "cron" to do that orchestration and that's fine.  And we shouldn't, and can't, stop people from doing that. But, when we talk about a more "official" Openstack based solution I think we need to think a bit bigger than "I just need to invoke a single Nova API" and realize that people we're going to have to handle the more complex usecases (meaning things like flows with conditions, etc...).  And I think that's where Heat can solve the problem very nicely.  True, it might be overkill for the one-liner problems, but I think those folks will probably be happy with simple tools like 'cron'.  </font><br>
<br>
<font size="2" face="sans-serif">My concern with trying to put in the solutions for the trivial problems directly into Nova is that I'm not clear on where to draw the line.  Its easy right now to say "single time-based operations go into Nova", but how long will it be before that becomes "two commands", and then "3 commands",  oh heck, just make it a script file so it can appear like one command.  Oh wait, then we can do if-statements!  We've now recreated Heat  :-)</font><br>
<br>
<font size="2" face="sans-serif">So, circling back around, keep Nova, Glance, etc... as the primitive building blocks and let something like Heat be the scripting tool that sits on top.  This then also puts the burden on Heat to make sure its simple enough to use in those trivial usecases (e.g. as easy to use as the script file example I mentioned above) but also powerful enough to handle the complex ones.</font><br>
<font size="2" face="sans-serif"><br>
thanks<br>
-Doug<br>
________________________________________________________<br>
STSM |  Standards Architect  |  IBM Software Group<br>
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com<br>
The more I'm around some people, the more I like my dog.</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF1CDDFFE12088f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Russell Bryant ---05/01/2013 03:54:55 PM---On 05/01/2013 03:04 PM, Adrian Otto wrote: > Like Gabe, I'"><font size="2" color="#424282" face="sans-serif">Russell Bryant ---05/01/2013 03:54:55 PM---On 05/01/2013 03:04 PM, Adrian Otto wrote: > Like Gabe, I'd like to also -1 the idea of packing ever</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From:      </font><font size="1" face="sans-serif">Russell Bryant <rbryant@redhat.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To:        </font><font size="1" face="sans-serif">openstack-dev@lists.openstack.org, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date:      </font><font size="1" face="sans-serif">05/01/2013 03:54 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject:   </font><font size="1" face="sans-serif">Re: [openstack-dev] [Nova][Heat] scheduled-images blueprint</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">On 05/01/2013 03:04 PM, Adrian Otto wrote:<br>
> Like Gabe, I'd like to also -1 the idea of packing everything new into Heat.<br>
<br>
I did not propose putting everything into Heat.  I'm talking about a<br>
very specific feature.  Comments like this are silly and not helpful to<br>
the discussion.<br>
<br>
> 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.<br>
<br>
I disagree.  Snapshots are important to Nova.  Scheduling policy around<br>
snapshots is about how Nova gets used and belongs elsewhere.<br>
<br>
> 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.<br>
<br>
I think if we end up with a more general scheduling mechanism, it will<br>
be a valuable resource type to integrate with Heat.  That was discussed<br>
elsewhere in this thread.<br>
<br>
> The concept in </font></tt><tt><font size="2"><a href="https://wiki.openstack.org/wiki/Convection">https://wiki.openstack.org/wiki/Convection</a></font></tt><tt><font size="2"> 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.<br>
<br>
<br>
-- <br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>