Error: No nw_info cache associated with instance (HTTP 400)

[Karandeep Singh Johar]

while associating floating-ip it gave errors
Error: No nw_info cache associated with instance (HTTP 400) (Request-ID: req-746ca660-bc26-4fb8-bcd7-461b9bb6d68d)
Error: Unable to associate IP address 192.168.255.1.

[Joe Gordon (jogo)]

How can we reproduce this bug? What version are you using?

[Karandeep Singh Johar (kdjohar91)]

2015.1

[Joel Brandenburg (joelsbrandenburg)]

We have seen two causes of this particular error in the past:
1) If you attempt to associate a floating IP before the Nova instance has completed building
2) If you attempt to associate a floating IP if the instance had issues during build (would be evident in the console log)
3) If you are using Neutron as well and you don't have a properly setup network associated with the instance, which would include:
a) Neutron Router
b) Network Network and Subnet

Just some things to look at and consider.

[Markus Zoeller (markus_z) (mzoeller)]

@Karandeep Singh Johar (kdjohar91):
Reminder: Could you please check if the information Joel Brandenburg (joelsbrandenburg) provided in comment #3 helps you to narrow down the root cause? Please also provide some steps how this bug can be reproduced as asked by Joe Gordon (jogo) in comment #1. Please change the status to "New" when you provided the requested information.

If you are already working on a patch for this bug, please change the bug status to "in progress" and set yourself as assignee.

[Launchpad Janitor (janitor)]

[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.]

[Meni Hillel (meni-hillel)]

We're seeing the same issue multiple times. It is relatively easy to reproduce. Please let me know if I can provide any information needed to help fix this issue ASAP.

[Sumant Murke (sumant-murke)]

Hey Meni Hillel,

Could you please provide some more information like ways to produce the bug and if possible different scenarios where you were facing similar issues.

Thanks !

[Simonas Kareiva (simonask)]

We encounter the problem using the below kitchen.yml configuration (although it seems that you would want to dive into more detailed neutron configuration examples?):

driver:
  name: openstack
  openstack_username: <%= ENV['OS_USERNAME'] %>
  openstack_tenant: <%= ENV['OS_TENANT_NAME'] %>
  openstack_api_key: <%= ENV['OS_PASSWORD'] %>
  openstack_auth_url: <%= "#{ENV['OS_AUTH_URL']}/tokens" %>
  availability_zone: Z1
  require_chef_omnibus: true
  network_ref: kitchen-net
  floating_ip_pool: ext-net
  image_ref: Ubuntu 14.04
  disable_ssl_validation: true
  flavor_ref: m1.kitchen
  username: ubuntu

platforms:
  - name: ubuntu-14.04

After `kitchen create`, from the users perspective it goes like this:

-----> Creating <default-ubuntu-1404>...
       OpenStack instance with ID of <195775bb-8c50-4bfd-83fb-f3e164daa152> is ready.
       Attaching floating IP from <ext-net> pool
       Attaching floating IP <1.2.3.4>
>>>>>> Create failed on instance <default-ubuntu-1404>.
>>>>>> Please see .kitchen/logs/default-ubuntu-1404.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Expected([200, 202]) <=> Actual(400 Bad Request)
excon.error.response
  :body => "{\"badRequest\": {\"message\": \"No nw_info cache associated with instance\", \"code\": 400}}"
  :headers => {
    "Content-Length" => "85"
    "Content-Type" => "application/json; charset=UTF-8"
    "Date" => "Sat, 05 Dec 2015 12:28:34 GMT"
    "X-Compute-Request-Id" => "req-ca32ce40-9450-41d1-a26e-8db22eadb4f5"
  }
  :local_address => "1.2.3.5"
  :local_port => 41784
  :reason_phrase => "Bad Request"
  :remote_ip => "1.2.3.6"
  :status => 400
  :status_line => "HTTP/1.1 400 Bad Request\r\n"

>>>>>> ----------------------

Will provide more neutron plumbing details later.

[Xav Paice (xavpaice)]

https://bugs.launchpad.net/nova/+bug/1249065 looks very similar to this - is it a duplicate?

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY