OpenStack Mitaka Design Summit

With the Liberty release of OpenStack, Neutron will have the ability to act as a BGP speaker on an operator's network.  This functionality enables Neutron to advertise host routes for floating IP's, and next-hops for tenant networks created with Neutron. This can alleviate many of the networking burdens placed on the operator when designing and operating an OpenStack cloud. It also enables new functionality in Neutron such as floating IP mobility and directly routable IPv4 and IPv6 tenant networks through a Neutron router.  In addition, deployment of Neutron BGP dynamic routing enables better support for existing features such as IPv6 and distributed virtual routing (DVR).

In this session we will explore how to use Neutron BGP dynamic routing to maximize the value of your Neutron deployment.  We will demonstrate how to deploy, configure, and use Neutron BGP dynamic routing and discuss the use cases it enables.  We will also explore how Neutron BGP dynamic routing works with features such as address scopes, routed network segments, distributed virtual routing (DVR), and what considerations operators should be aware of when deploying Neutron BGP dynamic routing.  We will also discuss future plans for expanding BGP dynamic routing capabilities in Neutron.

As IPv6 adoption continues to grow, there is an increasing need to deploy services in IPv6-only environments.  Openstack supports a myriad of configuration parameters for each service that can all be used together to create a deployment that requires only IPv6 addresses.

This talk will share experiences and lessons learned in deploying and operating an Internet-facing IPv6-only cloud, along with a demo showing its operation.  We will also give an outline on what needs to change, work that still needs to be done, possible future enhancements, as well as describe some new parameters in devstack that can be used to quickly get an IPv6-only test cloud up and running.

Service chaining allows dynamic steering of traffic from source, through a sequence of service function devices (physical or virtual), to destination. In current Data Center, the deployment of service chain for a tenant's flow is through static, complex, and rigid configurations and it usually takes days or weeks to deploy it. To reduce the OPEX and increase agility, automatic setup of service chaining is reuqired. 

Service Function Chaining (SFC) has long been a strongly requested feature in Neutron, and with the advent of Network Function Virtualization (NFV) as a major use case for OpenStack, that demand has only grown stronger. The wait for such feature is finally over in Liberty.

To address the needs, Service Chain feature is currently being developed as part of the Neutron Project. The community had gotten together and are developing a standard-based, vendor-neutral SFC functionality in Neutron using OVS as a reference driver implementation. In this talk we will give an introduction on the service function chaining project and its roadmap.

Attendees of this session will get to know:

1. Architecture Design, APIs, and Data Models of the Solution


2. Extensibility, Scalability, and Performance Consideration


3. Current Project Status: Where are we now?


4. Project Roadmap

If you are an operator or user of DNS come learn about Designate, the DNSaaS provider for OpenStack. We will cover:

• Designate Architecture Overview


• Designate Use Cases


• Exciting features that landed in the Liberty release: ALIAS Records, Pool Scheduler, Horizon


• Integration with Nova and Neutron


• How Designate works any DNS server


• Customization points - API Extensions, Storage Plugins, Backend Plugin

We'll conclude with an exciting live demo showing how to add support for your favorite DNS server to Designate!

This talk will discuss our experiences deploying Hierarchical Port Binding in production and at scale.  We'll compare an existing OVS+VXLAN implementation with a newer HPB+VXLAN based implementation.  We'll talk about the benefits of the newer implementation, as well as the problems we ran into along the way.

You just want to get to your instance by name.  But, Nova has your hostname, Designate has your DNS service, and Neutron has the IP allocation.  Could these ever be brought together to make it work like you want it?

In fact, they have come together.  In this talk, we'll talk about where we were at the end of Kilo and show you how we've come together to make this work across projects to give you the experience that you wanted.

"I can't ping my VM" , "Floating IP is not working" ....many people contact me with this kind of problems. That's why I decided to collect the most common hiccups of a Neutron deployment in this session,  provide some knowledge to understand the reason for the failure and a structured way to solve it.

Neutron has a good feedback cycle between getting new features added and getting them tested by other contributors so they are functionally correct within one or two releases. Unfortunately, after a feature is working ("it worked in devstack!"), developers tend to move on to the next new thing. This happens well before the previous features are deployed at a large scale.

