Difference between revisions of "NovaNetNeutronParity"
(→Network Manager Types) |
(→Network Manager Types) |
||
| Line 35: | Line 35: | ||
The FlatNetworkManager (thanks rkukura for spelling this out!): | The FlatNetworkManager (thanks rkukura for spelling this out!): | ||
| − | * [http://openstack.redhat.com/forum/discussion/comment/2363#Comment_2363] | + | * [http://openstack.redhat.com/forum/discussion/comment/2363#Comment_2363 flat networks] |
| − | * [http://openstack.redhat.com/forum/discussion/comment/2394#Comment_2394] | + | * [http://openstack.redhat.com/forum/discussion/comment/2394#Comment_2394 flat networks] |
(would this work for FlatDHCPNetworkManager as well?) | (would this work for FlatDHCPNetworkManager as well?) | ||
Revision as of 20:33, 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)
