OpenStack Summit Fall 2012

With Folsom, there were a couple key gaps around Quantum/Nova integration

- no equivalent of multi_host for quantum
- metadata service did not support overlapping IPs
- nova security groups couldn't handle overlapping IPs (this is being handled by security groups in Quantum, but we still need someone to do the work for iptables based security groups).
- nova CLI commands for security groups + floating IPs do not proxy to quantum.
- define best model for handling case where nova VM is spun up with no NICs.
- tools to migrate existing nova configs to quantum

With this session, we should also come to a conclusion on what network functionality will continue to live in nova for grizzly.

Note: looking for someone to lead this session (may be moved to a split session)

There are several aspects of vif-plugging that could be improved.

Some thoughts are here: https://bugs.launchpad.net/quantum/+bug/1046766

Other topics:
- generic vif-plugging mechanism to report data back to Quantum.
- moving all vif-plugging drivers into Nova (should have been done a long time ago).
- auto-setting vif-plugging based on response from quantum
- supporting multiple vif-plugging types at same time

Note: garyk will be leading this session.

Note: we will also discuss improvements to the internal DB model layer to better handle extensions.

This session should cover the following topis:
1) Promotion of extensions into core, in particular the L3, and provider networks extensions.
2) Approval of a plan for deprecating attributes and replacing them without breaking backward compatibility
3) Decision on renaming tenant_id to project_id in order to align with Keystone v3
4) Formally describing and documenting the Quantum API through schemas, and assessment of the potential for code and documentation generation.
5) Other API improvements, such as pagination and link to resources in responses.
6) Improvements to the Quantum client library and CLI

