[Yahoo-eng-team] [Bug 1622684] [NEW] Keycode error using novnc and Horizon consloe

2016-09-12 Thread Phil Hopkins
Public bug reported:

When using Newton or Mitaka versons of OpenStack Horizon, I am unable to
talk to the vm in the Horizon console window. I am using noVNC and I see
the following in the console when ever pressing any key on the keyboard:


atkbd serio0: Use 'setkeycodes 00 ' to make it known.
[   41.750245] atkbd serio0: Unknown key released (translated set 2,
code 0x0 on isa0060/serio0).
[   41.750591] atkbd serio0: Use 'setkeycodes 00 ' to make it known.
[   41.815590] atkbd serio0: Unknown key pressed (translated set 2,
code 0x0 on isa0060/serio0).
[   41.816087] atkbd serio0: Use 'setkeycodes 00 ' to make it known.
[   41.945017] atkbd serio0: Unknown key released (translated set 2,
code 0x0 on isa0060/serio0).
[   41.945848] atkbd serio0: Use 'setkeycodes 00 ' to make it known.
[   42.393227] atkbd serio0: Unknown key pressed (translated set 2,
code 0x0 on isa0060/serio0).

This appears to be related to recent code changes in noVNC. If I revert
noVNC to the sha 4e0c36dda708628836dc6f5d68fc40d05c7716d9, everything
works. This sha commit date is August 26, 2016.

Phil

** Affects: horizon
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1622684

Title:
  Keycode error using novnc and Horizon consloe

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When using Newton or Mitaka versons of OpenStack Horizon, I am unable
  to talk to the vm in the Horizon console window. I am using noVNC and
  I see the following in the console when ever pressing any key on the
  keyboard:

  
  atkbd serio0: Use 'setkeycodes 00 ' to make it known.
  [   41.750245] atkbd serio0: Unknown key released (translated set 2,
  code 0x0 on isa0060/serio0).
  [   41.750591] atkbd serio0: Use 'setkeycodes 00 ' to make it known.
  [   41.815590] atkbd serio0: Unknown key pressed (translated set 2,
  code 0x0 on isa0060/serio0).
  [   41.816087] atkbd serio0: Use 'setkeycodes 00 ' to make it known.
  [   41.945017] atkbd serio0: Unknown key released (translated set 2,
  code 0x0 on isa0060/serio0).
  [   41.945848] atkbd serio0: Use 'setkeycodes 00 ' to make it known.
  [   42.393227] atkbd serio0: Unknown key pressed (translated set 2,
  code 0x0 on isa0060/serio0).

  This appears to be related to recent code changes in noVNC. If I
  revert noVNC to the sha 4e0c36dda708628836dc6f5d68fc40d05c7716d9,
  everything works. This sha commit date is August 26, 2016.

  Phil

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1622684/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1559072] [NEW] WebOb 1.6.0 causes nova api problems

2016-03-18 Thread Phil Hopkins
Public bug reported:

Running on Ubuntu 14.04.
After installing nova from source in either the Liberty release or Mitaka, with 
WebOb 1.6.0, running any nova command generated this error:
root@openstack-ubu-controller:~# nova service-list
ERROR (AttributeError): 'unicode' object has no attribute 'get'

The equivalent openstack commands work correctly. After downgrading
WebOb to 1.5.1 AND restarting the nova-api service everything works.

Detailed output from nova -debug service-list with the error:

