Quantum, OpenStack's virtual networking service, is slated to replace Nova's networking service in the upcoming Folsom release. Initial Quantum development has focused on the basic requirements of a green-field Nova cloud deployment. Additional requirements will be discussed that enable Quantum to support private Nova cloud deployments within existing data centers, as well as enterprise virtualization with the oVirt project. Initial work is underway for Folsom, and additional work will follow.

1. Preparing Quantum for the
Data Center
Bob Kukura <rkukura@redhat.com>
Boston OpenStack User Group
June 21, 2012

2. Agenda
● Red Hat + OpenStack Background
● Quantum Overview as of Essex
● Quantum in Folsom
● Data Center Enhancements
2 Boston OpenStack User Group 2012

3. Red Hat + OpenStack Background
● Red Hat involved with OpenStack since mid 2011
● Full-time [core] developers on most OpenStack upstream projects
● Platinum member of OpenStack Foundation
● Fedora as a primary OpenStack development platform
● Multiple downstream activities
● Packaging OpenStack for Fedora and Enterprise Linux (EPEL)
● OpenStack sessions and labs at Red Hat Summit in Boston next week
● Proof-of-concept integration of Quantum with oVirt (RHEV upstream)
● Demo of OpenShift PaaS running on OpenStack
● Aeolus (CloudForms upstream) adding support for OpenStack
● Heat project – Implementing AWS CloudFormation API on OpenStack
● Red Hat actively hiring for OpenStack in Westford & globally
3 Boston OpenStack User Group 2012

4. Quantum Overview as of Essex
● OpenStack incubation project
● Layer 2 Virtual Networking Service
● Network – Isolated L2 network segment
● Port – point of attachment to Network
● Extensible REST API
● Example V 1.1 API requests on following slides
● Plugins – Implements API with specific virtual networking technology
● openvswitch, linuxbridge, cisco, nicira, ryu
● Agents – execute network commands on compute nodes for certain plugins
● Nova Integration – usable, but limited
● VIF Drivers
● Nova Network Service
● QuantumManager
● Nova or Melange IPAM
4 Boston OpenStack User Group 2012

5. V1.1 API – Create Network
POST /v1.1/tenants/XYZ/networks.json
Request:
{
"network":
{
"name": "test_create_network"
}
}
Response:
{
"network":
{
"id": "158233b0-ca9a-40b4-8614-54a4a99d47d1",
}
}
5 Boston OpenStack User Group 2012

6. V1.1 API – Create Port
POST /v1.1/tenants/XYZ/networks/158233b0-ca9a-40b4-8614-54a4a99d47d1/ports.json
Request:
{
"port":
{
"state": "ACTIVE"
}
}
Response:
{
"port":
{
"id": "98017ddc-efc8-4c25-a915-774b2a633855"
}
}
6 Boston OpenStack User Group 2012

7. V1.1 API – Attach VM Interface
PUT /v1.1/tenants/XYZ/networks/158233b0-ca9a-40b4-8614-54a4a99d47d1
/ports/98017ddc-efc8-4c25-a915-774b2a633855/attachment.json
Request:
{
"attachment":
{
"id": "test_interface_identifier"
}
}
7 Boston OpenStack User Group 2012

8. Quantum in Folsom
● Core project
● May be default networking service for Nova, but legacy NetworkManagers still available
● L3 functionality
● IPAM from Melange
● DHCP, firewall, NAT, ...
● V2 API
● Adds Subnet as top-level resource
● Port becomes top-level resource
● Example requests on following slides
● New client library and CLI
● Authentication and authorization via Keystone
● Tenant_id eliminated from resource URLs
● New Nova integration
● Nova Networking service and QuantumManager eliminated
● Horizon integration
8 Boston OpenStack User Group 2012

9. V2.0 API – Create Network
POST /v2.0/networks
Request:
{
"name" : "net1"
}
Response:
{
"id": "98bd8391-199f-4440-824d-8659e4906786",
"name": "net1",
"admin_state_up": True,
"op_status": "ACTIVE",
"tenant_id": "a4fc5328-c270-4891-845a-e61c9153d261",
"subnets" : [],
}
9 Boston OpenStack User Group 2012

10. V2.0 API – Create Subnet
POST /v2.0/subnets
Request:
{
"network_id": "98bd8391-199f-4440-824d-8659e4906786",
"ip_version": 4,
"cidr": "10.0.0.0/24",
}
Response:
{
"id": "e76a23fe-b028-47b8-a765-858b65c0f857",
"network_id": "98bd8391-199f-4440-824d-8659e4906786",
"ip_version": 4,
"cidr": "10.0.0.0/24",
"gateway_ip": "10.0.0.1",
"dns_nameservers": ["8.8.8.8"],
"reserved_ranges": [ { "start" : "10.0.0.1", "end": "10.0.0.1"},
{"start": "10.0.0.255", "end" : "10.0.0.255"}],
"additional_host_routes": [],
}
10 Boston OpenStack User Group 2012

11. V2.0 API – Create Port with Interface
POST /v2.0/ports
Request:
{
"network_id": "98bd8391-199f-4440-824d-8659e4906786",
"device_id": "32aeb491-4e78-4c24-8ab8-363daa65aa4d",
}
Response:
{
"id": "b08a3807-5d3b-4ab8-95ce-3ed5aa28bdf6",
"network_id": "98bd8391-199f-4440-824d-8659e4906786",
"admin_state_up": True,
"op_status": "ACTIVE",
"mac_address": "ca:fe:de:ad:be:ef",
"fixed_ips": [ "10.0.0.2" ],
"host_routes": [ { "destination": "0.0.0.0/0", "nexthop" : "10.0.0.1" },
{ "destination": "10.0.0.0/24", "nexthop": Null }],
"device_id": "32aeb491-4e78-4c24-8ab8-363daa65aa4d",
}
11 Boston OpenStack User Group 2012

12. Data Center Challenge
● Quantum currently assumes "green-field" cloud
deployment
● Uniform pool of similar compute nodes
● Uniform connectivity
● Tenant networks are completely isolated
● What about Quantum in existing data centers?
● On-premise private OpenStack clouds
● As networking service for "enterprise virtualization"
● Red Hat PoC: Integrate Quantum with oVirt
12 Boston OpenStack User Group 2012

13. Provider Networks
● Problem: How can VMs connect to existing data center networks
using Quantum?
● Solution: provider-networks blueprint for Folsom
● Add “provider” API extension
● Extend create_network operation so admins can specify VLAN tags and/or select
physical network ids via extended parameters
● Provider details visible to admins via GET operations
● Non-admins can use admin-defined provider networks if authorized
● Implement “provider” extension in (at least) linuxbridge and openvswitch
plugins
● Support “flat” (untagged) networks and VLANs
● Support multiple physical network devices with separate VLAN tag spaces
● Map physical network names to node-specific network devices
● Will also need flexibility in layer 3
● e.g. Use existing DHCP server
13 Boston OpenStack User Group 2012

14. V2.0 API – Create Provider Network
POST /v2.0/networks
Request:
{
"name" : "net1_vlan29"
“provider:phys_net”: “phys_net1”
“provider:vlan_id”: 29
}
Response:
{
"id": "98bd8391-199f-4440-824d-8659e4906786",
"name": "net1_vlan29",
"admin_state_up": True,
"op_status": "ACTIVE",
"tenant_id": "a4fc5328-c270-4891-845a-e61c9153d261",
"subnets" : [],
“provider:phys_net”: “phys_net1”
“provider:vlan_id”: 29
}
14 Boston OpenStack User Group 2012

15. Multiple Networking Technologies
● Problem: What if data center includes multiple networking
technologies (Linux bridging, OVS, UCS, VLAN, VXLAN, GRE)?
● Quantum only supports a single plugin
● Several options to consider:
● Use plugin that supports all the technologies you need
● nicira & ryu plugins interface quantum to external virtual network controllers
● Deploy separate quantum service for each technology
● Enhance quantum to support multiple simultaneous plugins
● Meta-plugin that manages multiple standard Quantum plugins
● Modular plugin that uses drivers for different technologies
● Topic for next OpenStack Design Summit
15 Boston OpenStack User Group 2012

16. Non-Uniform Connectivity
● Problem: What if not all compute nodes connect to the
same physical networks?
● Not all virtual networks accessible to VMs on every node
● Virtual networks accessible via different technologies at
different nodes
● Possible approaches:
● Model physical connectivity within Quantum API or API
extension
● Assert equivalence of set of virtual networks
● Tag virtual networks and/or nodes with metadata
representing connectivity zones
●
Nova scheduler plugin aware of nodes' Quantum connectivity
16 Boston OpenStack User Group 2012

17. Deployability
● Scalability
● Current agents periodically poll plugin DB via SQL
● Replacing with openstack-common RPC in Folsom
● Ensure Quantum server can be replicated
● Upgrades
● Support rolling upgrade of servers, nodes
● SLA / QoS
● Port mirroring
● IDS / IPS
● Debugging / Monitoring / Instrumentation
17 Boston OpenStack User Group 2012

18. Summary
● Nova transitioning to use Quantum in Folsom
● Quantum being “completed” with L3 features
● Integrations with Nova, Keystone, Horizon being improved
● Refinements needed for additional data center use cases
● Provider network support coming in Folsom
● Multiple technologies, non-uniform connectivity to be
addressed later
● Deployability improvements ongoing
● Questions?
18 Boston OpenStack User Group 2012

19. Contact Info
● Bob Kukura
● Email: rkukura@redhat.com
● IRC: rkukura on freenode
● OpenStack in Fedora & EPEL
● http://fedoraproject.org/wiki/OpenStack
● http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17
● http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL
● Red Hat Summit and JBoss World – Hynes Convention Center, June 26-29, 2012
● http://www.redhat.com/summit/
● Red Hat OpenStack Jobs
● https://careers-redhat.icims.com/jobs/search?searchKeyword=OpenStack
19 Boston OpenStack User Group 2012