Difference between revisions of "Meetings/Neutron blueprint ovs-firewall-driver"
< Meetings
(→Meeting Dec 16, 2013) |
(→Meeting Dec 16, 2013) |
||
| Line 4: | Line 4: | ||
* Design decisions | * Design decisions | ||
** openvswitch statelessness and security groups frontend API and DB: https://etherpad.openstack.org/p/ovs-firewall-driver-stateless-2 | ** openvswitch statelessness and security groups frontend API and DB: https://etherpad.openstack.org/p/ovs-firewall-driver-stateless-2 | ||
| + | * Overview of prototype | ||
| + | ** all security group flows on integration bridge | ||
| + | ** currently all on table 0, thinking about multi-table setup | ||
| + | ** prototype tested on flat network setup; should work on other network types as-is since the tunnel OVS flows just pass the data to the integration bridge | ||
| + | ** still a WIP: | ||
| + | *** working on adding IPv6 flows | ||
| + | *** working on adding multiple ports in range (try port bitmask or N flows per N ports?) | ||
* Miscellaneous items: | * Miscellaneous items: | ||
** ovs_neutron_agent nuances: | ** ovs_neutron_agent nuances: | ||
*** (1) firewall invoked before agent does anything in C[R]UD operations | *** (1) firewall invoked before agent does anything in C[R]UD operations | ||
| − | *** (2) agent removes all flows at initialization | + | *** (2) agent removes all flows at initialization (as well as deletes all flows on port_bound) |
*** (3) ovs atomicity like iptables-restore has (all connections might be dropped/allowed): one possibility is to have a dynamic multi-table hotswap | *** (3) ovs atomicity like iptables-restore has (all connections might be dropped/allowed): one possibility is to have a dynamic multi-table hotswap | ||
** if extra time, quickly mention: | ** if extra time, quickly mention: | ||
| − | *** | + | *** neutron-rootwrap-xen-dom0 bugs: https://bugs.launchpad.net/neutron/+bug/1185872/comments/3, https://bugs.launchpad.net/neutron/+bug/1259748 |
| − | |||
*** of course, need to add unit/integration tests; if someone wants to help on integration tests, that would be good if that's possible | *** of course, need to add unit/integration tests; if someone wants to help on integration tests, that would be good if that's possible | ||
| − | |||
| − | |||
*** table, priority coordination: ok for now to be hard-coded in Neutron, but will need an abstraction in the future possibly | *** table, priority coordination: ok for now to be hard-coded in Neutron, but will need an abstraction in the future possibly | ||
Revision as of 04:42, 14 December 2013
Meeting Dec 16, 2013
- Purpose restatement
- Design decisions
- openvswitch statelessness and security groups frontend API and DB: https://etherpad.openstack.org/p/ovs-firewall-driver-stateless-2
- Overview of prototype
- all security group flows on integration bridge
- currently all on table 0, thinking about multi-table setup
- prototype tested on flat network setup; should work on other network types as-is since the tunnel OVS flows just pass the data to the integration bridge
- still a WIP:
- working on adding IPv6 flows
- working on adding multiple ports in range (try port bitmask or N flows per N ports?)
- Miscellaneous items:
- ovs_neutron_agent nuances:
- (1) firewall invoked before agent does anything in C[R]UD operations
- (2) agent removes all flows at initialization (as well as deletes all flows on port_bound)
- (3) ovs atomicity like iptables-restore has (all connections might be dropped/allowed): one possibility is to have a dynamic multi-table hotswap
- if extra time, quickly mention:
- neutron-rootwrap-xen-dom0 bugs: https://bugs.launchpad.net/neutron/+bug/1185872/comments/3, https://bugs.launchpad.net/neutron/+bug/1259748
- of course, need to add unit/integration tests; if someone wants to help on integration tests, that would be good if that's possible
- table, priority coordination: ok for now to be hard-coded in Neutron, but will need an abstraction in the future possibly
- ovs_neutron_agent nuances:
