Difference between revisions of "NovaNetNeutronParity"
(→Network Manager Types) |
|||
| Line 39: | Line 39: | ||
(would this work for FlatDHCPNetworkManager as well?) | (would this work for FlatDHCPNetworkManager as well?) | ||
| − | |||
=== Multi-Host === | === Multi-Host === | ||
* [https://etherpad.openstack.org/p/Distributed-Virtual-Router Icehouse summit Distributed Router] (possible multi-host approach) | * [https://etherpad.openstack.org/p/Distributed-Virtual-Router Icehouse summit Distributed Router] (possible multi-host approach) | ||
Revision as of 20:31, 9 December 2013
Contents
Making Parity Happen
Documentation
Quality of Default Implementation
- Icehouse Summit QA Neutron session etherpad
- Icehouse Summit on testing with mulitple nodes
- Icehouse Summit on negative testing
Performance
Configuration
Communication
Scalability
HA Options
API Integration
Points to Look For
- Throwing exceptions across the API boundary that differ than those thrown by alternate implementations may be a parity issue. (e.g. validate_networks in neutron throws in the presence of multiple networks, nova-network does not)
- NotImplemented may be a significant parity issue. Even if addressed through alternate mechanisms, this is a testing /api binary compatible mismatch
Functional Parity
Network Manager Types
The FlatNetworkManager (thanks rkukura for spelling this out!):
(would this work for FlatDHCPNetworkManager as well?)
Multi-Host
- Icehouse summit Distributed Router (possible multi-host approach)
