First of all, thank you very much for sharing your thoughts. I really appreciate your perspective on how things are going with OVN.
On 02/11/2016 07:41 PM, Matt Kassawara wrote: > So, what do we do? Suggest a hybrid architecture with the following aspects: > > 1) Instances that require access from external networks contain a port on > the provider network. > 2) Instances that only require occasional access to external networks > contain a port on a private network and use SNAT on a router. If an > instance requires access from external networks at a later point, add a > port on the provider network. > 3) Instances optionally contain a port on one or more private networks to > facilitate communication among instances. > 4) Use a combination of multiple network nodes, clever network scheduling, > and L3 HA (neutron implementation of VRRP) to increase performance, > scalability, and reliability of routing among private networks and SNAT. > 5) Distribute DHCP and metadata services across multiple controller or > compute nodes. This deployment method seems quite reasonable. In fact, it seems we support a fairly simple form of this already. Without a gateway, private networks remain for inter-VM communication only and you *must* put an interface on the provider network for external connectivity. An OVN gateway solution will cover the rest. Obviously we'll have to keep working on the gateway story to ensure good scale and HA, but it won't have everything on the first pass. > What's missing? Floating IP addresses! > > I think OVN should support the NAT/FIP architecture, but only as a > temporary measure to increase adoption by operators using it. In fact, we > should use the words "classic" or "legacy" around it in any documentation. > For new deployments, suggest a hybrid architecture and provide ample > documentation for it similar to the scenarios in the networking guide. > Meanwhile, development should focus on supporting actual routing such as > advertisement of private networks via one or more dynamic routing > protocols. After release of this feature, deprecate and eventually remove > NAT/FIP support. Given how popular floating IPs are, I'm not sure I'm convinced we should get rid of it. It doesn't seem like a lot of extra work to keep it on top of what we'd need anyway. > P.S. - If OVN decides to support the NAT/FIP architecture, I strongly > recommend also offering some form of HA such as VRRP in the initial release > to increase appeal to operators, most of whom became wary of neutron's > inability to eliminate single points of failure for so many releases. > I don't want OVN to repeat mistakes of neutron, even for a little bit. It depends what you mean by "initial release". I don't think we should not merge code, but it could be a question of when we drop the "experimental" label from OVN, or at least the gateway functionality. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