root@openstack-ubu-controller:~# nova --debug service-list
DEBUG (extension:157) found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
DEBUG (extension:157) found extension EntryPoint.parse('admin_token = 
keystoneauth1.loading._plugins.admin_token:AdminToken')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcauthcode = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAuthorizationCode')
DEBUG (extension:157) found extension EntryPoint.parse('v2password = 
keystoneauth1.loading._plugins.identity.v2:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcpassword = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectPassword')
DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token')
DEBUG (extension:157) found extension EntryPoint.parse('v3token = 
keystoneauth1.loading._plugins.identity.v3:Token')
DEBUG (extension:157) found extension EntryPoint.parse('password = 
keystoneauth1.loading._plugins.identity.generic:Password')
DEBUG (session:248) REQ: curl -g -i -X GET http://10.0.1.3:5000/v2.0 -H 
"Accept: application/json" -H "User-Agent: keystoneauth1/2.3.0 
python-requests/2.9.1 CPython/2.7.6"
INFO (connectionpool:207) Starting new HTTP connection (1): 10.0.1.3
DEBUG (connectionpool:387) "GET /v2.0 HTTP/1.1" 200 334
DEBUG (session:277) RESP: [200] Content-Length: 334 Vary: X-Auth-Token 
Keep-Alive: timeout=5, max=100 Server: Apache/2.4.7 (Ubuntu) Connection: 
Keep-Alive Date: Fri, 18 Mar 2016 12:41:58 GMT Content-Type: application/json 
x-openstack-request-id: req-a0c68cd5-ea29-4391-942f-130cc69d15f8 
RESP BODY: {"version": {"status": "stable", "updated": "2014-04-17T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links": 
[{"href": "http://10.0.1.3:5000/v2.0/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}]}}

DEBUG (v2:63) Making authentication request to http://10.0.1.3:5000/v2.0/tokens
DEBUG (connectionpool:387) "POST /v2.0/tokens HTTP/1.1" 200 2465
DEBUG (session:248) REQ: curl -g -i -X GET 
http://10.0.1.3:8774/v1.1/b77d640e127e488fb42a7c0716ba53a5 -H "User-Agent: 
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}381893576ad46c62b587f4963d769b89441b919a"
INFO (connectionpool:207) Starting new HTTP connection (1): 10.0.1.3
DEBUG (connectionpool:387) "GET /v1.1/b77d640e127e488fb42a7c0716ba53a5 
HTTP/1.1" 404 112
DEBUG (session:277) RESP: [404] Date: Fri, 18 Mar 2016 12:41:59 GMT Connection: 
keep-alive Content-Type: application/json; charset=UTF-8 Content-Length: 112 
X-Compute-Request-Id: req-f10a2016-9a88-48fd-af1d-5f800fc9e11a 
RESP BODY: {"message": "The resource could not be found.\n\n\n", 
"code": "404 Not Found", "title": "Not Found"}

DEBUG (shell:894) 'unicode' object has no attribute 'get'
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/novaclient/shell.py", line 892, 
in main
OpenStackComputeShell().main(argv)
  File "/usr/local/lib/python2.7/dist-packages/novaclient/shell.py", line 726, 
in main
api_version = api_versions.discover_version(self.cs, api_version)
  File "/usr/local/lib/python2.7/dist-packages/novaclient/api_versions.py", 
line 267, in discover_version
client)
  File "/usr/local/lib/python2.7/dist-packages/novaclient/api_versions.py", 
line 248, in _get_server_version_range
version = client.versions.get_current()
  File "/usr/local/lib/python2.7/dist-packages/novaclient/v2/versions.py", line 
83, in get_current
return self._get_current()
  File "/usr/local/lib/python2.7/dist-packages/novaclient/v2/versions.py", line 
57, in _get_current
return self._get(url, "version")
  File "/usr/local/lib/python2.7/dist-packages/novaclient/base.py", line 297, 
in _get
_resp, body = self.api.client.get(url)
  File "/usr/local/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 
173, in get
return self.request(url, 'GET', **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/novaclient/client.py", line 92, 
in request
raise exceptions.from_response(resp, body, url, method)
  File "/usr/local/lib/python2.7/dist-packages/novaclient/exceptions.py", line 
274, in from_response
message = 

[Yahoo-eng-team] [Bug 1459816] [NEW] update sample_data script to use openstack commands

2015-05-28 Thread Phil Hopkins
Public bug reported:

The sample data script is genterating warnings since the keystone
commands are depricated. The script needs to be updated to use the new
openstack commands.

** Affects: keystone
 Importance: Undecided
 Assignee: Phil Hopkins (phil-hopkins-a)
 Status: In Progress

** Changed in: keystone
 Assignee: (unassigned) = Phil Hopkins (phil-hopkins-a)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1459816

Title:
  update sample_data script to use openstack commands

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  The sample data script is genterating warnings since the keystone
  commands are depricated. The script needs to be updated to use the new
  openstack commands.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1459816/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1411807] Re: linuxbridge using mulicast vxlan w/o l2pop fails

2015-01-19 Thread Phil Hopkins
Thanks Darragh, that is the problem. I am closing the bug. If anyone see
this check out the bug that Darragh referenced above.

The packets coming from the DHCP server donot have a correct shecksum
and are being droped as they cross the bridge. Adding a magle rule to
add the checksum or ignore it fixes everything.

** Changed in: neutron
   Status: New = Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1411807

Title:
  linuxbridge using mulicast vxlan w/o l2pop fails

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  I am running Ubuntu 14.04 with a source Juno install updated as of
  yesterday. I have two network nodes and two compute nodes. When a VM
  is booted the broadcast DHCP request goes out and is received by the
  network node dnsmasq process. The unicast DHCP response is sent and is
  received by the compute node. It can be captured on the vxlan and
  Linux bridge interfaces but is never forwarded to the VM's tap
  interface which is on the bridge..

  
  tcpdump on VM's tap interface. DHCP requests go out but the reply is never 
forwarded to the VM:

  root@compute:~# tcpdump -e -n -vv -i tapde7ffb39-b7
  tcpdump: WARNING: tapde7ffb39-b7: no IPv4 address assigned
  tcpdump: listening on tapde7ffb39-b7, link-type EN10MB (Ethernet), capture 
size 65535 bytes

  16:18:54.614728 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP 
(17), length 315)
  0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
Client-Ethernet-Address fa:16:3e:32:93:95
Vendor-rfc1048 Extensions
  Magic Cookie 0x63825363
  DHCP-Message Option 53, length 1: Discover
  Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
  MSZ Option 57, length 2: 576
  Parameter-Request Option 55, length 9: 
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, MTU, BR, NTP
Classless-Static-Route
  Vendor-Class Option 60, length 12: udhcp 1.20.1
  Hostname Option 12, length 3: one
  16:18:54.615002 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP 
(17), length 315)
  0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
Client-Ethernet-Address fa:16:3e:32:93:95
Vendor-rfc1048 Extensions
  Magic Cookie 0x63825363
  DHCP-Message Option 53, length 1: Discover
  Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
  MSZ Option 57, length 2: 576
  Parameter-Request Option 55, length 9: 
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, MTU, BR, NTP
Classless-Static-Route
  Vendor-Class Option 60, length 12: udhcp 1.20.1
  Hostname Option 12, length 3: one
  16:18:55.066473 fa:16:3e:32:93:95  33:33:ff:32:93:95, ethertype IPv6 
(0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) :: 
 ff02::1:ff32:9395: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, 
who has fe80::f816:3eff:fe32:9395

  tcpdump on the that has both the VM's tap interface and the ethernet
  vxlan sub-interface. DHCP request goes out and the DHCP reply comes
  back but is not forwarded to the tap interface:

  root@compute:~# tcpdump -e -n -vv -i brq475b2aeb-b5
  tcpdump: WARNING: brq475b2aeb-b5: no IPv4 address assigned
  16:18:54.614728 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP 
(17), length 315)
  0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
Client-Ethernet-Address fa:16:3e:32:93:95
Vendor-rfc1048 Extensions
  Magic Cookie 0x63825363
  DHCP-Message Option 53, length 1: Discover
  Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
  MSZ Option 57, length 2: 576
  Parameter-Request Option 55, length 9: 
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, MTU, BR, NTP
Classless-Static-Route
  Vendor-Class Option 60, length 12: udhcp 1.20.1
  Hostname Option 12, length 3: one
  16:18:54.614983 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 
(0x0800), length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP 
(17), length 315)
   

[Yahoo-eng-team] [Bug 1411807] [NEW] linuxbridge using mulicast vxlan w/o l2pop fails

2015-01-16 Thread Phil Hopkins
Public bug reported:

I am running Ubuntu 14.04 with a source Juno install updated as of
yesterday. I have two network nodes and two compute nodes. When a VM is
booted the broadcast DHCP request goes out and is received by the
network node dnsmasq process. The unicast DHCP response is sent and is
received by the compute node. It can be captured on the vxlan and Linux
bridge interfaces but is never forwarded to the VM's tap interface which
is on the bridge..


tcpdump on VM's tap interface. DHCP requests go out but the reply is never 
forwarded to the VM:

root@compute:~# tcpdump -e -n -vv -i tapde7ffb39-b7
tcpdump: WARNING: tapde7ffb39-b7: no IPv4 address assigned
tcpdump: listening on tapde7ffb39-b7, link-type EN10MB (Ethernet), capture size 
65535 bytes

16:18:54.614728 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), 
length 315)
0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
  Client-Ethernet-Address fa:16:3e:32:93:95
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 9: 
  Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
  Domain-Name, MTU, BR, NTP
  Classless-Static-Route
