Comment 13 for bug 1046121

Attempting to clarify...

During initial development of the networking guide somewhere in the Icehouse-Juno days, we didn't see a demand for "hybrid" architectures that support attaching a VM to public/provider and private/project networks. However, recent trends indicate an interest in hybrid architectures because they offer the most flexibility.

For Liberty, the installation guide architecture supports two networking options. Both options support attaching a VM to a public/provider network... the most simple way to deploy neutron, but does not support self-service networking. The second option augments the first option by adding the L3 agent to support self-service networking and attaching a VM to a private/project network with a router, floating IP address, etc.

The networking guide (currently continuous release) supports a variety of scenarios or networking architectures. Scenarios that traditionally provide self-service networking currently only support attaching a VM to a private/project network to reduce complexity and arguably push deployers toward "true" cloud networking. Technically, the only limiting factor is the lack of a provider network interface on the compute nodes and some additional configuration. We either need to modify the existing scenarios with self-service networking to enable attaching a VM to a public/provider network or create additional hybrid scenarios. I lean toward the former because it reduces information overload (to many choices with subtle differences) and minimizes duplication of content. However, it increases complexity (especially diagrams and packet flows) of an already difficult topic for our audience to understand.