The current Quantum python client is a very thin wrapper over the API protocol. In Grizzly, we should look improve the python client by making the python library more pythonic and easier to consume by developers. (Note: These changes will fit nicely Ian's proposed session about client lib documentation). In addition to the python library, we will also discuss the CLI and how to improve consistency across the command set.

Python Library Discussion Points:

- The python bindings are a light of a wrapper and leak too much of the wire protocol.
For example:
client.list_ports() should return a list instead having to do not client.list_ports()['ports']
client.create_port(dict(port=my_port_attributes))

- Adding the specific named params to the client library code. Update the method heirarchy of the client lib to improve code reuse of basic CRUD operations. The interfaces could possibly be created by automatic generation tools. Specific parameter names will help developers understand how the library works.

- Discuss an optional interface to the client bindings that returns proxy objects (ala SQLSoup).

CLI Discussion Points:

- Inconsistent option names

- The parsing frequently breaks on extended attributes if you forget the '--' which is inconsistently used. We should be able to make Cliff parse unknown flags correctly (per Cliff author's Doug H).

- Data type conversions. The CLI should be able to automatically coerce args types vs having to specify type flags such as bool|int.

- Embedded dicts as command line args make the CLI harder to use.

- Better error handling for unknown arguments.

Top priority for the Quantum team in Grizzly is getting good integration with tempest and initiating gating with quantum tests

Note: Nachi will be leading this session.

note: split session.

This session will include the following subject(s):

Quantum Scheduler:

Scheduler support for quantum

- HA support
- Nova scheduler integration
- Agent monitoring
- Agent resource management



Quantum and XenAPI / XenServer:

There seem to be lots of issues getting the Folsom version of Quantum working with XenServer.

Let's look at making the Open vSwitch Driver + DHCP working well, working well with DevStack, and getting it tested.

Beyond support for GRE networks, there is no meaningful server-side
difference between the current openvswitch and linuxbridge
plugins. Both support VLAN tenant networks and the same set of
provider network types. Their agents also are similarly structured,
differing mainly in the specific networking commands they run in
response to the same set of events. We will propose replacing these
two plugins in Grizzly with a modular Quantum plugin and agent where
both L2 network types and the mechanisms supporting those types
plug-in as driver, allowing multiple networking technologies to be simultaneously deployed within a Quantum installation.

Network types such as VLAN, GRE, and flat will be implemented in the
server-side plugin as network-type-drivers. These network-type-drivers
are responsible for maintaining any type-specific DB schema, pooling
and allocating tenant networks, and validating parameters for provider
networks. But a network-type-driver is not tied to any specific
mechanism for realizing that network type on participating compute or
L3 agent nodes.

The current Open vSwitch and Linux bridging mechanisms would plug into
the modular L2 agent as agent-mechanism-drivers. Nodes using different
agent-mechanism-drivers for a common network type could co-exist and
interoperate within a Quantum deployment. Multiple
agent-mechanism-drivers could also plug into a node's L2 agent
simultaneously to handle different network types. We will also explore
server-mechanism-drivers that would integrate certain centralized or
controller-based mechanisms on the server-side, without the need for
L2 agents on the participating nodes.

This modular L2 plugin and agent architecture is not intended to
replace the current Quantum plugin abstraction. Non-modular plugins
are more appropriate when an external controller completely controls
the data center network. We will discuss the benefits this modular
architecture offers in cases where a variety of networking
technologies co-exist within a data center. In particular, we believe
this approach is more flexible and more maintainable than the
meta-plugin approaches currently used in Folsom.

Extending Quantum functionality with Heat requirements

Design session introducing heat requirements for Quantum including a
further discussion of specific requirements and implementation planning.

Our planning, yet incomplete but being mapped out is here. We will be
ready to roll by summit:

ttps://github.com/heat-api/heat/wiki/Roadmap-Feature:-VPC-Quantum-mapping

Note: this session will likely not take the entire slot, so we may slot an additional item into this session "on-demand" (aka "sessions-as-a-service).

split session

This session will include the following subject(s):

Make IP allocation algorithm pluggable:

The default IP allocation algorithm works well on internal networks with its quick reuse and compact IP allocation strategy. On shared or public networks, this allocation scheme may not meet the providers security needs (rapid re-use by another tenant). In Grizzly, IP allocation should be pluggable by network, so that providers can choose the strategy that best fits their needs after weighing the space/time cost of each approach.

Proposed allocation approaches include:
first available ip
random
least recently used

Proposed recycling approaches include:
expiration delays
tenant affinity (ie on shared network a tenant is likely to get back the address they just released)
address space exhaustion before reclamation
DNS aware expiration (ie don't expire if DNS record is still pointing at IP).



Improving IPv6 support :

Quantum has rudimentary IPv6 support. In Grizzly we need to expand and polish the implementation.
- better DHCPv6 support
- fully working RA
- L3 Router support
- v6 firewall and/or security group support
- Automatic v6 subnet allocation/creation

The existing Quantum API provides APIs for based L2 and L3 communication. There is a lot of demand for inserting higher-level services, for example, firewalling, load-balancing, VPN, etc.

The discussion will talk both about generic mechanisms for extending the L2/L3 model to insert services. We will not discuss the design of individual service APIs (LB, FW, etc.) other than as example of how one such service insertion mechanism might be better suited than another.

We will also talk about a mechanism by which third-parties can services APIs that are independent of whatever "core plugin" is running.

What is it:
- proposal for integrated connectivity ( L2 and L3 ) and services (security, load balancing, internet access, NAT, QoS, ...) APIs for Quantum.

Goal:
- abstract APIs that decouple desired connectivity/services specification from implementation, enabling coherent specification of connectivity and services APIs with repeatable pattern for future extensions. This would allow Quantum to manage underlying network comprised of best of breed virtual and physical systems.
- compatibility with existing API v2.0

This will be a working session for discussing the changes to ceilometer and quantum necessary to integrate them to enable metering of network resources. The goal is to develop a general design and task break-down for the work to be done during the Grizzly release timeframe.

With Quantum now being part of Openstack core, it is of paramount importance that users are provided with a simple and reliable upgrade path, beyond package upgrades.

This should include at least database synchronization, but possibly also component versioning (for instance if you try and run a v1 plugin against the v2 API this should be properly checked).

The aim of this session is to:
1) discuss which are the key upgrade areas
2) discuss alternatives (and possibly approve a proposal) for handling db upgrades and component versioning (if deemed necessary)

In addition to the tenant and provider facing APIs the additional functional requirement should be discuss with the following list as an example:
Plugin Model
- Service capabilities versus plugin capabilities versus middleware
capabilities
- Multiple simultaneous plugins (to support multiple LB models)


Quantum Integration/dependency
- should the service be deployable standalone (without Quantum) ?

Additional dependencies/integration
- keystone
- horizon

Tenant API
- review of comparison of various implementations
- Review a proposal for common resource model for tenant api

- discuss the Implementation as either a single endpoint with extensions
or a different endpoint.
For reference, nova is using both : nova-api expose different endpoints
(os-api, metadata, ...)
and extensions for admin actions (e.g. http://goo.gl/udpkK)
- discuss proposed resource model for provider API

Youcef leading this one?

The Cloudpipe VPN service currently works as a service VM controlled by Nova. In Grizzly, we should examine moving the VPN service to Quantum. The benefits include:
- direct access to network infrastructure
- VPN process running in network namespace is less resource intensive
- easier to integrate VPN into other security features added to Quantum

Serge is leading this session

Today, DNS is implemented in Nova. However, with the consolidation of network services in Quantum, it would make sense to re-evaluate the DNS implementation so that DNS configuration and management is more tightly integrated with DHCP and IP address Management.
In addition of the consolidation, this would give us an opportunity to consolidate multiple efforts, and enable additional features in Openstack to support a more general purpose DNS provisioning solution.

split session

This session will include the following subject(s):

ARM Support for Quantum:

In the last couple of releases we made great progress with Nova, Glance, and Keystone running on ARM. We have to keep this progress up, but now we have to focus on Quantum as well.

Newtonian - Network Orchestration Service:

We have been running into limitations using Quantum at scale. In order to solve our use case we are building Newtonian. Newtonian will have a nova oriented API, a public accessible quantum API, an authoritative database, and have a plugin layer on the backend supporting quantum plugins. This has started as a Rackspace specific use case, but we want to make it public so others can play with it and contribute as well.

split session

This session will include the following subject(s):

Packet Filter API and its drivers:

A packet filtering API for Quantum network will be proposed.
This API provides a fine-grained packet filtering where
each filter entry consists of matching fields, an action and a priority.
The matching fields consists of in/out quantum port-id, src/dst mac/ip addr/L4 port number
and so on and they are similar to iptables and OpenFlow matching fields.

While the security group exists in OpenStack as a packet filtering feature,
this API provides more fine-grained packet filtering like outgoing packet filtering from VMs,
inter-VM communication and . In addition, some usecases requires controlling packet filtering
rule based on its operational status: for example, bare-metal computing support requires some communications is allowed only during an instance booting.

We believe such primitive (low-level) API is useful for these usecases.
The security group feature can be implemented on top of this API.

This API can be implemented by various method (iptables, firewall appliance, OpenFlow-based filtering
and so on) and plugin (or driver) architecture would be suitable.

Firewall API for quantum:

API for stateful firewall at the gateway.

This session will include the following subject(s):

LBaaS 4 - Implementation planning :

talk about actual design of code modules, who will be working on what parts of the code, etc.

half-session

non-technical community session to discuss plans for scaling leadership within the Quantum team. The quantum project is growing quickly, and is taking on a wider breath of topics (particularly as we move to higher-level services).

This session will propose a strategy where we have different "sub-systems" of quantum, each with their own lead, similar to nova.

For people new to Keystone development, this session attempts to provide insight into how the Keystone code is structured.

LDAP works, but there have been a lot of discussion about how it is supposed to work in the future. This will hammer out LDAP default schema, configuration, and Active Directory integration.

After an overview of the current state of PKI in Folsom, we'll launch into a discussion of where it needs to go in the near future.

We made no progress against https://blueprints.launchpad.net/keystone/+spec/multi-factor-authn during the Folsom release - this is to check on status, revitalize the topic, and see if there's interest in enabling this during the Grizzly release timeframe

overview of the V3 API spec and what's available and drafting up in the v3-feature branch on Keystone

We are shifting this talk to be specific to the details of implementing authenticated delegation/impersonation and gathering feedback on policy implementations and use cases needed by existing deployments.

This session will include the following subject(s):

Federation:

Federation means different things to different people. This session attempts to layout the range of proposals, and to drive toward a consensus of how to implement in Grizzly.