Horizon quantum-integration-grizzly

  • 600 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
600
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Horizon Quantum Integration Akihiro Motoki, NEC (from Quantum team) 2012/10/18 1
  • 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
  • 6. def get_floating_ips_data(self): try: floating_ips = api.tenant_floating_ip_list(self.request) except: …def get_floating_ips_data(self): try: if is_service_available(‘network’): floating_ips = quantum_api.list_floatingips(self.request) else: floating_ips = nova_api.tenant_floating_ip_list(self.request) except: … 6
  • 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
  • 10. [Demo] L3 support in Horizon• (Nachi) 10
  • 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