Open Stack

Actually, myself and Soren were talking about this over IRC earlier today.

Soren has a theory that we may not even need respond back to the caller for a "you win" decision to be made. The receiving compute node could just act on it straight away. I think he's correct. If you can't handle the request, don't listen for it. No fanout required.

Remember that this proposal only really works with Flavor-based scheduling and not ad-hoc capability-oriented scheduling.

Which means ... the whole Scheduler concept potentially goes away.
All the Zone stuff and the Cost computation stuff would stay the same, just move location.

The use case that causes problems is the one I mentioned earlier:  "prefer hosts that don't already hold instances for this customer" ... which requires compute nodes to know about each others state.

But I think we can handle this in the following way:
- Modulo the number of Compute nodes by some number X. This is our "stripe" number.
- Keep a per-customer reference to the last "stripe" used (S, an int)
- When requesting a new instance, ask for a Compute node of Stripe (S + 1) % X
- Compute nodes listen for Flavors on their Stripe only

This implies we need # Flavors * # Stripes queues, but queues are lightweight anyway.

Still stewing on the ramifications of all this.

-S



________________________________
From: Vishvananda Ishaya [vishvananda at gmail.com]
Sent: Wednesday, May 25, 2011 3:42 PM
To: Sandy Walsh
Cc: Soren Hansen; openstack at lists.launchpad.net
Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...


On May 25, 2011, at 4:41 AM, Sandy Walsh wrote:


- We'd need to create a per-Flavor FanOut queue. Some Compute nodes would express their interest in handling the request and we'd, somehow, need to decide which one gets the work. Who would decide that? How could they do it without creating a single point of failure?


Mesos has an interesing way of doing this, where there is an external scheduler that receives offers for resources and can choose to take the offers or not.

http://www.cs.brown.edu/courses/csci2950-u/f10/papers/mesos_tech_report.pdf

This would definitely be a radical difference from what we are doing, but perhaps we could provide some sort of webhook where we can pass sanitized offers back to clients and they can decide whether to take them or not.

Vish




Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse at rackspace.com, and delete the original message. 
Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110525/70e9b845/attachment.html>