<html><body>
<p><tt><font size="2">Being late to the discussion, I will skip most of these points since they have already been discussed, but wanted to capture my intent in the original mailing list discussion from August.</font></tt><br>
<br>
<tt><font size="2">Mark McLoughlin <markmc@redhat.com> wrote on 10/08/2012 02:49:03 AM:<br>
<br>
> From: Mark McLoughlin <markmc@redhat.com></font></tt><br>
<tt><font size="2">> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font></tt><br>
<tt><font size="2">> Date: 10/08/2012 02:51 AM</font></tt><br>
<tt><font size="2">> Subject: [openstack-dev] Bare-metal node scheduling</font></tt><br>
<tt><font size="2">> <br>
> Hi,<br>
> <br>
> I'm reviewing the first of the "general bare-metal provisioning"<br>
> patches:<br>
> <br>
> <a href="https://review.openstack.org/13920">https://review.openstack.org/13920</a><br>
> <br>
> and I'm really very concerned at how invasive this is to the core<br>
> compute scheduling infrastructure.<br>
> <br>
> Basically, we're adding infrastructure so that a virt driver in a single<br>
> compute service can cause the resources of multiple "nodes" to be<br>
> advertised to the scheduler.</font></tt><br>
<br>
<tt><font size="2">Based on the e-mail thread at the time (primarily the team working on bare-metal + Vish and myself), this was the desired behavior: the scheduler schedules to a node and then sends the message to the service with the provision request and the targeted node. The service just provides the communication/control path.</font></tt><br>
<tt><font size="2"><br>
> Making already confusing core infrastructure much more confusing for the<br>
> sake of a single virt driver seems like a bad idea.<br>
> <br>
> What we're doing is allowing the scheduler to choose a compute node<br>
> based on the details of the individual bare-metal nodes available via<br>
> the compute node. However, the compute node is still responsible for<br>
> choosing which bare-metal node to provision.<br>
</font></tt><br>
<tt><font size="2">I didn't review the code in detail, but this is different than what I would expect - the scheduler should pick the bare-metal node to provision and the "proxy" node running the service would be responsible for acting on it. This model would apply when a single service is responsible for providing the control plane to many boxes (in addition to bare-metal, there is vCenter, oVirt, HMC on IBM System p, etc - it could also apply to Cinder with a single service talking to a SAN registering all the pools from it). When compute pooling is in use, a different approach would be needed to advertise resources (e.g. in aggregate 32GB of RAM may be free, but the largest contiguous is 16GB). However, when the systems are in a manual placement mode, the OpenStack scheduler would be ideal.<br>
</font></tt><br>
<font size="2" face="sans-serif">Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Cloud Architect - OpenStack, Emerging Solutions<br>
IBM Systems & Technology Group</font><br>
</body></html>