nova client sends floating IP call to wrong node

[Lars Erik Pedersen]

When I try to assign a floating IP to an instance, I have to run the command several time before it actually manage to send the call to the network-node who actually has info about the instance. In my setup I currently have one controller and two compute notes. I'm running multi_host, so every compute-node is running nova-network and nova-api as well. As of now it's quite consistent that I have to run the command three times before it will succeed. The first time it's sent to the wrong node, and the log prints

DEBUG nova.utils [-] Attempting to grab semaphore "get_dhcp" for method "_get_dhcp_ip"... from (pid=8991) inner /usr/lib/python2.7/dist-packages/nova/utils.py:675

The second time, it's sent to the right node, but I get the same log as above. Finally the third time, it works as it should.

When it fail I must kill the command with ctrl+c and I get this traceback:

nova add-floating-ip 142 192.168.10.132
^CTraceback (most recent call last):
  File "/usr/bin/nova", line 9, in <module>
    load_entry_point('python-novaclient==2012.1', 'console_scripts', 'nova')()
  File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 353, in main
    OpenStackComputeShell().main(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/novaclient/shell.py", line 304, in main
    args.func(self.cs, args)
  File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/shell.py", line 974, in do_add_floating_ip
    server.add_floating_ip(args.address)
  File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/servers.py", line 72, in add_floating_ip
    self.manager.add_floating_ip(self, address)
  File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/servers.py", line 276, in add_floating_ip
    self._action('addFloatingIp', server, {'address': address})
  File "/usr/lib/python2.7/dist-packages/novaclient/v1_1/servers.py", line 538, in _action
    return self.api.client.post(url, body={action: info})
  File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 133, in post
    return self._cs_request(url, 'POST', **kwargs)
  File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 118, in _cs_request
    **kwargs)
  File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 88, in request
    resp, body = super(HTTPClient, self).request(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1444, in request
    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
  File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1196, in _request
    (response, content) = self._conn_request(conn, request_uri, method, body, headers)
  File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1166, in _conn_request
    response = conn.getresponse()
  File "/usr/lib/python2.7/httplib.py", line 1027, in getresponse
    response.begin()
  File "/usr/lib/python2.7/httplib.py", line 407, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python2.7/httplib.py", line 365, in _read_status
    line = self.fp.readline()
  File "/usr/lib/python2.7/socket.py", line 430, in readline
    data = recv(1)

[Vish Ishaya (vishvananda)]

Are you sure that mult_host is true on the network? This works correctly in essex. The code has moved, but I don't see anything that would cause this to occur in the diablo code unless multi_host isn't set.

[Lars Erik Pedersen (pedersen-larserik)]

Yes, the --multi_host=True are set, so it can't be that causing this trouble.

[Thierry Carrez (ttx)]

Marking invalid for Essex, opening an incomplete Diablo task