[openstack-dev] [Nova][Heat] scheduled-images blueprint
Doug Davis
dug at us.ibm.com
Wed May 1 20:08:25 UTC 2013
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.
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'.
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 :-)
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.
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug at us.ibm.com
The more I'm around some people, the more I like my dog.
From: Russell Bryant <rbryant at redhat.com>
To: openstack-dev at lists.openstack.org,
Date: 05/01/2013 03:54 PM
Subject: Re: [openstack-dev] [Nova][Heat] scheduled-images blueprint
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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/48c9c98a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/48c9c98a/attachment.gif>
More information about the OpenStack-dev
mailing list