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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
