Hi, I wanted to send an email out to introduce a new idea in TripleO about how we can go about configuring isolated networks for our baremetal Overcloud traffic. The thoughts here are largely about the ability to split out the baremetal Overcloud traffic via our tooling (Heat templates).
What TripleO does today: >From an Overcloud configuration standpoint TripleO today is largely built around a flat network we call the control plane. It acts as the provisioning network. We run our tenant traffic in it via a GRE or VXLAN tunnel. The internal API traffic runs on it. There is a lot going on on this network. We've got the ability to wire in a separate public network IP on a controller machines but besides this the network is largely a single control plane. What we would like: We would like the ability to split out some of the traffic onto isolated networks. Some examples: It would be nice to have a storage network that is dedicated for storage traffic. This could be things all things Ceph, Glance, and Swift related. An isolated Tenant network might be nice. Or a dedicated network for all the internal API communication. These are some examples... We would like some common cases to be well represented upstream... but things should be very flexible with regards to both the networks and how things are wired up to the physical NICs. ------------- There is an etherpad [1] where some of us have been hacking around some of these things. The developing set of patches allows us to: 1) Create some extra Neutron networks via Heat. These are largely used for IPAM only to help assign the required IP address ranges via Heat using Neutron::Port resources. 2) Ports resources which are represented (currently) as nested stacks. These resources allow the network port assignments to be opt-in per network. If you don't want a "tenant" network... no problem. Just don't configure it in your resource registry and traffic will continue to run on the ctlplane. 3) ServiceMap and NetworkIpMap resources that help us to assign the correct IP addresses to each service. Using this approach we can for example have the Neutron ML2 plugin set its local_ip to the correct network thus diverting where traffic runs for the tenant network. The end result looks something like this: https://review.openstack.org/#/c/178716/ We will eventually want to do this for all all sorts of service endpoints so their traffic can be isolated on a specific network. Would love to hear feedback on the approach. I know it is probably late but it would be nice to fit a talk about this into one of the TripleO sessions at the summit as well. Dan [1] https://etherpad.openstack.org/p/tripleo-service-endpoints __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
