Open Stack

Zane,
  That would imply that you don't see Heat being used to take actions on
some existing resources.  Is that correct?

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:	Zane Bitter <zbitter at redhat.com>
To:	openstack-dev at lists.openstack.org,
Date:	05/02/2013 03:49 PM
Subject:	Re: [openstack-dev] [Nova][Heat] scheduled-images blueprint



On 01/05/13 22:08, Doug Davis wrote:
> 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  :-)

I think you're misunderstanding what Heat is slightly. It's not a
scripting language, and there are no "if" statements. A Heat template is
a declarative representation of what you'd like your cloud application
to look like, and Heat does the work of transforming that into the
series of API calls to move from the current state to the state declared
in the template.

What you're talking about is a workflow service, not orchestration.
While orchestration _uses_ a workflow of sorts, they're not the same thing.

cheers,
Zane.
>
> 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.


_______________________________________________
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/20130502/05c011f9/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/20130502/05c011f9/attachment.gif>