Charm needed: Openstack Quantum

Bug #1079782 reported by James Page
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Juju Charms Collection
Fix Released
High
James Page

Bug Description

We need to support Quantum SDN for Openstack; I'm writing this one.

Related branches

James Page (james-page)
Changed in charms:
assignee: nobody → James Page (james-page)
status: New → In Progress
Revision history for this message
James Page (james-page) wrote :

Quantum-gateway charm tested and ready for review as well.

Changed in charms:
importance: Undecided → High
status: In Progress → New
Revision history for this message
Adam Gandelman (gandelman-a) wrote :

James-

Finally got a chance to deploying all of this at once. I know the quantum charm is targeted toward quantal, but I'd really like to have a charm that can deploy this stuff to Precise via the cloud archive, as well. Trying to deploy this to 12.04, I found the use of python-dnspython is problematic. The following snippet works fine on 12.10 but raises socket.error on 12.04:

#!/usr/bin/python
import dns.resolver
import dns.ipv4
hostname='www.ubuntu.com'
try:
  # Test to see if already an IPv4 address
  dns.ipv4.inet_aton(hostname)
  print hostname
except dns.exception.SyntaxError:
  try:
    answers = dns.resolver.query(hostname, 'A')
    if answers:
      print answers[0].address
  except dns.resolver.NXDOMAIN:
    pass

On 12.04, it bails with "socket.error: illegal IP address string passed to inet_aton". Also, the nova-compute charm doesn't verify the output of get_ip, so the hooks that call get_ip() continue to execute without invalid configuration. I wonder if something more standardcould be used instead:

import socket
hostname='www.ubuntu.com'
try:
    print socket.gethostbyname(hostname)
except socket.gaierror:
    pass

Aside form that, the quantum integration seems work okay from Juju's POV. After deployed, I tried creating networks and launching instances. I can get instances to spin up with fixed IPs associated, but the instances are having trouble picking up its metadata. I'm not certain config drive is working correctly, or perhaps I've forgotten a step. I'll sync up with you tomorrow and get some pointers on that.

Revision history for this message
James Page (james-page) wrote :

Hi Adam

socket.gethostbyname(hostname) works OK so long as /etc/hosts does not contain:

127.0.1.1 hostname.domainname hostname

In which case 127.0.1.1 is returned; which is not desirable.

I've continually come up against this challenge using Juju with providers that return a hostname rather than an IP address for `private-address`.

dig +short hostname works OK so long as hostname is a direct A record; if its a CNAME it breaks; I'll give this all another round of thinking and see what other approaches might be taken.

Thanks for the reviews....

Changed in charms:
status: New → In Progress
Revision history for this message
James Page (james-page) wrote :

Seems that the MaaS provider enables the 'manage_etc_hosts' by default for the machines it manages.

Revision history for this message
James Page (james-page) wrote :

Raised a bug for this against MaaS; I'm sure there are good reasons for doing it but it makes the MaaS provider work in a different way to other providers; bug 1087183

Revision history for this message
James Page (james-page) wrote :

Adam

Config Drive is only supported from Quantal onwards; this feels really awkward and does limit quantum's usefulness in Folsom IMHO.

Its possible todo some really horrid network hacks with routing to make it work but its not charmable.

James Page (james-page)
Changed in charms:
status: In Progress → New
Revision history for this message
Adam Gandelman (gandelman-a) wrote :

I've merged the supporting changes to nova-compute and nova-cloud-controller. The workaround you added to get_ip() in nova-c-c worked to avoid the backward compat. issue on 12.04, but the same fix wasn't added to the similar code in quantum. Other than that, I think the quantum charm is in good shape to be added to the charm store.

I've been able to deploy quantum alongside the rest of it, and get an instance spun up with both private and floating IPs. I'm having some trouble SSH'ing to the instances (the quantal guests still seem not to get the SSH keys), but network connectivity is working fine .

Revision history for this message
James Page (james-page) wrote :

Adam; I think that you probably did not supply a DNS server when creating the tenant network.

quantum-gateway charm promulgated to precise (with default of folsom cloud archive) and quantal

Changed in charms:
status: New → Fix Released
Revision history for this message
Adam Israel (aisrael) wrote :

This bug is in the review queue because the author was the last to comment. A non author comment removes this Fix Released bug from the review queue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.