Open Stack

"Armando M." <armamig at gmail.com> wrote on 05/28/2014 07:35:52 PM:

> From: "Armando M." <armamig at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>, 
> Date: 05/28/2014 07:37 PM
> Subject: Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network
> as input any consideration ?
> 
> Hi Keshava,
> 
> To the best of my knowledge Nova does not have an explicit way to 
> determine VM placements based on network attributes. That said, it 
> does have a general mechanism called host-aggregates [1] that can be
> leveraged to address what you are looking for. How certain hosts are
> grouped together to match certain network affinity rules is in the 
> hands of the cloud operator and I believe this requires quite a bit 
> of out-of-band management.
> 
> I recall at one point that there was an effort going on to improve 
> the usability of such a use case (using the port binding extension 
> [2]), but my knowledge is not very current, so I'd need to fall back
> on some other folks listening on the ML to chime in on the latter topic.
> 
> Hope this help!
> Armando
> 
> [1] - http://docs.openstack.org/trunk/openstack-ops/content/
> scaling.html#segregate_cloud
> [2] - http://docs.openstack.org/api/openstack-network/2.0/content/
> binding_ext_ports.html
> 

> On 27 May 2014 09:53, A, Keshava <keshava.a at hp.com> wrote:
> Hi,
> I have one of the basic question about the Nova Scheduler in the 
> following below scenario.
> Whenever a new VM to be hosted is there any consideration of network
> attributes ? 
> Example let us say all the VMs with 10.1.x is under TOR-1, and 20.
> 1.xy are under TOR-2.
> A new CN nodes is inserted under TOR-2 and at same time a new 
>  tenant VM needs to be  hosted for 10.1.xa network.
>  
> Then is it possible to mandate the new VM(10.1.xa)   to hosted under
> TOR-1 instead of it got scheduled under TOR-2 ( where there CN-23 is
> completely free from resource perspective ) ? 
> This is required to achieve prefix/route aggregation and to avoid 
> network broadcast (incase if they are scattered across different 
> TOR/Switch) ? 

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 https://wiki.openstack.org/wiki/Heat/PolicyExtension) 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.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140528/42ef717f/attachment.html>