Vendor-Class Option 60, length 12: udhcp 1.20.1
Hostname Option 12, length 3: one
16:18:54.615002 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), 
length 315)
0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
  Client-Ethernet-Address fa:16:3e:32:93:95
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 9: 
  Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
  Domain-Name, MTU, BR, NTP
  Classless-Static-Route
Vendor-Class Option 60, length 12: udhcp 1.20.1
Hostname Option 12, length 3: one
16:18:55.066473 fa:16:3e:32:93:95  33:33:ff:32:93:95, ethertype IPv6 (0x86dd), 
length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) ::  
ff02::1:ff32:9395: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who 
has fe80::f816:3eff:fe32:9395

tcpdump on the that has both the VM's tap interface and the ethernet
vxlan sub-interface. DHCP request goes out and the DHCP reply comes back
but is not forwarded to the tap interface:

root@compute:~# tcpdump -e -n -vv -i brq475b2aeb-b5
tcpdump: WARNING: brq475b2aeb-b5: no IPv4 address assigned
16:18:54.614728 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), 
length 315)
0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
  Client-Ethernet-Address fa:16:3e:32:93:95
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 9: 
  Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
  Domain-Name, MTU, BR, NTP
  Classless-Static-Route
Vendor-Class Option 60, length 12: udhcp 1.20.1
Hostname Option 12, length 3: one
16:18:54.614983 fa:16:3e:32:93:95  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), 
length 329: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), 
length 315)
0.0.0.0.68  255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 
fa:16:3e:32:93:95, length 287, xid 0x8c595e0b, Flags [none] (0x)
  Client-Ethernet-Address fa:16:3e:32:93:95
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether fa:16:3e:32:93:95
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 9: 
  Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
  Domain-Name, MTU, BR, NTP
  Classless-Static-Route
