[neutron] Multi-segment per host support for routed networks

Slawomir Kaplonski skaplons at redhat.com
Wed Feb 13 22:07:51 UTC 2019


Hi,

> Wiadomość napisana przez David G. Bingham <dbingham at godaddy.com> w dniu 01.02.2019, o godz. 19:16:
> 
> Neutron land,
> 
> Problem:
> Neutron currently only allows a single network segment per host. This
> becomes a problem when networking teams want to limit the number of IPs it
> supports on a segment. This means that at times the number of IPs available to
> the host is the limiting factor for the number of instances we can deploy on a
> host. Ref: https://bugs.launchpad.net/neutron/+bug/1764738
> 
> Ongoing Work:
> We are excited in our work add "multi-segment support for routed networks".
> We currently have a proof of concept here https://review.openstack.org/#/c/623115
> that for routed networks effectively:
> * Removes validation preventing multiple segments.
> * Injects segment_id into fixed IP records.
> * Uses the segment_id when creating a bridge (rather than network_id).
> In effect, it gives each segment its own bridge.
> 
> It works pretty well for new networks and deployments. For existing
> routed networks, however, it breaks networking. Please use *caution* if you
> decide to try it.
> 
> TODOs:
> Things TODO before this before it is fully baked:
> * Need to add code to handle ensuring bridges are also updated/deleted using
>  the segment_id (rather than network_id).
> * Need to add something (a feature flag?) that prevents this from breaking
>  routed networks when a cloud admin updates to master and is configured for
>  routed networks.
> * Need to create checker and upgrade migration code that will convert existing
>  bridges from network_id based to segment_id based (ideally live or with
>  little network traffic downtime). Once converted, the feature flag could
>  enable the feature and start using the new code.
> 
> Need:
> 1. How does one go about adding a migration tool? Maybe some examples?

I’m not sure if this can be similar but I know that networking-ovn project has some migration tool to migrate from ml2/ovs to ml2/ovn solution. Maybe this can be somehow helpful for You.

> 2. Will nova need to be notified/upgraded to have bridge related files updated?

Probably someone from Nova team should answer to that. Maybe Sean Mooney would be good person to ask?

> 3. Is there a way to migrate without (or minimal) downtime?
> 4. How to repeatably test this migration code? Grenade?

Again, check how networking-ovn did it, maybe You will be able to do something similar :)

> 
> Looking for any ideas that can keep this moving :)
> 
> Thanks a ton,
> 
> David Bingham (wwriverrat on irc)
> Kris Lindgren (klindgren on irc)
> Cloud Engineers at GoDaddy
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat




More information about the openstack-discuss mailing list