The Grizzly cycle was a successful for the OpenStack Networking team as we added many new features and worked to resolve reported issues. In this session, we'll look back on Grizzly and then discuss the OpenStack Networking development process for Havana. We'll also review the existing common components of OpenStack Networking to ensure they meet the needs of the team.
Let's get the OpenStack Networking and Nova teams together to discuss the future of OpenStack Networking being the default network provider for Nova. Part 1 will be a session held early in the week and will cover topics such as:
- Status of OpenStack networking / nova-network feature parity - Goals for Havana - Make OpenStack Networking the default? If so, when in the cycle? - Documentation impact? - How to migrate an existing deployment using nova-network? - And more!
By establishing this as a high priority goal for both Nova and OpenStack Networking early in the week, everyone should have it in mind for the rest of the week while discussing other work. We'll get back together later in the week to recap and identify specific tasks to go work on.
This session will include the following subject(s):
Networking API update:
The usual update on status of the OpenStack Networking API, and the direction for Havana.
Agenda: - New extensions introduced in Grizzly - Pagination and sorting in the OpenStack Networking API - Areas were the API needs improvements - OpenStack Networking API documentation
(Session proposed by Salvatore Orlando)
Decouple AuthZ from business logic:
The aim of this session is to gather feedback on the already ongoing activities of the blueprint: https://blueprints.launchpad.net/quantum/+spec/make-authz-orthogonal
The final aim of this blueprint is to remove explicit authZ checking from Quantum code, and move it in a module which could potentially become a middleware of his own.
Also, discuss whether the resulting code modules, which should be independent of Quantum, should then be moved to the Oslo repository.
We spend a lot of time making OpenStack Networking more complicated... adding new config options, agents, apis, etc. I'd like to spend some time on how to make it simpler. - How can be make it more bullet-proof to get a reasonable multi-node deployment up and running? - How can we make it easier for people to detect when they have made common errors (e.g., not running an l2-agent on the node where they are running the l3-agent?). - Can we write tools to help people validate a basic setup?
This is a brainstorming session. I will have some wacky ideas to propose, but the goal is to have everyone present ideas.
The database layer, which acts as a backend for the OpenStack Networking API, has become a critical component as far as performability, scalability, and reliability of the Openstack networking service are concerned.
This session should cover the following points: - Database access APIs Database access is currently spread throughout the plugin. This leads to occasional errors such as atomicity not properly handled, or concurrent updates. The aim here is to discuss alternatives to improve DB logic in OpenStack Networking, possibly leveraging oslo and using other Openstack projects as an 'inspiration' (ie: shamelessly copy). - Database Upgrades During the Grizzly time frame, Mark McClain gave us DB upgrades; we would now like to collect feedback from the developer and user community about whether the current approach is suitable for deployment which chase OpenStack Networking trunk; also it might be worth discussing whether the current approach needs to be tweaked for handling service plugins. - Usage of SqlAlchemy models The aim of this point in the agenda is to discuss how DB models are used in OpenStack Networking, identifying what can be regarded as good practice, and what instead might not be a good practice, especially when the size of the data set increases dramatically. - DB Profiling at scale This point is related to the previous one and is aimed at discussing a set of procedure to asses how the OpenStack Networking database, and the modules operating on it, can be validated at scale. Note: The list of referenced blueprints is provisional
During the past year the OpenStack Networking codebase has dramatically increased in size, and the same happened to unit tests.
OpenStack Networking now has over 5000 unit tests which take about 10 minutes to execute (at least on my machine)
While at a first glance this might seem great, most of these unit tests are actually not unit tests, but rather integration tests performed against plugins (which sometimes mock their backends with fake drivers); also the coverage of such unit tests probably deserves to be reviewed as well, as proved by the fact that odd syntax errors are sometimes still found in OpenStack Networking
The aim of this session is to have a discussion around the current state of OpenStack Networking unit tests, and decide, together with the community, an attack plan to improve coverage, reduce execution time and resource usage, and define guidelines for writing unit tests for OpenStack Networking
Proposed agenda for the session: 1 - Assessment of the current state of unit tests, with emphaisis on Plugin unit tests 2 - Discuss and decide what is a unit test and what is a integration test 2.b - If we agree that many tests are actually integration tests, do we deem them still useful? Should they be part of a gate job? 3 - Consider alternatives for plugin unit tests 4 - Fake libraries. Are they a simple and handy way for simulating a complex system, or just added burden for unit tests? 5 - Parallel testing (this should probably not even need discussion!) 6 - Define/Assign blueprints and bugs
This session will include the following subject(s):
Network proximity:
Application performance can be enhanced by ensuring that images are deployed as close as possible to one another on the underlying physical network. The scheduler will need to be aware of the network "proximity" of hosts to one another. The session will propose an API to OpenStack Networking that will return the proximity between Hosts on a OpenStack Networking network to enable a "network proximity" group scheduling policy.
(Session proposed by Gary Kotton)
OpenStack Networking Client 3.0.0:
In this session, we'll discuss the underlying changes to the 3.0.0 python library and discuss how we can update the CLI to address some of the common issues experiences by users.
Gary is a core Neutron developer working at VMware who also spends a lot of his time these days writing + reviewing code for Nova. Prior to working at VMware Gary worked at Red Hat, Radware and at Algorithmic Research. Gary holds a Bs.C in Mathematics and Computer Science from the... Read More →
Mark McClain is the Chief Technical Officer of Akanda Inc, a member of the OpenStack Technical Committee and a core reviewer for several teams (Neutron, Requirements and Stable). Mark was the Program Technical Lead for the OpenStack Networking during the Havana and Icehouse cycles... Read More →
In Grizzly we took a significant step forward with defining a network service and incorporating one service insertion model in the form of 'routed-service-insertion'. The proposed session aims to revisit this topic to move the discussion forward with exploring use cases requiring other modes of L2/L3 service insertion. The other complementary aspect of this discussion is services' chaining and possibly the requirement for steering. Currently there is one service defined and implemented in OpenStack Networking in the form of Loadbalancer, but more services such as Firewalls will also need to be added. With the possibility of more than one service it becomes relevant to explore the model of how multiple services can be requested and sequenced.
As of Grizzly, LBaaS is supported for HAProxy only. There are multiple subjects summarized on etherpad https://etherpad.openstack.org/havana-quantum-lbaas that covers the subjects for discussion in the summit.
As Quantum now is gearing towards supporting a Multi-Plugin Support Approach, one of the Service Types is VPN. In this session we will discuss how VPN's can be configured, provisioned and managed as a service through Quantum. This part 1 of 2.
In this session we will discuss potential new APIs extensions to be implemented in Havana.
This session will include the following subject(s):
QoS API for OpenStack Networking:
A blueprint has been filed: https://blueprints.launchpad.net/quantum/+spec/quantum-qos-api
QoS features can be complex. There are standards and there are vendor-specific bells and whistles. This session will bring interested parties together to discuss what we would like to see in the initial common QoS API for OpenStack Networking, and how extensions can be handled.
(Session proposed by Henry Gessau)
Port Isolation in Networks:
It should be interesting to proposed an option on the network creation that enable the isolation between ports in a same broadcast domain (network), similar to a common use of private VLANs with isolated port technologies (RFC 5517).
Quantum now has the ability to load multiple service plugins. Firewall features could be managed and exposed via a Firewall service plugin (similar to LBaaS service plugin).
Discussion topics: - Defining the resource abstractions and CRUD operations - SQLAlchemy data model - Backend "fake" driver for testing
This session will cover two aspects of improving bare metal support within Quantum: Additional VLAN support and PXE DHCP.
This session will include the following subject(s):
bare metal HA PXE dhcp-agent support:
Bare metal machines need PXE fields set in DHCP to provision properly. We currently have someone working on that, but only at the minimum set of functionality - we hope to have that landed before the summit.
However, to be production ready, having active-active DHCP agents would be much better.
In this session we would work though all the required changes to run quantum-dhcp-agent on multiple nodes (for the same network) concurrently.
The linked blueprint is for the initial work.
(Session proposed by Robert Collins)
Bare Metal VLAN network support:
This session will cover several aspects of bare metal and Quantum.
VLAN network:
With bare metal nova we cannot add or remove ethernet cards in response to user network requests. We can however give nodes access to additional L2 networks using VLANs.
For triple-o, running openstack on openstack, we want VLANs as well to partition operator and tenant traffic more thoroughly.
In both cases we need to be able to hand information to the instance which will be booting and have only native-VLAN access [but that is sufficient to access the metadata service].
In this session we will discuss the available options and decide on the route forward.
HA PXE dhcp-agent: Bare metal machines need PXE fields set in DHCP to provision properly. We currently have someone working on that, but only at the minimum set of functionality - we hope to have that landed before the summit.
However, to be production ready, having active-active DHCP agents would be much better.
Quite a few limitations in the current implementation prevend OVS or Linux Bridge to be used in large scale deployment. This session has for goal to * present the result of a first analysis done by CloudWatt for their deployment * propose a few solutions to solve those issues using various techniques * collect other ideas and suggestions from the community.
This session will be led by Edouard Thuleau (CloudWatt) helped by Nick Barcet (eNovance).
This blueprint describes a generic hardware driver interface within the OpenStack Networking plugins which will enable support for different hardware backends for L2 network segregation (VLANs, tunneling, etc.). This API is available as a common driver library under quantum/common/hardware_driver and may be used by any OpenStack Networking plugin. Currently we have modified only the popular OVSPlugin to use this driver API.
This may be useful for existing data centers with hardware switches which needs to be used along with Openstack infrastructure. In this case a hardware vendor may introduce a hardware driver which confirms to this driver API, which will allow using vendor's hardware within Openstack along with Open vSwitch virtual switches to provide L2 network segregation.
This will allow automatic L2 network provisioning on the hardware devices alongside with the open vswitch provisioning in the compute node hypervisors.
We have implemented the driver API proposed in this blueprint and are providing the source code for an Arista Driver which supports provisioning of Arista TOR (top-of-the-rack) switches alongside with open vswitches.
In this session we will look at modularization efforts for both L2 and L3 services.
This session will include the following subject(s):
L3 API modularization:
The purpose is to discuss issues related to L3 routing provided by separate service plugins as opposed to integrated in core plugins. Even though L3 routing is focus, this will have relevance to Quantum SI in general.
Things to cover could be API related like if L3 resources become part of core, how will Quantum support those to be provided by other than core plugins? Also, would there be a benefit in breaking apart some of the API/resources today bundled together as "L3" (e.g. NAT)? Another thing to cover could be handling of state dependencies between plugins (one plugin has state dependent on resource handled by another plugin, floatingip one example), can Quantum support this in generic way?
A service plugin for L3 routing (but also other network services implemented as part of Quantum's SI framework) could be implemented by relying on Nova managed VMs. Connecting and de-connecting such service VMs to different subnets/networks could be simplified if Quantum supported something analogous to VLAN trunks on physical switches. This has been proposed in a blueprint. But how should that be represented/implemented in Quantum, by extending ports or as new resource?
(Session proposed by Bob Melander)
Modular L2 Plugin - Design, Status and Future:
A modular layer 2 plugin (ml2) was proposed and discussed during the grizzly design summit. In contrast to existing monolithic plugins, ml2 uses drivers to simultaneously support an extensible set of network types and to simultaneously support an extensible set of mechanisms for accessing networks of those types.
During grizzly, an initial design for ml2 was created, implementation was begun, and a work-in-progress patch set was reviewed. Meanwhile there has been growing community interest in achieving the goals that the ml2 plugin attempts to address, such as:
* better support for mixing heterogeneous networking technologies * supporting complex network topologies (i.e. multi-segment L2 networks) * reducing the amount of code that needs to be written and maintained for each supported networking technology
This session will start with a brief overview of the ml2 plugin's initial goals, its current design, and its development status. This overview will be followed by open discussion of its future in havana and beyond. Possibilities include:
* replacing the existing non-controller plugins (linuxbridge, openvswitch, hyperv) in havana, using their existing L2 agents * replacing the existing L2 agents with a driver-based modular L2 agent * supporting new networking technologies in havana via drivers rather than adding new monolithic plugins * replacing existing controller-based monolithic plugins with ml2 drivers * replacing the quantum core monolithic plugin interface with a set of more-modular driver interfaces * extending the quantum API to control physical network topology and other deployment details currently handled via configuration files * addressing orchestration of higher-level activities that cross the various networking layers and the available mechanisms at each layer
(Session proposed by Robert Kukura)
Wednesday April 17, 2013 11:00am - 11:40am PDT
B114
In this session we will propose a new pluggable architecture model for OpenStack Networking back-end architecture, where Physical Networking Infrastructure (PNI) and Virtual Networking Infrastructure (VNI) are managed by different type of plugins. These plugins will be technology specific and their scope is limited to the capabilities of the domain where they belong. OpenStack Networking users will decide which PNI and/or VNI plugin include in their deployment, OpenStack Networking should allow to use one plugin per type but including multiple plugins could be discussed.
(Session proposed by Edgar Magana Perdomo)
Wednesday April 17, 2013 11:50am - 12:30pm PDT
B114
Quantum now has the ability to load multiple service plugins. Firewall features could be managed and exposed via a Firewall service plugin (similar to LBaaS service plugin). This is a follow up session from the prior day to discuss the path to implementing FWaaS in Havana.
OpenStack Networking networks are currently flat L2 domains - every machine can reach every other machine in one hop, the domain is a broadcast domain and OpenStack Networking's task is to ensure this holds true regardless of where VMs are placed. Limitations on L2 networks hold true - L2 networks are not great at scaling, which is why there's an 'inter' in 'internet', and joining these networks together involves various sorts of encapsulation.
We can add simple layer 3 networks to OpenStack Networking. The network is no longer flat, scales better and has significant advantages for public-facing services, and standard internet routing holds sway with no encaps; it has significant advantages when you're willing to lose L2 and the features that depend upon it.
We will discuss how we could do this with a minimum of complexity, and why it's a good idea.
MVRP is a standards-based layer-2 protocol for the automatic configuration of VLANs. With MVRP, VLANs can be configured at the end-port, or the network device connected to the switch port, and the VLAN trunks are dynamically created on MVRP enabled switches. Support for MVRP gives OpenStack Networking a standards based alternative to proprietary VLAN provisioning and configuration systems, and simplifies the work of configuring nova with VLANnetworking.
(Session proposed by ChristopherMacGown)
SR-IOV NIC support :
Although generic SR-IOV support is mostly nova story, SR-IOV NIC has some specific features from networking point of view. For example, how to keep the network isolation when the VF NIC is assigned to VM directly, how to live migrate the VM with VF NIC. These deserve careful discussion in H summit.
(Session proposed by jiang, yunhong)
Integration tests based on NaaS requirements:
co-author: Mahankali, Sridhar co-author: Luo, Xuan
* requires one full session
The problem with Quantum tests in Tempest is that the test cases are tightly coupled to what the Quantum API provides. Therefore the test cases have no significant difference with unit tests other than not having stubbed objects.
In order to prove that Quantum and its plugins are production ready, we need a thorough collection of integration tests based on NaaS requirements.
I've gathered some NaaS features as a checklist in the document below.
As Quantum now is gearing towards supporting a Multi-Plugin Support Approach, one of the Service Types is VPN. In this session we will discuss how VPN's can be configured, provisioned and managed as a service through Quantum. This is the follow up session to continue the previous day's discussion with the goal of determining the work to be completed during Havana.