Open Stack

On 03/05/13 01:34, Doug Davis wrote:
> Zane,
>    That would imply that you don't see Heat being used to take actions
> on some existing resources.  Is that correct?

Yes, pretty much, apart from template updates obviously.

The exception at the moment is Autoscaling, which we built into Heat 
simply because it didn't exist in OpenStack and we needed it. The 
current plan is to give Autoscaling its own API with a different 
endpoint, as a first step toward separating the code bases.

In principle, nobody should be forced to use a template language to set 
up their resources just so they can use other features like Autoscaling 
or, as in this case, scheduled backups.

cheers,
Zane.

>
> 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.
>
> Inactive hide details for Zane Bitter ---05/02/2013 03:49:55 PM---On
> 01/05/13 22:08, Doug Davis wrote: > I think this conversatZane Bitter
> ---05/02/2013 03:49:55 PM---On 01/05/13 22:08, Doug Davis wrote: > I
> think this conversation is better served by talking about i
>
> 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
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>