<tt><font size=2>"Armando M." <armamig@gmail.com> wrote
on 05/28/2014 07:35:52 PM:<br>
<br>
> From: "Armando M." <armamig@gmail.com></font></tt>
<br><tt><font size=2>> To: "OpenStack Development Mailing List
(not for usage questions)" <br>
> <openstack-dev@lists.openstack.org>, </font></tt>
<br><tt><font size=2>> Date: 05/28/2014 07:37 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [neutron][L3] VM
Scheduling v/s Network<br>
> as input any consideration ?</font></tt>
<br><tt><font size=2>> <br>
> Hi Keshava,</font></tt>
<br><tt><font size=2>> <br>
> To the best of my knowledge Nova does not have an explicit way to
<br>
> determine VM placements based on network attributes. That said, it
<br>
> does have a general mechanism called host-aggregates [1] that can
be<br>
> leveraged to address what you are looking for. How certain hosts are<br>
> grouped together to match certain network affinity rules is in the
<br>
> hands of the cloud operator and I believe this requires quite a bit
<br>
> of out-of-band management.</font></tt>
<br><tt><font size=2>> <br>
> I recall at one point that there was an effort going on to improve
<br>
> the usability of such a use case (using the port binding extension
<br>
> [2]), but my knowledge is not very current, so I'd need to fall back<br>
> on some other folks listening on the ML to chime in on the latter
topic.</font></tt>
<br><tt><font size=2>> <br>
> Hope this help!</font></tt>
<br><tt><font size=2>> Armando</font></tt>
<br><tt><font size=2>> <br>
> [1] - </font></tt><a href="http://docs.openstack.org/trunk/openstack-ops/content/"><tt><font size=2>http://docs.openstack.org/trunk/openstack-ops/content/</font></tt></a><tt><font size=2><br>
> scaling.html#segregate_cloud</font></tt>
<br><tt><font size=2>> [2] - </font></tt><a href="http://docs.openstack.org/api/openstack-network/2.0/content/"><tt><font size=2>http://docs.openstack.org/api/openstack-network/2.0/content/</font></tt></a><tt><font size=2><br>
> binding_ext_ports.html</font></tt>
<br><tt><font size=2>> <br>
</font></tt>
<br><tt><font size=2>> On 27 May 2014 09:53, A, Keshava <keshava.a@hp.com>
wrote:</font></tt>
<br><tt><font size=2>> Hi,</font></tt>
<br><tt><font size=2>> I have one of the basic question about the Nova
Scheduler in the <br>
> following below scenario.</font></tt>
<br><tt><font size=2>> Whenever a new VM to be hosted is there any consideration
of network<br>
> attributes ? </font></tt>
<br><tt><font size=2>> Example let us say all the VMs with 10.1.x is
under TOR-1, and 20.<br>
> 1.xy are under TOR-2.</font></tt>
<br><tt><font size=2>> A new CN nodes is inserted under TOR-2 and at
same time a new <br>
>  tenant VM needs to be  hosted for 10.1.xa network.</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> Then is it possible to mandate the new VM(10.1.xa)
  to hosted under<br>
> TOR-1 instead of it got scheduled under TOR-2 ( where there CN-23
is<br>
> completely free from resource perspective ) ? </font></tt>
<br><tt><font size=2>> This is required to achieve prefix/route aggregation
and to avoid <br>
> network broadcast (incase if they are scattered across different <br>
> TOR/Switch) ? </font></tt>
<br>
<br><tt><font size=2>The idea of taking cross-service relationships into
account when scheduling has been discussed off-and-on for a while (longer
than I have been involved in OpenStack), but it is not well realized today.
 I brought a proposal (see </font></tt><a href=https://wiki.openstack.org/wiki/Heat/PolicyExtension><tt><font size=2>https://wiki.openstack.org/wiki/Heat/PolicyExtension</font></tt></a><tt><font size=2>)
to the Icehouse summit.  In that model, your use case would be handled
by relationships that limit network hop counts between VMs.  Work
is underway towards this vision, but the vision remains a long way off.
 The current work is called Gantt, it is a preliminary step of factoring
the scheduling out of nova in preparation for sharing and generalization.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>