Open Stack

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; 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
> 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/f233f783/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/f233f783/attachment.png>