Difference between revisions of "Meetings/Neutron blueprint ovs-firewall-driver"
< Meetings
(→Meeting Dec 16, 2013) |
(→Meeting Dec 16, 2013) |
||
Line 14: | Line 14: | ||
*** adding multiple ports in range: debating trying out port bitmask or N flows for N ports? | *** adding multiple ports in range: debating trying out port bitmask or N flows for N ports? | ||
*** TODO unit/integration tests (integration tests help is always appreciated) | *** TODO unit/integration tests (integration tests help is always appreciated) | ||
− | + | * ovs_neutron_agent issues: | |
− | + | ** (1) firewall invoked before agent does anything in C[R]UD operations | |
− | + | *** need to at least extract VLAN provisioning out before firewall invocation (to have correct OVS action on ALLOW path) | |
− | + | ** (2) agent removes all flows at initialization (as well as deletes all vif's flows on port_bound) | |
− | + | *** possibly require OVS 1.5.0+ to delete flows based on cookie | |
− | |||
** lacking ovs atomicity like iptables-restore has (all connections might be dropped/allowed): one possibility is to have a dynamic multi-table hotswap | ** lacking ovs atomicity like iptables-restore has (all connections might be dropped/allowed): one possibility is to have a dynamic multi-table hotswap | ||
** neutron-rootwrap-xen-dom0 bugs: https://bugs.launchpad.net/neutron/+bug/1185872/comments/3, https://bugs.launchpad.net/neutron/+bug/1259748 | ** neutron-rootwrap-xen-dom0 bugs: https://bugs.launchpad.net/neutron/+bug/1185872/comments/3, https://bugs.launchpad.net/neutron/+bug/1259748 | ||
** table, priority, cookie, actions coordination: ok for now to be hard-coded in Neutron, but will need an abstraction layer in the future possibly | ** table, priority, cookie, actions coordination: ok for now to be hard-coded in Neutron, but will need an abstraction layer in the future possibly |
Revision as of 18:37, 14 December 2013
Discussion for <https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver>
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: barely functional
- adding IPv6 flows
- adding multiple ports in range: debating trying out port bitmask or N flows for N ports?
- TODO unit/integration tests (integration tests help is always appreciated)
- ovs_neutron_agent issues:
- (1) firewall invoked before agent does anything in C[R]UD operations
- need to at least extract VLAN provisioning out before firewall invocation (to have correct OVS action on ALLOW path)
- (2) agent removes all flows at initialization (as well as deletes all vif's flows on port_bound)
- possibly require OVS 1.5.0+ to delete flows based on cookie
- lacking ovs atomicity like iptables-restore has (all connections might be dropped/allowed): one possibility is to have a dynamic multi-table hotswap
- neutron-rootwrap-xen-dom0 bugs: https://bugs.launchpad.net/neutron/+bug/1185872/comments/3, https://bugs.launchpad.net/neutron/+bug/1259748
- table, priority, cookie, actions coordination: ok for now to be hard-coded in Neutron, but will need an abstraction layer in the future possibly
- (1) firewall invoked before agent does anything in C[R]UD operations