[openstack-dev] [heat] [scheduler] Bringing things together for Icehouse

Keith Bray keith.bray at RACKSPACE.COM
Mon Sep 23 19:22:16 UTC 2013


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.

Kind regards,
-Keith


On 9/23/13 11:22 AM, "Zane Bitter" <zbitter at redhat.com> wrote:

>On 15/09/13 09:19, Mike Spreitzer wrote:
>> But first I must admit that I am still a newbie to OpenStack, and still
>> am missing some important clues.  One thing that mystifies me is this: I
>> see essentially the same thing, which I have generally taken to calling
>> holistic scheduling, discussed in two mostly separate contexts: (1) the
>> (nova) scheduler context, and (2) the ambitions for heat.  What am I
>> missing?
>
>I think what you're missing is that the only person discussing this in
>the context of Heat is you. Beyond exposing the scheduling parameters in
>other APIs to the user, there's nothing here for Heat to do.
>
>So if you take [heat] out of the subject line then it will be discussed
>in only one context, and you will be mystified no longer. Hope that helps
>:)
>
>cheers,
>Zane.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list