Vendor-Class Option 60, length 12: udhcp 1.20.1
Hostname Option 12, length 3: one
16:18:54.615946 fa:16:3e:e3:35:28  

[Yahoo-eng-team] [Bug 1377280] [NEW] Adding gateway to flat externat network breaks HA routers

2014-10-03 Thread Phil Hopkins
Public bug reported:

I am running Juno on Ubuntu 14.04. OpenStack is installed from source
and updated to the latest this morning. I am trying to build HA routers
using VXLAN tunnels. When I set up my external network as a VXXLAN
network type everything works properly. If I delete the VXLAN based
external network as the gateway to this network and change the external
network to a flat network by adding the flat network as the gateway
everything with the qrouter namespace disappears except for the lo
interface.

Here is my ml2_conf.ini file:
[ml2]
type_drivers = vxlan,flat
tenant_network_types = vxlan,flat
mechanism_drivers = linuxbridge,l2population
[ml2_type_flat]
flat_networks = physnet1
[ml2_type_vlan]
[ml2_type_gre]
[ml2_type_vxlan]
vni_ranges = 100:200
vxlan_group = 224.0.0.1
[securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
enable_security_group = True
[agent]
l2population = True
tunnel_type = vxlan
[linuxbridge]
physical_interface_mappings = physnet1:vethOVS
[l2pop]
agent_boot_time = 180
[vxlan]
enable_vxlan = True
vxlan_group = 224.0.0.1
local_ip = 10.0.2.5
l2_population = True


contents of the qrouter namespace with external VXLAN network:
root@network:~# ip netns exec qrouter-5e9b2a5f-4431-48a0-ad31-a46c987506cf ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: ha-9c3955a7-32: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:10:4d:61 brd ff:ff:ff:ff:ff:ff
inet 169.254.192.12/18 brd 169.254.255.255 scope global ha-9c3955a7-32
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe10:4d61/64 scope link 
   valid_lft forever preferred_lft forever
3: qr-88c5895b-17: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:6d:54:62 brd ff:ff:ff:ff:ff:ff
inet 10.2.0.1/28 scope global qr-88c5895b-17
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe6d:5462/64 scope link 
   valid_lft forever preferred_lft forever
4: qr-b4a07ce5-34: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:ae:b8:65 brd ff:ff:ff:ff:ff:ff
inet 10.1.0.1/28 scope global qr-b4a07ce5-34
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:feae:b865/64 scope link 
   valid_lft forever preferred_lft forever
5: qg-f454eff8-ea: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:37:3e:a9 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.32/24 scope global qg-f454eff8-ea
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe37:3ea9/64 scope link 
   valid_lft forever preferred_lft forever

after removing the router gateway:
root@network:~# ip netns exec qrouter-a423edc7-5e12-4c15-a4eb-989c73cdb704 ip a
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: ha-87269710-52: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:00:b6:9d brd ff:ff:ff:ff:ff:ff
inet 169.254.192.14/18 brd 169.254.255.255 scope global ha-87269710-52
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe00:b69d/64 scope link 
   valid_lft forever preferred_lft forever
3: qr-dc345670-13: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:13:2b:52 brd ff:ff:ff:ff:ff:ff
inet6 fe80::f816:3eff:fe13:2b52/64 scope link 
   valid_lft forever preferred_lft forever
4: qr-bfe17de0-2c: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast 
state UP group default qlen 1000
link/ether fa:16:3e:04:ef:91 brd ff:ff:ff:ff:ff:ff
inet6 fe80::f816:3eff:fe04:ef91/64 scope link 
   valid_lft forever preferred_lft forever

Everything looks good up to this point.

Building the following external network:
root@controller:~# neutron router-create MyRouter1 --distributed False --ha True
Created a new router:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| distributed   | False|
| external_gateway_info |  |
| ha| True  

[Yahoo-eng-team] [Bug 1303998] [NEW] vm fails with error vif_type=binding_failed using gre tunnels

2014-04-07 Thread Phil Hopkins
Public bug reported:

I am running Icehouse r-1 on Ubuntu 12.04. Whenever I try to launch a VM
it immediately goes into error state. The log file fo rnova-compute
shows the following:

 http_log_req /usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:173
2014-04-07 19:15:32.888 2866 DEBUG neutronclient.client [-] RESP:{'date': 'Mon, 
07 Apr 2014 19:15:32 GMT', 'status': '204', 'content-length
': '0', 'x-openstack-request-id': 'req-92a58024-6cd6-4ef3-bd81-f579bd057445'} 
 http_log_resp 
/usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:179
2014-04-07 19:15:32.888 2866 DEBUG nova.network.api 
[req-48a2dbdd-7067-4c48-8c09-62d604160d59 b90c0e0ca1aa4cd79703c50e1ff8684a 
f1c5b087cd9e
412daf2360c0cf83a5c6] Updating cache with info: [] 
update_instance_cache_with_nw_info 
/usr/lib/python2.7/dist-packages/nova/network/api.py:
74
2014-04-07 19:15:32.909 2866 ERROR nova.compute.manager 
[req-48a2dbdd-7067-4c48-8c09-62d604160d59 b90c0e0ca1aa4cd79703c50e1ff8684a 
f1c5b087
cd9e412daf2360c0cf83a5c6] [instance: a85f771d-13d2-4cba-88f6-6c26a5cc7f37] 
Error: Unexpected vif_type=binding_failed


--snip--

2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher   File 
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py, line 858, in 
unplug_vifs
2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
self.vif_driver.unplug(instance, vif)
2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher   File 
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py, line 798, in unplug
2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
_(Unexpected vif_type=%s) % vif_type)
2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher NovaException: 
Unexpected vif_type=binding_failed
2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
2014-04-07 19:15:33.221 2866 ERROR oslo.messaging._drivers.common [-] Returning 
exception Unexpected vif_type=binding_failed to caller
2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
2014-04-07 19:15:33.221 2866 ERROR oslo.messaging._drivers.common [-] Returning 
exception Unexpected vif_type=binding_failed to caller

full log file for nova-compute at: http://paste.openstack.org/show/75244/
Log file for /var/log/neutron/openvswitch-agent.log is at: 
http://paste.openstack.org/show/75245/

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1303998

Title:
  vm fails with error vif_type=binding_failed using gre tunnels

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  I am running Icehouse r-1 on Ubuntu 12.04. Whenever I try to launch a
  VM it immediately goes into error state. The log file fo rnova-compute
  shows the following:

   http_log_req 
/usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:173
  2014-04-07 19:15:32.888 2866 DEBUG neutronclient.client [-] RESP:{'date': 
'Mon, 07 Apr 2014 19:15:32 GMT', 'status': '204', 'content-length
  ': '0', 'x-openstack-request-id': 'req-92a58024-6cd6-4ef3-bd81-f579bd057445'} 
   http_log_resp 
/usr/lib/python2.7/dist-packages/neutronclient/common/utils.py:179
  2014-04-07 19:15:32.888 2866 DEBUG nova.network.api 
[req-48a2dbdd-7067-4c48-8c09-62d604160d59 b90c0e0ca1aa4cd79703c50e1ff8684a 
f1c5b087cd9e
  412daf2360c0cf83a5c6] Updating cache with info: [] 
update_instance_cache_with_nw_info 
/usr/lib/python2.7/dist-packages/nova/network/api.py:
  74
  2014-04-07 19:15:32.909 2866 ERROR nova.compute.manager 
[req-48a2dbdd-7067-4c48-8c09-62d604160d59 b90c0e0ca1aa4cd79703c50e1ff8684a 
f1c5b087
  cd9e412daf2360c0cf83a5c6] [instance: a85f771d-13d2-4cba-88f6-6c26a5cc7f37] 
Error: Unexpected vif_type=binding_failed

  
  --snip--

  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher   File 
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py, line 858, in 
unplug_vifs
  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
self.vif_driver.unplug(instance, vif)
  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher   File 
/usr/lib/python2.7/dist-packages/nova/virt/libvirt/vif.py, line 798, in unplug
  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
_(Unexpected vif_type=%s) % vif_type)
  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
NovaException: Unexpected vif_type=binding_failed
  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
  2014-04-07 19:15:33.221 2866 ERROR oslo.messaging._drivers.common [-] 
Returning exception Unexpected vif_type=binding_failed to caller
  2014-04-07 19:15:33.218 2866 TRACE oslo.messaging.rpc.dispatcher 
  2014-04-07 19:15:33.221 2866 ERROR oslo.messaging._drivers.common [-] 
Returning exception Unexpected vif_type=binding_failed to caller

  full log file for nova-compute at: