Hi. At this moment, Neutron doesn't offer physical network information for now. There is a proposal for it[1] and it was discussed at the summit [2]. Although it is still early design phase[3][4], using routing protocol will surely help to discover physical network topology.
[1] https://wiki.openstack.org/wiki/Topology-as-a-service [2] https://etherpad.openstack.org/p/hierarchical_network_topology [3] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035868.html [4] https://review.openstack.org/#/c/91275/ thanks, Isaku Yamahata On Fri, May 30, 2014 at 11:11:46AM +0200, Mathieu Rohon <[email protected]> wrote: > I'm also very interested in scheduling VMs with Network requirement. This > seems to be in the scope of NFV workgroup [1]. > For instance, I think that scheduling should take into account bandwith/QoS > requirement for a VM, or specific Nic requirement for a VM (availability of > a SRIOV Vif on compute nodes). > > To do this, it seems that Neutron should report its available capacity (Vif > availability, bandwith availability) for each compute node, and Gantt > should take this reporting into account for scheduling. > > [1]https://etherpad.openstack.org/p/juno-nfv-bof > > > > On Fri, May 30, 2014 at 10:47 AM, jcsf <[email protected]> wrote: > > > Sylvain, > > > > > > > > Thank you for the background ??? I will educate myself on this work. > > > > > > > > Thanks, > > > > John > > > > > > > > > > > > *From:* Sylvain Bauza [mailto:[email protected]] > > *Sent:* Friday, May 30, 2014 11:31 AM > > > > *To:* OpenStack Development Mailing List (not for usage questions) > > *Cc:* jcsf; 'Carl Baldwin'; 'A, Keshava' > > > > *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as > > input any consideration ? > > > > > > > > Le 30/05/2014 10:06, jcsf a écrit : > > > > Carl, > > > > > > > > A new routing protocol is certainly of great interest. Are you working > > with IETF or can you share more here? > > > > > > > > WRT:Nova Schedule - There still are requirements for the Schedule to > > taking into consideration network as a resource. My focus is to figure > > out how to add network capabilities to the Scheduler’s algorithm while > > still maintaining clean separation of concerns between Nova and Neutron. > > We wouldn’t want to get back into the nova-network situation. > > > > > > > > John > > > > > > As it was previously mentioned, there are already different kinds of > > grouping for VMs in Nova that probably don't require to add new > > network-specific features : > > - aggregates and user-facing AZs allow to define a common set of > > capabilities for physical hosts upon which you can boot VMs > > - ServerGroups with Affinity/Anti-Affinity filters allow you to enforce a > > certain level of network proximity for VMs > > > > > > Once that said, there is also another effort of forking the Nova Scheduler > > code into a separate project so that cross-projects scheduling could happen > > (and consequently Neutron could use it). This project is planned to be > > delivered by K release, and will be called Gantt. > > > > > > So, could you please mention which features do you need for Nova, so we > > could discuss that here before issuing a spec ? > > > > -Sylvain > > > > > > > > > > > > > > > > > > > > *From:* Carl Baldwin [mailto:[email protected] <[email protected]>] > > *Sent:* Friday, May 30, 2014 12:05 AM > > *To:* A, Keshava > > *Cc:* [email protected]; Armando M.; OpenStack Development Mailing List > > (not for usage questions); Kyle Mestery > > *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as > > input any consideration ? > > > > > > > > Keshava, > > > > > > > > How much of a problem is routing prefix fragmentation for you? > > Fragmentation causes routing table bloat and may reduce the performance of > > the routing table. It also increases the amount of information traded by > > the routing protocol. Which aspect(s) is (are) affecting you? Can you > > quantify this effect? > > > > > > > > A major motivation for my interest in employing a dynamic routing protocol > > within a datacenter is to enable IP mobility so that I don't need to worry > > about doing things like scheduling instances based on their IP addresses. > > Also, I believe that it can make floating ips more "floaty" so that they > > can cross network boundaries without having to statically configure routers. > > > > > > > > To get this mobility, it seems inevitable to accept the fragmentation in > > the routing prefixes. This level of fragmentation would be contained to a > > well-defined scope, like within a datacenter. Is it your opinion that > > trading off fragmentation for mobility a bad trade-off? Maybe it depends > > on the capabilities of the TOR switches and routers that you have. Maybe > > others can chime in here. > > > > > > > > Carl > > > > > > > > On Wed, May 28, 2014 at 10:11 PM, A, Keshava <[email protected]> wrote: > > > > Hi, > > > > Motivation behind this requirement is “ to achieve VM prefix aggregation > > using routing protocol ( BGP/OSPF)”. > > > > So that prefix advertised from cloud to upstream will be aggregated. > > > > > > > > I do not have idea how the current scheduler is implemented. > > > > But schedule to maintain some kind of the ‘Network to Node mapping to VM” > > .. > > > > Based on that mapping to if any new VM getting hosted to give prefix in > > those Nodes based one input preference. > > > > > > > > It will be great help us from routing side if this is available in the > > infrastructure. > > > > I am available for review/technical discussion/meeting. > > > > > > > > > > > > Thanks & regards, > > > > Keshava.A > > > > > > > > *From:* [email protected] [mailto:[email protected]] > > *Sent:* Thursday, May 29, 2014 9:14 AM > > *To:* [email protected]; Carl Baldwin; Kyle Mestery; > > OpenStack Development Mailing List (not for usage questions) > > *Subject:* Re: [openstack-dev] [neutron][L3] VM Scheduling v/s Network as > > input any consideration ? > > > > > > > > Hi keshava, > > > > > > > > This is an area that I am interested in. I'd be happy to collaborate > > with you on a blueprint. This would require enhancements to the > > scheduler as you suggested. > > > > > > > > There are a number of uses cases for this. > > > > > > > > > > > > ???John. > > > > > > > > Sent from my smartphone. > > > > *From: *A, Keshava??? > > > > *Sent: *Tuesday, May 27, 2014 10:58 AM > > > > *To: *Carl Baldwin; Kyle Mestery; OpenStack Development Mailing List (not > > for usage questions) > > > > *Reply To: *OpenStack Development Mailing List (not for usage questions) > > > > *Subject: *[openstack-dev] [neutron][L3] VM Scheduling v/s Network as > > input any consideration ? > > > > > > > > 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) ? > > > > > > > > > > > > > > > > > > > > Thanks & regards, > > > > Keshava.A > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > OpenStack-dev mailing list > > > > [email protected] > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Isaku Yamahata <[email protected]> _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
