Open Stack

Le 30/05/2014 11:11, Mathieu Rohon a écrit :
> 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
>
>

I don't have a clear picture yet on all the stakeholders, but the goal
of Gantt is to deal with heterogenous resources like Nova compute nodes
or others.
At the moment, the idea is to paint a clear line in between Nova and the
scheduler, so we are defining an interface (update_resource_stats) that
anyone could call.
In other words, mid-term it would not be mandatory to report the stats
to compute nodes for updating Gantt resources, Neutron could directly
update the resources thanks to Gantt API.

-Sylvain

>
> On Fri, May 30, 2014 at 10:47 AM, jcsf <jcsf31459 at gmail.com
> <mailto:jcsf31459 at gmail.com>> wrote:
>
>     Sylvain,
>
>      
>
>     Thank you for the background – I will educate myself on this work.
>
>      
>
>     Thanks,
>
>     John
>
>      
>
>      
>
>     *From:*Sylvain Bauza [mailto:sbauza at redhat.com
>     <mailto:sbauza at redhat.com>]
>     *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:carl at ecbaldwin.net]
>     *Sent:* Friday, May 30, 2014 12:05 AM
>     *To:* A, Keshava
>     *Cc:* jcsf31459 at gmail.com <mailto:jcsf31459 at gmail.com>; 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 <keshava.a at hp.com
>     <mailto:keshava.a at hp.com>> 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:* jcsf31459 at gmail.com <mailto:jcsf31459 at gmail.com>
>     [mailto:jcsf31459 at gmail.com <mailto:jcsf31459 at gmail.com>]
>     *Sent:* Thursday, May 29, 2014 9:14 AM
>     *To:* openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>; 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
>
>     OpenStack-dev at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>      
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/a30387c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30014 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140530/a30387c0/attachment.png>