Open Stack

Excerpts from Keith Bray's message of 2013-09-23 12:22:16 -0700:
> 
> I think this picture is relevant to Heat context:
> https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o
> 0R9U/edit
> 
> 
> As more and more types of compute (containers, VMs, bare metal) and other
> resources (geographically dispersed) become available from the cloud with
> boarder capabilities (e.g. regionally dispersed backups,
> failover/recovery, etc.), the concept of scheduling and optimizing
> resource placement becomes more important, particularly when a customer
> wants to deploy an application that has multiple underlying resource needs
> but doesn't want to know (or care) about specifying the details of those
> resources and their placement.
> 
> I'm not advocating that this does or does not belongs in Heat (in general
> I think Stack resource placement, region, etc., belongs with the template
> author or authoring system, and I think physical resource placement
> belongs with the underlying service, Nova, Trove, etc.), but I appreciate
> Mike including Heat on this. I for one would vote that we consider this
> "in-context" for discussion purposes, regardless of action.  Placement
> coordination across disparate resource services is likely to become a more
> prominent problem, and given Heat has the most holistic view of the
> application topology stack within the cloud, Heat may have something to
> offer in being a piece of the solution.

Just to restate what you and Zane have just said succintly: There is
definitely a need for Heat to be able to communicate to the API's any
placement details that can be communicated. However, Heat should not
actually be "scheduling" anything.