This delay has led to limited attention being paid to the performance of Neutron's HTTP management API and the AMQP control plane it uses to communicate with its agents. Subsequently, several cases had emerged over the past few cycles where operations were taking orders of magnitude longer than they should have to complete. These were imperceptible to developers because they were usually amplified by large numbers of networks and ports (instances) not present in a typical development environment.

This presentation will cover the wide range of performance improvements made to the Neutron management and control plane over the last ~6 months. These include both user-facing improvements (e.g. the time it takes to list Neutron networks) and deployer-facing improvements (e.g. the ratio of Neutron servers to L3 agents required to respond all agent requests). Benchmark and improvement numbers will be provided using measurements taken by Rally. This will be focused on the open source ML2 reference implementation; however, most of these improvements benefited many 3rd party plugins/drivers that utilize the same APIs.

Yahoo is huge! Yahoo has always had some legacy infrastructure in place, for better or worse, to solve the problems that OpenStack now solves. When we try to move to OpenStack, we can’t just get rid of existing infrastructure one fine day and tell people - “hey, I know that you have been using this or doing things this way for a long time.. From now on, you just can’t do that anymore. You need to update all your automation to work with this new thing”..

That will definitely piss off people.

Also, most of these legacy requirements come from our huge scale. So we need to make sure that when we move to OpenStack,  we continue supporting those use-cases. To do so, we need to patch Neutron heavily as it currently doesn’t support them. Most of them are useful for the community as well, since anyone at this scale is going to have similar requirement.

We are working with community to upstream them. With this talk, we would like to share our experience, use-cases, hacks and also like to know if anyone else in the community has the same requirements.

We need following features to support our legacy use-cases

• Static IP allocation: Currently, when inventory is installed in racks, our site operations team picks IP address for the inventory and updates our inventory management database. Currently, we consider this database as source-of-truth. When this inventory is added to Ironic and booted, Neutron first looks at its original IP address, creates networks/subnets on-the-fly, if not already present and then assigns the same IP to the instance. Currently we have to do this because we can’t yet treat Neutron as the source-of-truth for bare-metal inventory. We are slowly trying to move towards Dynamic IP allocation where Neutron will be the source of truth, but there are certain blockers that we need to solve first.


• Single process Dnsmasq support for Neutron DHCP Agent: At Yahoo we don’t have tenant networks or overlapping IP spaces. So we don’t need dhcp-agent to spawn a Dnsmasq process for every network. We have patched the agent and the driver to spawn a single process responsible for all the networks. We don’t plan on using this patch forever, but only temporarily until we get support for ISC-DHCPD driver in.


• Support for ISC-DHCPD driver for Neutron: Dnsmasq does not scale well, especially for a scale at which Yahoo operates. Also, ISC-DHCP is mostly what is used at this scale. Currently Neutron DHCP agent doesn’t support any other DHCP server that Dnsmasq. In fact, the agent itself is so aligned with Dnsmasq, that it doesn’t work as-is for ISC-DHCP. So we have modified the agent and added a driver for ISC-DHCPD. This work is being upstreamed. 


• Support for multiple gateways for a subnet in Neutron: At Yahoo, the network architecture is such a way that multiple gateways are configured for the subnets. These multiple gateways are typically spread across backplanes so that the production traffic can be load-balanced between backplanes. Currently, the subnets in Neutron only support one gateway. We are working with community to add multiple gateway support to Neutron subnet.


• Multi-IP support: For one of our use-cases, we need ability to allocate multiple IPs for an Ironic instance, but not necessarily create a port for it in Neutron. Currently we are evaluating different ways we can do this.


• IPv6 support on Opt-In basis: We need Neutron to be able to allocate IPv6 addresses, but not always. We have some legacy stuff that will simply not work with IPv6. So we need provide ability for users to “Opt-In” for either only IPv6, only IPv4, or both. This is also something that community doesn’t support as of now. We would like to know if others also have similar use-cases, so that we can work with them to upstream this.

If you are an operator or user of CDN, then come learn about Poppy - the CDNaaS API for OpenStack.

We will cover:

• Poppy Architecture Overview


• Poppy Use Cases


• CDN Vendor Drivers that are part of Poppy


• Exciting new features that have landed: Multiple Domains/Origins, TTLs, Host Headers, SSL, Referrer/Geo/IP Restrictions


• How Poppy works with your preferred CDN vendor


• Customization - Vendor Plugins, Storage Backends, DNS Plugins