Open Stack

Thanks for your feedback. 

No, I do not yet have code for it. Just wanted to get a feeling if such
a feature would get acceptance in the community. 
But if that helps I can sit down and start some prototyping while I'm
preparing a blueprint spec in parallel. 

The main part of the implementation I wanted to do on my own to get more
familiar with the code base and to get more in touch with the community.
But of course advice and feedback of experienced neutron developers is
essential!

So I will proceed like this
- Create a blueprint
- Commit first pieces of code to get early feedback (e.g. ask via the
mailing list or irc)
- Upload a spec (as soon as the repo is available for K)

Does that make sense for you?

Thanks,
Andreas



On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
> I think this sounds reasonable. Do you have code for this already, or
> are you looking for a developer to help implement it?
> 
> 
> On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring
> <scheuran at linux.vnet.ibm.com> wrote:
>         Hi,
>         last week I started discussing an extension to the existing
>         neutron
>         openvswitch agent to support network adapters that are not in
>         promiscuous mode. Now I would like to enhance the round to get
>         feedback
>         from a broader audience via the mailing list.
>         
>         
>         The Problem
>         When driving vlan or flat networking, openvswitch requires an
>         network
>         adapter in promiscuous mode.
>         
>         
>         Why not having promiscuous mode in your adapter?
>         - Admins like to have full control over their environment and
>         which
>         network packets enter the system.
>         - The network adapter just does not have support for it.
>         
>         
>         What to do?
>         Linux net-dev driver offer an interface to manually register
>         additional
>         mac addresses (also called secondary unicast addresses).
>         Exploiting this
>         one can register additional mac addresses to the network
>         adapter. This
>         also works via a well known ip user space tool.
>         
>         `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`
>         
>         
>         What to do in openstack?
>         As neutron is aware of all the mac addresses that are in use
>         it's the
>         perfect candidate for doing the mac registrations. The idea is
>         to modify
>         the neutron openvswitch agent that it does the registration on
>         "port
>         add" and "port remove" via the bridge command.
>         There would be a new optional configuration parameter,
>         something like
>         'non-promisc-mode' that is by default set to false. Only when
>         set to
>         true, macs get manually registered. Otherwise the agent
>         behaves like it
>         does today. So I guess only very little changes to the agent
>         code are
>         required. From my current point of view we do not need any
>         changes to
>         the ml2 plug-in.
>         
>         
>         Blueprint or a bug?
>         I guess it's a blueprint.
>         
>         What's the timeframe?
>         K would be great.
>         
>         
>         
>         I would be thankful for any feedback on this! Feel free to
>         contact me
>         anytime. Thanks in advance!
>         
>         Regards,
>         Andreas
>         
>         (irc: scheuran)
>         
>         
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Kevin Benton
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev