2. Agenda
• Folsom Status Review and Gaps
• Considerations:
– vNIC ordering issue
– Using Quantum API directly for floating IP/secgroup
• Demo of Quantum L3 (router) implementation
[nachi]
• LBaaS Integration [LBaaS team]
• Grizzly feature scheduling draft
• Open Discussion
2
3. Folsom Status Review
• First support for Quantum
• Supported Features:
– Network panels for project and admin dashboards
– CRUD for network/subnet/port
– Public network support
– Launching an instance with specified networks
3
4. Gaps between Quantum and Horizon support
• There are gaps in features between Quantum and Horizon
support.
– L3 (router)
– Floating IP
– Provider networks
– Network quotas
– admin_state control
– Cannot display some useful fields
• device_owner for port
• router_external for network
• host_router, dnsservers for subnet
– Security Group (coming soon)
• Supporting them is a first milestone of Grizzly.
4
5. Using Quantum API directly
• To support floating IP and security group, there are two options: Nova API
and Quantum API.
– Using Nova API
• nova proxies calls for floating IP to Quantum.
• Cannot support IP overlapping. IP address must be unique among tenants.
– Using Quantum API
• Horizon talks to Quantum to manage floating IP.
• Can leverage full quantum features like overlapping IPs.
• I believe it is reasonable to shift to Quantum API if Quantum enabled.
• On the other hand, Horizon needs to support legacy network models (Flat,
FlatDHCP, VLAN).
– Floating IP is managed via Nova API for legacy network models.
• There needs a way to select an appropriate API to be used.
– Use quantum API if ‘network’ service (quantum) is enabled,
– Use nova API otherwise.
5
7. Specifying VNIC order in launching a VM
• VNIC ordering is important. Without it we cannot map a specific VNIC to a
specific network.
– Someone wants to connect eth0 to the management network and eth1 to the
service network.
• When using “nova” command, we can specify the order of NICs.
– nova boot --nic net-id=<net1> --nic net-id=<net2> --nic net-id=<net3>
– In the VM launched , we can see:
eth0 => net1, eth1 => net2, eth2 => net3
• In Horizon:
– Can select networks which an VM connects to,
– But can not specify VNIC ordering in a VM
– The order of VNIC depends on the order of network list returned by Quantum
API.
• To enable to specify VNIC ordering, we need a new “ChoiceField”(?)
– With forms.MultipleChoiceField, we can just select elements of a list.
– Need a way to select elements of a list with ordering.
– What is the right way to support it?
7
8. eth0
eth1
eth2
We cannot control VNIC ordering in a VM.
8
9. Other topics
• Displays networking quotas:
– Adds quota menu in network creation,
– Show quota retrieved from Quantum (in Floating IP allocation menu).
• Support ‘provider network’
– Quantum ‘provider network’ extension defined additional attributes to
control underlying networks
• network_type, physical_network, segmentation_id
– In Horizon support, we need to determine the corresponding
extension (‘provider’) is enabled or not.
• “ext-list” API returns a list of enabled extensions.
• Pagenation
– (expected to be discussed as general topics)
– It is useful when the number of quantum networks increases.
– Quantum API support is required (to support it).
9
11. Grizzly schedule draft (Quantum related)
• G-1
– Supports non-exposed features in Quantum Folsom.
– L3, Floating IP (with nova proxy)
• G-2
– Floating IP/Security Group support using Quantum API directly
• According to our experience in Folsom, it is reasonable that
features added to Quantum are supported in Horizon in the next
milestone.
• LBaaS : ? (needs to be discussed with LBaaS team)
Folsom G-1 G-2 G-3 G-rc1
Quantum
?
Horizon G-1 G-2 G-3 G-rc1
11