Today is the second day of the OpenStack summit, today we have Emilien giving his view of the day.

It’s always interesting to meet in person those who contribute with you on OpenStack. That’s why I love the Summit. Trying to reach the same goals by discussing design is one of the objectives in Hong-Kong right now. Since most of my work at eNovance is related to Neutron, deployments and having a focus on Quality, I will give you my thoughts about Wednesday sessions that I attended.

Neutron QA and Testing

Neutron is the virtual networking service in OpenStack. It aims to bring advanced network connectivity to virtual machines. The topic of today was about trying to find new contributors wanting to help in QA with tempest integration tests. Tempest is the integration test framework in OpenStack that we run against a live OpenStack cluster to say “my cloud is running OpenStack”.

Current Limitations of Neutron tests

The main issues talked were:

• tenant isolation are not supported
• You can’t run the full tempest tests suite
• parallels jobs are not supported yet because of first issue.
• API has bad negative tests coverage.
• scenario tests are missing.
• no Grenade support (upgrade testing)

Tenant Isolation & Parallel Testing

The main issue in Neutron QA is the non-working tenant isolation in OpenStack infra. Solutions exist and some work is in progress. They are improving the current logging implementation with “Request id tracking through all the services” support with the goal to find the bug. A second issue is parallel testing in the gate neutron breaks due to internal race conditions. Core developpers are working on fixing agent framework in Neutron, to handle load generated by tempest.

API Tests

The most relevant lack in tempest coverage are negative tests and new API features from the last release. Some developpers took the point to improve API testing during the Icehouse cycle. The priority is to fix the issues in the CI and then continue the work on tempest.

Due of a lack of time we unfortunately haven’t discussed about Grenade and test scenario.

The full etherpad in this session is located here:

https://etherpad.openstack.org/p/icehouse-summit-qa-neutron

Neutron Loadbalancing service (LBaaS)

Load-Balancing as a Service has been introduced in Grizzly release with basic features and now focuses on important improvements that cover new use-cases.

Model changes

The goal is to remove the 1:1 mapping between VIP (Virtual IP) and Pool to enable Pool reuse to:

• be able to specify several VIPs for within pool (ex: :80 and :443 to the same set of nodes)
• multiple pools for a VIP potential (which is needed by L7 rules feature)
• being able to reuse IP address for different tcp port
• being able to reuse L2 port for several VIPs

Blueprint: https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance

SSL Termination – SSL Certificate

Design proposal is transient (passed from API to driver without DB persistence) with optionnal extra-attributes in the VIP (passphrase, PEM). The challenge here was to choose a solution between using HAproxy from dev branch, or switching to another backend (nginx or stud). The conversation could not finish due to short time.

Concept of noop driver/”backendless” configuration

The target in Icehouse is to improve unit testing by using a common driver, but not as a real noop driver to avoid some pain in provider supports. This abstraction will obsiously improve the tests coverage.

The full etherpad in this session is located here:

https://etherpad.openstack.org/p/icehouse-neutron-lbaas

Neutron Pain Points

This session was very interesting since we talked about common problem we have on many use-cases when using Neutron.

Networking primitives

• One of the complaints of the community is that it’s sometimes still to hard to install and configure Neutron.
• The topic was also about how to provide default networking configuration when installing OpenStack. Some of present people was wondering if we should we use Heat to manage it easily, since there is good support of networking orchestration.

Purpose of neutron

Hot topic here. Do we need to move the network intelligency into an external 3rd party software (i.e. SDN controller)? A comparaison has been made with Nova where default supported hypervisor is KVM. Should we follow this stream in networking ? Using an Open-Source SDN solution was discussed as an eventual default Open-Source supported solution. To make it happen, the requirement will be to have contributors from this solution within core-team.

At eNovance, we are contributing at the ML2 and L2 population, and we strongly believe to bring the network intelligency within neutron core.

The full etherpad in this session is located here:

https://etherpad.openstack.org/p/icehouse-summit-neutron-pain-points