nova & neutron what's new in...

Nova & Neutron

What's new in Kilo

Pasquale Porreca & Daniele Casini, DEK Technologies

Specifications tweaks in Kilo

New specifications process introduced in Juno

• Specification is a formal document which defines what is being implemented

• Specifications are reviewed separately from the code

• To ensure an higher quality of the developed features, the specification process was intentionally slow

Tweaks for Kilo

• Trivial blueprints: for trivial changes a blueprint is enough

• Fast track approvals: helps to continue the work without starting the specification from scratch

• Backlog specifications: only the problem description section is required, not the implementation details

• Kilo priorities: a list of blueprints that deserves special attention from reviewers

3/31/2015 | Page 1 [email protected] [email protected]

mailto:[email protected]



Contents


Kilo Priorities Nova

• Cell v2

• Continued object transition

• Scheduler

• V2.1 API

• Functional testing

• Nova-network to Neutron migration

Neutron

• Distributed virtual router in Neutron

• Advanced services split

• L3 agent restructuring

• Pluggable IPAM

• VLAN trunking networks for NFV




Cells v2


Problems

• Single database and message queue for data persistence and communication

• Difficulties at scaling and providing fault tolerance

Cells

• Cells is an experimental feature to partition compute nodes into smaller groups with their own database and queue

• Nova-cells service for communication between the Nova API and instances/hosts within a cell

Cells v2

• Only deployments based on cells: the default installation will be a single cell setup

• In case of Nova API requests, a particular instance is identified by the three-tuple (database, queue, hostname)




Continued object transition


A conversion is ongoing on data structures used for RPC or database communications

An object encapsulation called Nova Objects is being introduced

Multi-versioning support for live-upgrade and database schema independence




Scheduler


What is the nova-scheduler

A service to establish which host a VM should be launched on

Kilo update for nova-scheduler

Clean up of the scheduler interfaces to have the nova-scheduler access clearly defined and isolated

Gantt

A project called Gantt is being started to provide a Scheduler-as-a-Service splitting the scheduler service out from Nova




V2.1 API


V2 API

It suffers for several problems

• Incorrect success return codes

• Poor input validation

• Poor or inconsistent error handling

• API inconsistencies

V3 API

• Already started in Havana and present in Juno as experimental feature to address the above problems

• Backward incompatibility

V2.1 API

• Introduced in Kilo, providing most of v3 API benefits while removing the backward incompatibility

• A new microversioning mechanism introduced in Kilo to easily change the REST API




Functional testing


Unit tests were required while only a few functional tests, mixed with unit tests, were performed

Functional Tests check for correctness of a specific feature matching the results for a given input against the specification

In Kilo

• Tree Organization of the tests is changed

• Functional tests have their own dedicated place




Nova-network to Neutron migration


A migration procedure from nova-network to neutron is wanted for OpenStack deployments already in place

The migration procedure requires impacts both in nova-network

and in neutron

The main purpose is to ensure that the control plane elements can continue to work and that an operator could perform a rolling upgrade

The idea is that during migration Neutron REST API are restricted to read-write only by nova-api

Even if some work has been done, the migration procedure was not ready for Kilo and it has been postponed to Liberty




Contents


Kilo Priorities Nova

• Cell v2

• Continued object transition

• Scheduler

• V2.1 API & API Functional testing

• nova-network to Neutron migration

Neutron

• Distributed virtual router in Neutron

• Advanced services split

• L3 agent restructuring

• Pluggable IPAM

• VLAN trunking networks for NFV




Distributed virtual router in Neutron


Problem All the L3 Compute traffic flows through Neutron L3 Routers that are deployed in Network Nodes

• Tenant intra VM traffic flows through the Network Node

• VMs with Floating IP also receive and send packets through the Network Node Routers

Solution Add DVR (Distributed Virtual Router)

• VXLAN/GRE network supported in Juno

• VLAN underlay support added in Kilo




Advanced services split


Problems • Development concentrates around either layer 2 and 3 or layers 4

through 7

• Development is slowed down due to different velocities

Solution Split the Neutron repo into four repos, one for basic L2/L3 plumbing, and one each for LBaaS, FWaaS, and VPNaaS




L3 Agent restructuring


Problem

Most of the L3 agent functionality is provided by a single class which comprises about 75% of a single python file that is just over 2,000 lines of code.

This structure makes the agent very difficult to be extended and modified

Proposed change

• Create a full-fledged class that only handles the implementation of the router

• Decouple L3 services from the L3 agent class




Pluggable IPAM


Problems

• OpenStack is not yet ready to be integrated with existing infrastructure that uses external IPAM (IP Address Management)

• Most (if not all) Neutron plugins leverage an IPAM implementation that is embedded in the db_base_plugin implementation (difficult or impossible to integrate it with an external IPAM backend)

Proposed change

Addition of a well-defined, abstract IPAM interface, and refactoring of the existing NeutronDbPluginV2 to utilize that interface rather than directly perform IPAM actions on its own




VLAN trunking networks for NFV


Requirement

VLANs are needed for many NFV functions in order to keep different traffic flows separated

Problem

Many commonly used Neutron plugin configurations create networks that do not permit VLAN tagged traffic to transit the network (e.g ML2 when using the OVS or the VLAN)

What is implemented in Kilo

Added vlan_trasparent attribute to notify whether a specific network configuration supports trunk link or not

Future work

Fix OVS driver to support trunk port for VMs




[email protected] [email protected]




nova & neutron what's new in...

Documents