[openstack-dev] [scheduler] [heat] Policy specifics

Clint Byrum clint at fewbar.com
Fri Sep 27 19:28:45 UTC 2013


Excerpts from Mike Spreitzer's message of 2013-09-27 11:51:20 -0700:
> Clint Byrum <clint at fewbar.com> wrote on 09/27/2013 11:58:16 AM:
> 
> > From: Clint Byrum <clint at fewbar.com>
> > To: openstack-dev <openstack-dev at lists.openstack.org>, 
> > Date: 09/27/2013 12:01 PM
> > Subject: Re: [openstack-dev] [scheduler] [heat] Policy specifics
> > 
> > > - Does this fit within the scope of an existing OpenStack program? 
> Which 
> > > one? Why?
> > 
> > Heat. You want users to use holistic scheduling when it can work for 
> them,
> > so having it just be a tweak to their templates is a win.
> 
> I think this is actually a pretty interesting question.  If we recognize 
> that the heat program has a bigger view (all kinds of orchestration) than 
> today's heat engine (infrastructure orchestration), this can partly help 
> untangle heat/not-heat debate.   Holistic infrastructure scheduling is a 
> form of scheduling, and the nova scheduler group has some interest in it, 
> but it is inherently not limited to nova.  I think it fits best between 
> software orchestration preparation and infrastructure orchestration --- in 
> the middle of the interests of the heat program. I think we may want to 
> recognize that the best flow of processing does not necessarily intersect 
> the interests of a given program in only one contiguous region.
> 

So I think I responded incorrectly. The _program_ is "OpenStack
Orchestration".  The project could call itself heat-something else too,
or could have another name entirely.

They need to be connected in some way, as the user experience should be
congruent whether users use concrete or holistic templating. Also being
able to mix the two would be key to letting users solve problems that
the holistic scheduler cannot yet solve.

This reaches into other programs too. Trove, Savanna, etc., are all trying
to provide the user with a simplified interface to spin up common cluster
types. This would be ideal for expressing and deploying those clusters.



More information about the OpenStack-dev mailing list