Open Stack

On 27/09/13 08:58, Mike Spreitzer wrote:
> I have begun to draft some specifics about the sorts of policies that
> might be added to infrastructure to inform a smart unified placement
> engine.  These are cast as an extension to Heat templates.  See
> https://wiki.openstack.org/wiki/Heat/PolicyExtension.  Comments solicited.

Mike,
These are not the kinds of specifics that are of any help at all in 
figuring out how (or, indeed, whether) to incorporate holistic 
scheduling into OpenStack.

- What would a holistic scheduling service look like? A standalone 
service? Part of heat-engine?
- How will the scheduling service reserve slots for resources in advance 
of them being created? How will those reservations be accounted for and 
billed?
- In the event that slots are reserved but those reservations are not 
taken up, what will happen?
- Once scheduled, how will resources be created in their proper slots as 
part of a Heat template?
- What about when the user calls the APIs directly? (i.e. does their own 
orchestration - either hand-rolled or using their own standalone Heat.)
- How and from where will the scheduling service obtain the utilisation 
data needed to perform the scheduling? What mechanism will segregate 
this information from the end user?
- How will users communicate their scheduling constraints to OpenStack? 
(Through which API and in what form?)
- What value does this provide (over and above non-holistic scheduler 
hints passed in individual API calls) to end users? Public cloud 
operators? Private cloud operators? How might the value be shared 
between users and operators, and how would that be accounted for?
- Does this fit within the scope of an existing OpenStack program? Which 
one? Why?
- What changes are required to existing services to accommodate this 
functionality?

Answer these questions first. *Then* you can talk about symmetric dyadic 
primitive policies as much as you like to anybody who will listen.

cheers,
Zane.