Charm needed: Openstack Quantum

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

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.

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....

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

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

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.

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 .

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

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.