[Yahoo-eng-team] [Bug 1595043] [NEW] Make DVR portbinding implementation useful for HA ports

2016-06-21 Thread venkata anil
Public bug reported:

Make DVR portbinding implementation generic so that it will be useful
for all distributed router ports(for example, HA router ports).

Currently HA interface port binding is implemented as a normal port
binding i.e it uses only ml2_port_bindings table, with host set to
master host. When a new host becomes master, this binding will be
updated. But this approach has issues as explained in
https://bugs.launchpad.net/neutron/+bug/1522980

As HA router ports(DEVICE_OWNER_HA_REPLICATED_INT, DEVICE_OWNER_ROUTER_SNAT for 
DVR+HA) are distributed ports like DVR, we will follow DVR approach of port 
binding for HA router ports.
So we make DVR port binding generic, so that it can be used for all distributed 
router ports.

To make DVR port binding generic for all distributed router ports, we need to
1) rename ml2_dvr_port_bindings table to ml2_distributed_port_bindings 
2) rename functions updating/accessing this table
3) Replace 'if condition' for dvr port with distributed port, for example, 
replace
   if port['device_owner'] == const.DEVICE_OWNER_DVR_INTERFACE:
  with
   if distributed_router_port(port):

** Affects: neutron
 Importance: Undecided
 Assignee: venkata anil (anil-venkata)
 Status: In Progress


** Tags: l2-pop l3-dvr-backlog l3-ha

** Changed in: neutron
 Assignee: (unassigned) => venkata anil (anil-venkata)

** Tags added: l3-dvr-backlog

** Tags added: l2-pop l3-ha

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

Title:
  Make DVR portbinding implementation useful for HA ports

Status in neutron:
  In Progress

Bug description:
  Make DVR portbinding implementation generic so that it will be useful
  for all distributed router ports(for example, HA router ports).

  Currently HA interface port binding is implemented as a normal port
  binding i.e it uses only ml2_port_bindings table, with host set to
  master host. When a new host becomes master, this binding will be
  updated. But this approach has issues as explained in
  https://bugs.launchpad.net/neutron/+bug/1522980

  As HA router ports(DEVICE_OWNER_HA_REPLICATED_INT, DEVICE_OWNER_ROUTER_SNAT 
for DVR+HA) are distributed ports like DVR, we will follow DVR approach of port 
binding for HA router ports.
  So we make DVR port binding generic, so that it can be used for all 
distributed router ports.

  To make DVR port binding generic for all distributed router ports, we need to
  1) rename ml2_dvr_port_bindings table to ml2_distributed_port_bindings 
  2) rename functions updating/accessing this table
  3) Replace 'if condition' for dvr port with distributed port, for example, 
replace
 if port['device_owner'] == const.DEVICE_OWNER_DVR_INTERFACE:
with
 if distributed_router_port(port):

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1595043/+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 1589434] Re: ROUTER_INTERFACE/BEFORE_DELETE event should provide router-id

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/325795
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=75ae15365762e477fb6084bdbf29e41ad2c3b414
Submitter: Jenkins
Branch:master

commit 75ae15365762e477fb6084bdbf29e41ad2c3b414
Author: YAMAMOTO Takashi 
Date:   Mon Jun 6 18:41:45 2016 +0900

Provide router-id for ROUTER_INTERFACE/BEFORE_DELETE event

Closes-Bug: #1589434
Change-Id: I31f65b40c83f03c4e4b71a799aaea0359b992279


** Changed in: neutron
   Status: In Progress => Fix Released

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

Title:
  ROUTER_INTERFACE/BEFORE_DELETE event should provide router-id

Status in neutron:
  Fix Released

Bug description:
  there's a use case:
  
https://review.openstack.org/#/c/325713/7/midonet/neutron/services/l3/l3_midonet.py@349

  anyway a router related event which doesn't provide router-id seems
  weird.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1589434/+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 1595041] [NEW] Executing 'neutron purge TENANT' command,the result returned doesn't contain the subnet resource.

2016-06-21 Thread xiewj
Public bug reported:

In Mitaka,

Creating network resources as follows,it contains:
Networks
Subnets
Ports
Router Interfaces
Routers
Floating IPs
Security Groups
Executing 'neutron purge TENANT' command,the result returned doesn't contain 
subnet resource.However the subnets are actually deleted.

[root@localhost devstack]# neutron net-list
neutron subnet-list
neutron port-list
neutron router-list
neutron router-port-list
neutron floatingip-list
+--+-++
| id   | name| subnets  
  |
+--+-++
| d34befc5-2d78-493a-b4b0-ee771eea153a | big_net | 
d6c59ba1-bce1-4223-9ddf-576cc1a48df6 10.10.10.0/24 |
| 45f7255d-1559-47a8-ba94-714be5598243 | net_xwj | 
5c3f4fb5-a0ae-437c-9f11-9c2e8cd4d1ed 102.1.1.0/24  |
|  | | 
0d400302-da37-40a2-a7a6-f9ba3134a6fa 101.1.1.0/24  |
+--+-++
[root@localhost devstack]# neutron subnet-list
+--++---++
| id   | name   | cidr  | 
allocation_pools   |
+--++---++
| d6c59ba1-bce1-4223-9ddf-576cc1a48df6 | big_subnet | 10.10.10.0/24 | {"start": 
"10.10.10.2", "end": "10.10.10.254"} |
| 5c3f4fb5-a0ae-437c-9f11-9c2e8cd4d1ed | subnet_xwj | 102.1.1.0/24  | {"start": 
"102.1.1.2", "end": "102.1.1.254"}   |
| 0d400302-da37-40a2-a7a6-f9ba3134a6fa | subnet_xwj | 101.1.1.0/24  | {"start": 
"101.1.1.2", "end": "101.1.1.254"}   |
+--++---++
[root@localhost devstack]# neutron port-list
+--+--+---+---+
| id   | name | mac_address   | fixed_ips   
  |
+--+--+---+---+
| 0291537e-d912-47cc-a3ee-4c677cebd61f |  | fa:16:3e:e4:51:6e | 
{"subnet_id": "0d400302-da37-40a2-a7a6-f9ba3134a6fa", |
|  |  |   | 
"ip_address": "101.1.1.2"}|
|  |  |   | 
{"subnet_id": "5c3f4fb5-a0ae-437c-9f11-9c2e8cd4d1ed", |
|  |  |   | 
"ip_address": "102.1.1.2"}|
| 092cf37c-409d-4ab0-9be2-da30113a6235 |  | fa:16:3e:9e:81:5d | 
{"subnet_id": "d6c59ba1-bce1-4223-9ddf-576cc1a48df6", |
|  |  |   | 
"ip_address": "10.10.10.3"}   |
| 83c4fad1-6875-4dca-8695-d0e80dd3cdb7 |  | fa:16:3e:2d:8d:6a | 
{"subnet_id": "d6c59ba1-bce1-4223-9ddf-576cc1a48df6", |
|  |  |   | 
"ip_address": "10.10.10.2"}   |
| a7ad23cf-d7df-47b5-9839-b1ace0641090 |  | fa:16:3e:94:f2:60 | 
{"subnet_id": "d6c59ba1-bce1-4223-9ddf-576cc1a48df6", |
|  |  |   | 
"ip_address": "10.10.10.4"}   |
| d0041621-b8dc-4b2c-9455-eb37f3f26b08 |  | fa:16:3e:7e:72:e5 | 
{"subnet_id": "d6c59ba1-bce1-4223-9ddf-576cc1a48df6", |
|  |  |   | 
"ip_address": "10.10.10.9"}   |
+--+--+---+---+
[root@localhost devstack]# neutron router-list
+--+-+---+-+---+
| id   | name| external_gateway_info
 | distributed | ha|
+--+-+---+-+---+
| f47136b0-6c84-4037-aeb9-95a3cead76a4 | router-list | {"network_id": 
"d34befc5-2d78-493a-   | False   | False |
|  | | b4b0-ee771eea153a", 
"enable_snat": true,  | |   |
|  | | 

[Yahoo-eng-team] [Bug 1595039] [NEW] The 'router:external' argument is missing in the help message of command 'net-create'.

2016-06-21 Thread xiewj
Public bug reported:

In Mitaka,
The 'router:external' argument is missing in the help message of command 
'net-create'.

However,creating a network specied by '--router:external' is ok,so it
seems that the '--router:external' argument is forgotten in Mitaka
Release.

[root@localhost devstack]# neutron help net-create
usage: neutron net-create [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN]
  [--max-width ] [--noindent]
  [--prefix PREFIX] [--request-format {json}]
  [--tenant-id TENANT_ID] [--admin-state-down]
  [--shared] [--provider:network_type ]
  [--provider:physical_network ]
  [--provider:segmentation_id ]
  [--vlan-transparent {True,False}]
  [--description DESCRIPTION]
  [--qos-policy QOS_POLICY]
  [--availability-zone-hint AVAILABILITY_ZONE]
  [--dns-domain DNS_DOMAIN]
  NAME

Create a network for a given tenant.

positional arguments:
  NAME  Name of network to create.

optional arguments:
  -h, --helpshow this help message and exit
  --request-format {json}
DEPRECATED! Only JSON request format is supported.
  --tenant-id TENANT_ID
The owner tenant ID.
  --admin-state-downSet admin state up to false.
  --shared  Set the network as shared.
  --provider:network_type 
The physical mechanism by which the virtual network is
implemented.
  --provider:physical_network 
Name of the physical network over which the virtual
network is implemented.
  --provider:segmentation_id 
VLAN ID for VLAN networks or tunnel-id for GRE/VXLAN
networks.
  --vlan-transparent {True,False}
Create a vlan transparent network.
  --description DESCRIPTION
Description of network.
  --qos-policy QOS_POLICY
Attach QoS policy ID or name to the resource.
  --availability-zone-hint AVAILABILITY_ZONE
Availability Zone for the network (requires
availability zone extension, this option can be
repeated).
  --dns-domain DNS_DOMAIN
Assign DNS domain to the network (requires DNS
integration extension)

output formatters:
  output formatter options

  -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml}
the output format, defaults to table
  -c COLUMN, --column COLUMN
specify the column(s) to include, can be repeated

table formatter:
  --max-width 
Maximum display width, 0 to disable

json formatter:
  --noindentwhether to disable indenting the JSON

shell formatter:
  a format a UNIX shell can parse (variable="value")

  --prefix PREFIX   add a prefix to all variable names
[root@localhost devstack]# 

[root@localhost devstack]# neutron net-create net_test --shared 
--router:external
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| availability_zone_hints   |  |
| availability_zones|  |
| created_at| 2016-06-22T04:50:38  |
| description   |  |
| id| be6ae072-3a39-4aa5-a180-79e2c0673db1 |
| ipv4_address_scope|  |
| ipv6_address_scope|  |
| is_default| False|
| mtu   | 1450 |
| name  | net_test |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1050 |
| router:external   | True |
| shared| True |
| status| ACTIVE   |
| subnets   |  |
| tags  |  |
| tenant_id | d692c40b9bd74af38361d855bebb60ac

[Yahoo-eng-team] [Bug 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread Ji.Wei
** Also affects: tempest
   Importance: Undecided
   Status: New

** Changed in: tempest
 Assignee: (unassigned) => Ji.Wei (jiwei)

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

Title:
  Make dict.keys() PY3 compatible

Status in Ceilometer:
  In Progress
Status in Cinder:
  In Progress
Status in heat:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in python-ceilometerclient:
  New
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  New
Status in python-heatclient:
  New
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  In Progress
Status in Rally:
  In Progress
Status in tempest:
  New

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1583419/+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 1594482] Re: list_services API filtered by name can't find the service when using list_limit

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/331790
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=6a9a9f002f44c15d40cf890eefd03a4ab6172b0b
Submitter: Jenkins
Branch:master

commit 6a9a9f002f44c15d40cf890eefd03a4ab6172b0b
Author: Roxana Gherle 
Date:   Mon Jun 20 10:53:36 2016 -0700

/services?name= API fails when using list_limit

When using list_limit configuration option in Default section of
keystone.conf, the /services?name= API fails to find
the service if list_limit value is smaller than the total number
of services and the searched service is not among the first
'list_limit' services. The API should first filter by name and
only afterwards truncate the result list.

Also, this patch fixes setting the 'truncated' attribute of the
driver's hint.limit object when truncating the list outside of
driver_hints.truncated decorator, problem exposed by fixing the
problem described in the first paragraph.

Closes-Bug: #1594482
Change-Id: I832f542c3cb0faf94a1e5bce5a894f7f4d26a8de


** Changed in: keystone
   Status: In Progress => Fix Released

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

Title:
  list_services API filtered by name can't find the service when using
  list_limit

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  /services?name= API can't find the service when using list_limit 
configuration.
  Before setting list_limit in keystone.conf the following API call behaves 
correctly: 

  stack@mitaka2:/opt/stack/keystone$ curl -H "X-Auth-Token: $TOK" 
http://mitaka2.com:5000/v3/services?name=keystone | python -mjson.tool
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   318  100   3180 0 95  0  0:00:03  0:00:03 --:--:--95
  {
  "links": {
  "next": null,
  "previous": null,
  "self": "http://mitaka2.com/identity/v3/services?name=keystone;
  },
  "services": [
  {
  "enabled": true,
  "id": "f7ef63607b8542e0a7cb9a9b1b119c25",
  "links": {
  "self": 
"http://mitaka2.com/identity/v3/services/f7ef63607b8542e0a7cb9a9b1b119c25;
  },
  "name": "keystone",
  "type": "identity"
  }
  ]
  }

  After setting list_limit=3 in the Default section in keystone.conf,
  the API can't find the service any more:

  stack@mitaka2:/opt/stack/keystone$ curl -H "X-Auth-Token: $TOK" 
http://mitaka2.com:5000/v3/services?name=keystone | python -mjson.tool
% Total% Received % Xferd  Average Speed   TimeTime Time  
Current
   Dload  Upload   Total   SpentLeft  Speed
  100   143  100   1430 0 43  0  0:00:03  0:00:03 --:--:--43
  {
  "links": {
  "next": null,
  "previous": null,
  "self": "http://mitaka2.com/identity/v3/services?name=keystone;
  },
  "services": [],
  "truncated": true
  }

  It seems like the list is truncated before applying the name filter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1594482/+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 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread Ji.Wei
** Also affects: python-glanceclient
   Importance: Undecided
   Status: New

** Changed in: python-glanceclient
 Assignee: (unassigned) => Ji.Wei (jiwei)

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

Title:
  Make dict.keys() PY3 compatible

Status in Ceilometer:
  In Progress
Status in Cinder:
  In Progress
Status in heat:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in python-ceilometerclient:
  New
Status in python-cinderclient:
  Fix Released
Status in python-glanceclient:
  New
Status in python-heatclient:
  New
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  In Progress
Status in Rally:
  In Progress

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1583419/+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 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread liuwei
** Also affects: python-ceilometerclient
   Importance: Undecided
   Status: New

** Changed in: python-ceilometerclient
 Assignee: (unassigned) => liuwei (liu-wei81)

** Also affects: python-heatclient
   Importance: Undecided
   Status: New

** Changed in: python-heatclient
 Assignee: (unassigned) => liuwei (liu-wei81)

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

Title:
  Make dict.keys() PY3 compatible

Status in Ceilometer:
  In Progress
Status in Cinder:
  In Progress
Status in heat:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in python-ceilometerclient:
  New
Status in python-cinderclient:
  Fix Released
Status in python-heatclient:
  New
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  In Progress
Status in Rally:
  In Progress

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1583419/+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 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread liuwei
** Also affects: ceilometer
   Importance: Undecided
   Status: New

** Changed in: ceilometer
 Assignee: (unassigned) => liuwei (liu-wei81)

** Also affects: heat
   Importance: Undecided
   Status: New

** Changed in: heat
 Assignee: (unassigned) => liuwei (liu-wei81)

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

Title:
  Make dict.keys() PY3 compatible

Status in Ceilometer:
  New
Status in Cinder:
  In Progress
Status in heat:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in python-cinderclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  In Progress
Status in Rally:
  In Progress

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1583419/+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 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread Bin Zhou
** Also affects: neutron
   Importance: Undecided
   Status: New

** Changed in: neutron
 Assignee: (unassigned) => Bin Zhou (binzhou)

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

Title:
  Make dict.keys() PY3 compatible

Status in Cinder:
  In Progress
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in python-cinderclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  In Progress
Status in Rally:
  New

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1583419/+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 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread yuyafei
** Also affects: rally
   Importance: Undecided
   Status: New

** Changed in: rally
 Assignee: (unassigned) => yuyafei (yu-yafei)

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

Title:
  Make dict.keys() PY3 compatible

Status in Cinder:
  In Progress
Status in neutron:
  New
Status in OpenStack Compute (nova):
  New
Status in python-cinderclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  In Progress
Status in Rally:
  New

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1583419/+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 1585893] Re: Launch instance got libvirtError for qemu unsupported IDE bus in AARCH64

2016-06-21 Thread Augustina Ragwitz
Since the Mitaka cycle we use the direct release model, which means this
should be Fix Released.

** Changed in: nova
   Status: Fix Committed => Fix Released

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

Title:
  Launch instance got libvirtError for qemu unsupported  IDE bus in
  AARCH64

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===
  After setup the nova development environment with devstack in aarch64 machine 
,use the glance upload the image ,then use nova to launch the 
instance.Launching failed with the error "libvirtError: unsupported 
configuration: IDE controllers are unsupported for this QEMU binary or machine 
type".
   
  Steps to reproduce
  ==
  1.Using devstack to deploy openstack. Using default local.conf.

  2.Upload the aarch64 image with glance.
  $ source ~/devstack/openrc admin admin
  $ glance image-create --name image-arm64.img --disk-format qcow2 
--container-format bare --visibility public --file 
images/image-arm64-wily.qcow2 --progress
  $ glance image-create --name image-arm64.vmlinuz --disk-format aki 
--container-format aki --visibility public --file 
images/image-arm64-wily.vmlinuz --progress
  $ glance image-create --name image-arm64.initrd --disk-format ari 
--container-format ari --visibility public --file 
images/image-arm64-wily.initrd --progress
  $ IMAGE_UUID=$(glance image-list | grep image-arm64.img | awk '{ print $2 }')
  $ IMAGE_KERNEL_UUID=$(glance image-list | grep image-arm64.vmlinuz | awk '{ 
print $2 }')
  $ IMAGE_INITRD_UUID=$(glance image-list | grep image-arm64.initrd | awk '{ 
print $2 }')
  $ glance image-update --kernel-id ${IMAGE_KERNEL_UUID} --ramdisk-id 
${IMAGE_INITRD_UUID} ${IMAGE_UUID}

  3.nova add keypair
  $ nova keypair-add default --pub-key ~/.ssh/id_rsa.pub

  4.Launch the instance:
  $ image=$(nova image-list | egrep "image-arm64.img"'[^-]' | awk '{ print $2 
}')
  $ nova boot --flavor m1.medium --image ${image} --key-name default test-arm64

  5.screen -x and select the n-cpu session to see the output.
  Then will got the error.

  Expected result
  ===
  After spawningn the instance, use :
  $ nova list
  We can see the instance is active.

  Actual result
  =
  Got the error: 
  libvirtError: unsupported configuration: IDE controllers are unsupported for 
this QEMU binary or machine type

  We can see the detailed information:
   ERROR nova.compute.manager [req-75325207-6c1b-481d-b188-a66c0a64eb89 admin 
admin] [instance: 188aa5bc-173c-46ec-b872-6bacb512911e] Instance failed to spawn
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e] 
Traceback (most recent call last):
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/opt/stack/nova/nova/compute/manager.py", line 2041, in _build_resources
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   yield resources
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/opt/stack/nova/nova/compute/manager.py", line 1887, in 
_build_and_run_instance
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   block_device_info=block_device_info)
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2569, in spawn
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   block_device_info=block_device_info)
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4713, in 
_create_domain_and_network
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   xml, pause=pause, power_on=power_on)
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4644, in 
_create_domain
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   guest.launch(pause=pause)
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 142, in launch
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   self._encoded_xml, errors='ignore')
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
221, in __exit__
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
   self.force_reraise()
   TRACE nova.compute.manager [instance: 188aa5bc-173c-46ec-b872-6bacb512911e]  
 File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
197, in force_reraise
   TRACE 

[Yahoo-eng-team] [Bug 1333498] Re: table nova.pci_devices lost device status every time. && PciDeviceList.get_by_compute_node pass a wrong parameter

2016-06-21 Thread Augustina Ragwitz
A previous comment indicated this bug had been addressed by
https://review.openstack.org/#/c/148904/ so marking this as Fix
Released.

** Changed in: nova
   Status: Confirmed => Fix Released

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

Title:
  table nova.pci_devices  lost device status every time. &&
  PciDeviceList.get_by_compute_node pass a wrong parameter

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  
  I'm trying to use SR-IOV in openstack havana.

  After a pci device(virtual function in my case) is allocated to a vm, the 
status of  according record in table 'nova.pci_devices' is updated to allocated.
  However,   when I restart the openstack services,  the devices' records are 
updated to available again.   Actually, the pci devices are allocated to vm.

  I looked into the code and found the problem below.

  In the __init__ function of PciDevTracker in pci/pci_manager.py ,  it 
requires node_id. 
  If a node_id is passed in, it will fetch pci devices information
  from database, otherwise, it will create an empty devices list

  However, the code initiating PciDevTracker (in
  compute/resource_tracker.py) never passes node_id.   So  it will never
  fetch pci devices information from database and the status will be
  updated to 'available' every time we restart services.

  
  =

  
  Then I  try do add the node id and  want to see what will happen.

  Then I got this error
   self.pci_tracker = pci_manager.PciDevTracker(node_id=1)
 File "/usr/lib/python2.6/site-packages/nova/pci/pci_manager.py", line 67, 
in __init__
   context, node_id)
 File "/usr/lib/python2.6/site-packages/nova/objects/base.py", line 106, in 
wrapper
   args, kwargs)
 File "/usr/lib/python2.6/site-packages/nova/conductor/rpcapi.py", line 
492, in object_class_action
   objver=objver, args=args, kwargs=kwargs)
 File "/usr/lib/python2.6/site-packages/nova/rpcclient.py", line 85, in call
   return self._invoke(self.proxy.call, ctxt, method, **kwargs)
 File "/usr/lib/python2.6/site-packages/nova/rpcclient.py", line 63, in 
_invoke
   return cast_or_call(ctxt, msg, **self.kwargs)
 File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/proxy.py", line 
126, in call
   result = rpc.call(context, real_topic, msg, timeout)
 File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/__init__.py", line 
139, in call
   return _get_impl().call(CONF, context, topic, msg, timeout)
 File 
"/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py", line 
783, in call
   rpc_amqp.get_connection_pool(conf, Connection))
 File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", 
line 572, in call
   rv = multicall(conf, context, topic, msg, timeout, connection_pool)
 File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", 
line 558, in multicall
   pack_context(msg, context)
 File "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", 
line 308, in pack_context
   for (key, value) in context.to_dict().iteritems()])
   AttributeError: 'module' object has no attribute 'to_dict'

  
  It pass the module context to 
pci_device_obj.PciDeviceList.get_by_compute_node.  But to_dict is a function of 
RequestContext in module context. It seems that it should pass a 
RequestContext instance instead of the module context.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1333498/+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 1589221] Re: Nova-compute: "ImageNotFound: Image could not be found."

2016-06-21 Thread Augustina Ragwitz
This looks like a possible configuration issue, according to your logs I
see the following:

>From nova compute manager:
ConnectFailure: Unable to establish connection to 
http://192.168.10.59:9696/v2.0/ports.json?tenant_id=a28c7b4b55034254a2d912fe6bfb49ad_id=21a97ef7-7ae8-4f...

And from the glance client:
ImageNotFound: Image b1c302c6-23b2-4d59-9b32-da9ff5d11e5b could not be found.

For technical support, please direct your question to the OpenStack
mailing list or to the #openstack channel on irc.

If you do believe this is a bug, please reopen this issue and provide the 
following information:
1. What version of Nova you are running (eg, Liberty, Mitaka, master)
2. Detailed steps to reproduce the issue


** Changed in: nova
   Status: New => Invalid

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

Title:
  Nova-compute: "ImageNotFound: Image  could not be found."

Status in OpenStack Compute (nova):
  Invalid
Status in nova-compute package in Juju Charms Collection:
  New

Bug description:
  Spawning a new instance using a newly created image most of the time
  fails. After 2-3 attempts, the problem gets resolved.

  The configs that I'm using in my HA-environment are:
  nova-compute:
  enable-live-migration: "True"
  enable-resize: "True"
  openstack-origin: "cloud:trusty-mitaka"
  migration-auth-type: "ssh"
  manage-neutron-plugin-legacy-mode: False
  glance:
  openstack-origin: "cloud:trusty-mitaka"
  region: "serverstack"
  vip: 
  nova-cloud-controller:
  network-manager: "Neutron"
  console-access-protocol: "novnc"
  openstack-origin: "cloud:trusty-mitaka"
  region: "serverstack"
  vip: 

  I have one compute. Compute logs: http://paste.ubuntu.com/17026140/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1589221/+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 1593793] Re: [RFE] No notification on floating ip status change

2016-06-21 Thread Travis Tripp
** Also affects: searchlight
   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/1593793

Title:
  [RFE] No notification on floating ip status change

Status in neutron:
  Triaged
Status in OpenStack Search (Searchlight):
  New

Bug description:
  Tested on neutron/master in devstack.

  When I associate or disassociate a floating IP I get a notification
  indicating the new fixed IP and port association, but the status still
  indicates the current value (so for associate, the notification
  contains "fixed_ip_address":"a.b.c.d", "status": "DOWN") because
  there's a short latency time before the FIP is marked as ACTIVE.

  I see the status change after a very short period after in the q-svc
  log:

  New status for floating IP 8470e622-0f3b-419f-ac21-deed658d3260:
  ACTIVE

  There's no notification emitted representing this state change,
  however. The same is true on disassociate; the port and fixed IP are
  cleared but the status is indicated ACTIVE and there's no notification
  marking it DOWN.

  E.g.
  $ neutron floatingip-create 0e97853d-3ac0-4c08-a8b3-f6bfa443dd24

  {"event_type": "floatingip.create.end", "payload": {"floatingip":
  {"router_id": null, "status": "DOWN", "description": "", "tenant_id":
  "c1b853bf78bc43c69daa8d42cb9fb07f", "floating_network_id": "0e97853d-
  3ac0-4c08-a8b3-f6bfa443dd24", "fixed_ip_address": null,
  "floating_ip_address": "172.25.0.11", "port_id": null, "id":
  "6442165e-4caa-437c-9377-196f4db638f9"}}, "publisher_id":
  "network.devstack", "ctxt": {...}, "metadata": {"timestamp":
  "2016-06-17 16:44:20.600943", "message_id": "547b0f34-1bc0-4fbc-
  8e58-a0c2d2dc1751"}}

  $ neutron floatingip-associate 6442165e-4caa-437c-9377-196f4db638f9
  8068c884-1ab4-42d9-97d0-f65848fca2b0

  {"event_type": "floatingip.update.end", "payload": {"floatingip":
  {"router_id": "390ab366-0eee-46e9-a07f-f49cf0b31652", "status":
  "DOWN", "description": "", "tenant_id":
  "c1b853bf78bc43c69daa8d42cb9fb07f", "floating_network_id": "0e97853d-
  3ac0-4c08-a8b3-f6bfa443dd24", "fixed_ip_address": "172.40.0.4",
  "floating_ip_address": "172.25.0.11", "port_id":
  "8068c884-1ab4-42d9-97d0-f65848fca2b0", "id": "6442165e-4caa-
  437c-9377-196f4db638f9"}}, "publisher_id": "network.devstack", "ctxt":
  {...}, "metadata": {"timestamp": "2016-06-17 16:44:50.149631",
  "message_id": "f6f7ec1f-6363-49b0-b10f-84fd81e0a506"}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593793/+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 1259292] Re: Some tests use assertEqual(observed, expected) , the argument order is wrong

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/329764
Committed: 
https://git.openstack.org/cgit/openstack/glance_store/commit/?id=fd1e846a60c0e73e641b22af2ed07b91b040c6a2
Submitter: Jenkins
Branch:master

commit fd1e846a60c0e73e641b22af2ed07b91b040c6a2
Author: yuyafei 
Date:   Wed Jun 15 13:26:44 2016 +0800

Fix argument order for assertEqual to (expected, observed)

assertEqual expects that the arguments provided to it should be
(expected, observed). If a particluar order is kept as a convention,
then it helps to provide a cleaner message to the developer if Unit
Tests fail. The following patch fixes this issue.

TrivialFix

Change-Id: I07b78383ef38731140143c91ae3a902bea55eebb
Closes-Bug: #1259292


** Changed in: glance-store
   Status: In Progress => Fix Released

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

Title:
  Some tests use assertEqual(observed, expected) , the argument order is
  wrong

Status in Barbican:
  In Progress
Status in Ceilometer:
  Invalid
Status in Cinder:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in Glance:
  Fix Released
Status in glance_store:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in Mistral:
  Fix Released
Status in Murano:
  Fix Released
Status in OpenStack Compute (nova):
  Won't Fix
Status in os-brick:
  In Progress
Status in python-ceilometerclient:
  Invalid
Status in python-cinderclient:
  Fix Released
Status in python-designateclient:
  Fix Committed
Status in python-glanceclient:
  In Progress
Status in python-mistralclient:
  Fix Released
Status in python-solumclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Sahara:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  The test cases will produce a confusing error message if the tests
  ever fail, so this is worth fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1259292/+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 1525913] Re: vmwareapi get vcenter cluster

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/257674
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=621191f1d6a6c3f98966069dafac8ca6701f8567
Submitter: Jenkins
Branch:master

commit 621191f1d6a6c3f98966069dafac8ca6701f8567
Author: linbing 
Date:   Thu Jun 16 03:57:13 2016 -0700

VMware: Fix bug of TypeError when getting reference of VCenter cluster is 
None.

* When get VCenter of all cluster reference and return None, it's  a
  NoneType, and could not be iterable, so it will cause error like
  :“TypeError: 'NoneType' object is not iterable ”.

* This patch add the situation of cluster reference is None, and will
  return an empyt list.

Closes-Bug: #1525913
Change-Id: Ifcf0e1edf378f239030a27e40d5bed436876858b


** Changed in: nova
   Status: Fix Committed => Fix Released

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

Title:
  vmwareapi get vcenter cluster

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  
  In liberty nova/virt/vmwareapi/vm_util.py
  def get_cluster_ref_by_name(session, cluster_name):
  """Get reference to the vCenter cluster with the specified name."""
  all_clusters = get_all_cluster_mors(session)
  for cluster in all_clusters:
  if (hasattr(cluster, 'propSet') and
  cluster.propSet[0].val == cluster_name):
  return cluster.obj
  when all_cluster is None,this code may cause error:TypeError: 'NoneType' 
object is not iterable,and nova-computer would't up

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1525913/+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 1587117] Re: type is missing from the parameter list of Get RDP console

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/329462
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=32d45f15dc97e02138eced3899c872725413ae83
Submitter: Jenkins
Branch:master

commit 32d45f15dc97e02138eced3899c872725413ae83
Author: csatari 
Date:   Tue Jun 14 15:49:16 2016 +0200

api-ref: console types.

Documentation change in api-ref.

type is added to the parameter lists of Get RDP console, Get serial console,
Get SPICE console, Get VNC console.

Closes-Bug: 1587117
Closes-Bug: 1587118
Closes-Bug: 1587119
Closes-Bug: 1587121

Change-Id: I73823fd6fb0886e2fff0da4838fe868f578bba6d
Signed-off-by: csatari 


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  type is missing from the parameter list of  Get RDP console

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  According to the example Get RDP console has a parameter called "type".
  This parameter is not listed in the Parameter list of Get RDP console in the 
web API reference [1] and not mentioned in Chapter 4.4.11.1 of the pdf API 
reference [2].
  In the wab API reference it is not clear that the 2nd example is for the 
response. Similar bug was reported in [3].

  [1]: http://developer.openstack.org/api-ref-compute-v2.1.html#getRDPConsole
  [2]: http://api.openstack.org/api-ref-guides/bk-api-ref.pdf
  [3]: https://bugs.launchpad.net/openstack-api-site/+bug/1565670

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1587117/+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 1587119] Re: type is missing from the parameter list of Get SPICE console

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/329462
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=32d45f15dc97e02138eced3899c872725413ae83
Submitter: Jenkins
Branch:master

commit 32d45f15dc97e02138eced3899c872725413ae83
Author: csatari 
Date:   Tue Jun 14 15:49:16 2016 +0200

api-ref: console types.

Documentation change in api-ref.

type is added to the parameter lists of Get RDP console, Get serial console,
Get SPICE console, Get VNC console.

Closes-Bug: 1587117
Closes-Bug: 1587118
Closes-Bug: 1587119
Closes-Bug: 1587121

Change-Id: I73823fd6fb0886e2fff0da4838fe868f578bba6d
Signed-off-by: csatari 


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  type is missing from the parameter list of Get SPICE console

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  According to the example Get SPICE console has a parameter called "type".
  This parameter is not listed in the Parameter list of Get SPICE console in 
the web API reference [1] and not mentioned in Chapter 4.4.13.1 of the pdf API 
reference [2].
  In the web API reference it is not clear that the 2nd example is for the 
response. Similar bug was reported in [3].

  [1]: http://developer.openstack.org/api-ref-compute-v2.1.html#getSPICEConsole
  [2]: http://api.openstack.org/api-ref-guides/bk-api-ref.pdf
  [3]: https://bugs.launchpad.net/openstack-api-site/+bug/1565670

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1587119/+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 1587118] Re: type is missing from the parameter list of Get serial console

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/329462
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=32d45f15dc97e02138eced3899c872725413ae83
Submitter: Jenkins
Branch:master

commit 32d45f15dc97e02138eced3899c872725413ae83
Author: csatari 
Date:   Tue Jun 14 15:49:16 2016 +0200

api-ref: console types.

Documentation change in api-ref.

type is added to the parameter lists of Get RDP console, Get serial console,
Get SPICE console, Get VNC console.

Closes-Bug: 1587117
Closes-Bug: 1587118
Closes-Bug: 1587119
Closes-Bug: 1587121

Change-Id: I73823fd6fb0886e2fff0da4838fe868f578bba6d
Signed-off-by: csatari 


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  type is missing from the parameter list of Get serial console

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  According to the example Get serial console has a parameter called "type".
  This parameter is not listed in the Parameter list of Get serial console in 
the web API reference [1] and not mentioned in Chapter 4.4.12.1 of the pdf API 
reference [2].
  In the wab API reference it is not clear that the 2nd example is for the 
response. Similar bug was reported in [3].

  [1]: http://developer.openstack.org/api-ref-compute-v2.1.html#getSerialConsole
  [2]: http://api.openstack.org/api-ref-guides/bk-api-ref.pdf
  [3]: https://bugs.launchpad.net/openstack-api-site/+bug/1565670

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1587118/+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 1587121] Re: type is missing from the parameter list of Get VNC console

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/329462
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=32d45f15dc97e02138eced3899c872725413ae83
Submitter: Jenkins
Branch:master

commit 32d45f15dc97e02138eced3899c872725413ae83
Author: csatari 
Date:   Tue Jun 14 15:49:16 2016 +0200

api-ref: console types.

Documentation change in api-ref.

type is added to the parameter lists of Get RDP console, Get serial console,
Get SPICE console, Get VNC console.

Closes-Bug: 1587117
Closes-Bug: 1587118
Closes-Bug: 1587119
Closes-Bug: 1587121

Change-Id: I73823fd6fb0886e2fff0da4838fe868f578bba6d
Signed-off-by: csatari 


** Changed in: nova
   Status: In Progress => Fix Released

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

Title:
  type is missing from the parameter list of Get VNC console

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  According to the example Get VNC console has a parameter called "type".
  This parameter is not listed in the Parameter list of Get VNC console in the 
web API reference [1] and not mentioned in Chapter 4.4.14.1 of the pdf API 
reference [2].
  In the web API reference it is not clear that the 2nd example is for the 
response. Similar bug was reported in [3].

  [1]: http://developer.openstack.org/api-ref-compute-v2.1.html#getVNCConsole
  [2]: http://api.openstack.org/api-ref-guides/bk-api-ref.pdf
  [3]: https://bugs.launchpad.net/openstack-api-site/+bug/1565670

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1587121/+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 1594969] [NEW] stable/liberty lbaas http package not forwarded

2016-06-21 Thread alex kang
Public bug reported:

The latest neutron-lbaas stable/liberty repo, the loadbalancer VIP will
not forward http packets to its pool members.

http to pool members are OK, but http to loadbalancer VIP failed.
Look at the VIP's port security-group, and it is correctly wired to the 
security-group-id.

stack@htb-1n-eng-dhcp8:~/devstack$ neutron router-list
+--+--++
| id   | name | 
external_gateway_info   

   |
+--+--++
| 6181d39e-9e0c-4209-a20a-7708b49f9adb | router1  | {"network_id": 
"7bf2d2d9-c714-46fe-a785-d1f4f43f0520", "enable_snat": true, 
"external_fixed_ips": [{"subnet_id": "cc99a75d-229a-47ef-801a-095f1afa590a", 
"ip_address": "172.24.4.2"}]} |
| e31ca56f-eb2f-4903-a254-a91ac736074c | venus-lb2-1506387029 | {"network_id": 
"7bf2d2d9-c714-46fe-a785-d1f4f43f0520", "enable_snat": true, 
"external_fixed_ips": [{"subnet_id": "cc99a75d-229a-47ef-801a-095f1afa590a", 
"ip_address": "172.24.4.3"}]} |
+--+--++
stack@htb-1n-eng-dhcp8:~/devstack$ neutron lbaas-loadbalancer-list
+--+---+-+-+--+
| id   | name  | vip_address | 
provisioning_status | provider |
+--+---+-+-+--+
| 9b4d8297-0f6d-47c3-80fe-7a09e3c5f5f1 | venus-lb2 | 10.199.88.5 | ACTIVE   
   | haproxy  |
+--+---+-+-+--+
stack@htb-1n-eng-dhcp8:~/devstack$ neutron lbaas-loadbalancer-show venus-lb2
+-++
| Field   | Value  |
+-++
| admin_state_up  | True   |
| description ||
| id  | 9b4d8297-0f6d-47c3-80fe-7a09e3c5f5f1   |
| listeners   | {"id": "7db08049-472a-4d95-bd33-7a3c42bd4cb9"} |
| name| venus-lb2  |
| operating_status| ONLINE |
| provider| haproxy|
| provisioning_status | ACTIVE |
| tenant_id   | eea91ed392d64bae8d9eb41310127f09   |
| vip_address | 10.199.88.5|
| vip_port_id | f542905d-8fde-4562-a9a1-e337f2d3c01c   |
| vip_subnet_id   | f8627153-0817-4676-b493-38c9e079426a   |
+-++
stack@htb-1n-eng-dhcp8:~/devstack$ neutron port-show 
f542905d-8fde-4562-a9a1-e337f2d3c01c
+---++
| Field | Value 
 |
+---++
| admin_state_up| True  
 |
| allowed_address_pairs |   
 |
| binding:host_id   | htb-1n-eng-dhcp8  
 |
| binding:vif_details   | {"port_filter": true} 
 |
| binding:vif_type  | ovs   
 |
| binding:vnic_type | normal
 |
| device_id | 9b4d8297-0f6d-47c3-80fe-7a09e3c5f5f1  
 |
| device_owner  | neutron:LOADBALANCERV2
 |
| 

[Yahoo-eng-team] [Bug 1594967] [NEW] cloud-init lack of retry causes apt-get failures to be fatal

2016-06-21 Thread Nunya
Public bug reported:

We use cloudinit to do apt-gets to install software. apt-gets fail ~20%
of the time and it seems to be increasing.

W: An error occurred during the signature verification. The repository is 
not updated and the previous index files 
will be used. GPG error: http://us-central1.gce.archive.ubuntu.com 
trusty-updates InRelease: The following signatures couldn't be verified because 
the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 
3B4FE6ACC0B21
F32

Manually doing the command below a few times solves the problem, but
cloudinit doesn't have any retry logic around this so having stable apt
repositories is very important to have a repeatable process. What do you
recommend if the repos won't be stable? I would think a simple retry in
cloud-init (either configurable or 5x or something sane) would be very
helpful.

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys XXX 
apt-get update

** Affects: cloud-init
 Importance: Undecided
 Status: New


** Tags: apt-get cloudinit

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

Title:
  cloud-init lack of retry causes apt-get failures to be fatal

Status in cloud-init:
  New

Bug description:
  We use cloudinit to do apt-gets to install software. apt-gets fail
  ~20% of the time and it seems to be increasing.

  W: An error occurred during the signature verification. The repository is 
not updated and the previous index files 
  will be used. GPG error: http://us-central1.gce.archive.ubuntu.com 
trusty-updates InRelease: The following signatures couldn't be verified because 
the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 
3B4FE6ACC0B21
  F32

  Manually doing the command below a few times solves the problem, but
  cloudinit doesn't have any retry logic around this so having stable
  apt repositories is very important to have a repeatable process. What
  do you recommend if the repos won't be stable? I would think a simple
  retry in cloud-init (either configurable or 5x or something sane)
  would be very helpful.

  apt-key adv --keyserver keyserver.ubuntu.com --recv-keys XXX 
  apt-get update

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1594967/+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 1591920] Re: Unnecessary message is recorded for aggregate panel at every time

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/328912
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=f20b3b1e600c8739fece3b3c7083019016f9608f
Submitter: Jenkins
Branch:master

commit f20b3b1e600c8739fece3b3c7083019016f9608f
Author: Kenji Ishii 
Date:   Mon Jun 13 17:54:53 2016 +0900

Add check whether nova is enable or not in aggregate panel

At the moment, aggregate panel has a check whether nova extension
is enable or not. However it doesn't check nova is enable or not.
So, when operator use non nova, error always occur by this check
method. Therefore, this patch will add a check whether nova is
enable or not.

Closes-Bug: #1591920

Change-Id: I5ad37f16f70f1ac9b95c49b1363d1b23abbb1b94


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1591920

Title:
  Unnecessary message is recorded  for aggregate panel at every time

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Aggregate panel is checking whether nova extension is enabled or not.
  when nova service is disabled, this process will occur exception and will 
record error message every time apache is restarted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1591920/+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 1553815] Re: host keys never restored following metadata api outage

2016-06-21 Thread Scott Moser
** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu Trusty)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Wily)
   Status: New => Confirmed

** Changed in: cloud-init (Ubuntu Wily)
   Status: Confirmed => Won't Fix

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

Title:
  host keys never restored following metadata api outage

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Trusty:
  Confirmed
Status in cloud-init source package in Wily:
  Won't Fix
Status in cloud-init source package in Xenial:
  Fix Released

Bug description:
  We are running an Openstack cloud and have noticed some unexpected
  behaviour in our Ubuntu Trusty cloud instances created by Nova.

  We have observed that if a previously initialised instance (e.g.
  DataSourceOpenstack has already been run) is rebooted while the
  metadata api is not available (i.e. 169.254.169.264 is unreachable),
  cloud-init will retry a few times then switch to DataSourceNone and
  regenerate host keys.

  # Boot instance under normal conditions
  ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance
  /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95
  ubuntu@vm1:~$ grep "Generating public/private rsa key pair." 
/var/log/cloud-init-output.log 
  Generating public/private rsa key pair.

  # Stop neutron metadata api service and reboot instance (observing that 
host keys were regenerated)
  ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance
  /var/lib/cloud/instances/iid-datasource-none
  ubuntu@vm1:~$ grep "Generating public/private rsa key pair." 
/var/log/cloud-init-output.log 
  Generating public/private rsa key pair.
  Generating public/private rsa key pair.

  So far so good since we expect this behaviour, but now we reboot this 
instance with the metadata api is once again reachable. Cloud-init rightly 
selects the original DataSourceOpenstack instance but it does nothing since it 
already ran once (and it is set to only run once). The problem here is that the 
original host keys are never 
  restored so any client connecting to that instance will have no option to 
accept the new host keys along with MITM attack warning.

  ubuntu@vm1:~$ sudo reboot
  ...
  ubuntu@vm1:~$ readlink -f /var/lib/cloud/instance
  /var/lib/cloud/instances/cd535bc4-9c2f-4d31-8903-0ede59c7ef95

  Surely we could find a way for cloud-init to know that if if the
  current DataSourceOpenstack uuid matches its previously run uuid, then
  it can check that the host keys are consistent with the original run.
  @smoser suggested in a side discussion that dmidecode info could
  perhaps be used since the Openstack instance uuid can be found there:

  ubuntu@vm1:~$ sudo dmidecode -t system
  # dmidecode 2.12
  SMBIOS 2.8 present.

  Handle 0x0100, DMI type 1, 27 bytes
  System Information
Manufacturer: OpenStack Foundation
Product Name: OpenStack Nova
Version: 13.0.0
Serial Number: ba5f7371-fd4c-a25e-132f-3dd1e5b92e93
UUID: CD535BC4-9C2F-4D31-8903-0EDE59C7EF95
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Virtual Machine

  Handle 0x2000, DMI type 32, 11 bytes
  System Boot Information
Status: No errors detected

  If cloud-init kept a copy of previous host keys prior to regenerating
  them, it could presumably use this info to know when to safely restore
  the original host keys.

  Since it is not inconceivable for the metadata api to become
  unreachable for a brief period (perhpas during an upgrade), i think we
  really need to make cloud-init more tolerant of this circumstance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553815/+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 1493576] Re: Incorrect usage of python-novaclient

2016-06-21 Thread Andrey Kurilin
** Also affects: networking-cisco
   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/1493576

Title:
  Incorrect usage of python-novaclient

Status in Cinder:
  Fix Released
Status in congress:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Manila:
  Fix Released
Status in Mistral:
  Fix Released
Status in networking-cisco:
  New
Status in os-cloud-config:
  New
Status in OpenStack DBaaS (Trove):
  Fix Released

Bug description:
  All projects should use only `novaclient.client` as entry point. It designed 
with some version checks and backward compatibility.
  Direct import of versioned client object(i.e. novaclient.v2.client) is a way 
to "shoot yourself in the foot".

  Python-novaclient's doc: http://docs.openstack.org/developer/python-
  novaclient/api.html

  Affected projects:
   - Horizon - 
https://github.com/openstack/horizon/blob/69d6d50ef4a26e2629643ed35ebd661e82e10586/openstack_dashboard/api/nova.py#L31

   - Manila -
  
https://github.com/openstack/manila/blob/473b46f6edc511deaba88b48392b62bfbb979787/manila/compute/nova.py#L23

   - Cinder-
  
https://github.com/openstack/cinder/blob/de64f5ad716676b7180365798efc3ea69a4fef0e/cinder/compute/nova.py#L23

   - Mistral - 
https://github.com/openstack/mistral/blob/f42b7f5f5e4bcbce8db7e7340b4cac12de3eec4d/mistral/actions/openstack/actions.py#L23
   
   - Congress - 
https://github.com/openstack/congress/blob/88f4a87f4899fc29e9dde6482ceb2a0e42896ece/contrib/nova/congress.py#L92

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1493576/+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 1493576] Re: Incorrect usage of python-novaclient

2016-06-21 Thread Matt Riedemann
** Also affects: congress
   Importance: Undecided
   Status: New

** Also affects: os-cloud-config
   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/1493576

Title:
  Incorrect usage of python-novaclient

Status in Cinder:
  Fix Released
Status in congress:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Manila:
  Fix Released
Status in Mistral:
  Fix Released
Status in os-cloud-config:
  New
Status in OpenStack DBaaS (Trove):
  Fix Released

Bug description:
  All projects should use only `novaclient.client` as entry point. It designed 
with some version checks and backward compatibility.
  Direct import of versioned client object(i.e. novaclient.v2.client) is a way 
to "shoot yourself in the foot".

  Python-novaclient's doc: http://docs.openstack.org/developer/python-
  novaclient/api.html

  Affected projects:
   - Horizon - 
https://github.com/openstack/horizon/blob/69d6d50ef4a26e2629643ed35ebd661e82e10586/openstack_dashboard/api/nova.py#L31

   - Manila -
  
https://github.com/openstack/manila/blob/473b46f6edc511deaba88b48392b62bfbb979787/manila/compute/nova.py#L23

   - Cinder-
  
https://github.com/openstack/cinder/blob/de64f5ad716676b7180365798efc3ea69a4fef0e/cinder/compute/nova.py#L23

   - Mistral - 
https://github.com/openstack/mistral/blob/f42b7f5f5e4bcbce8db7e7340b4cac12de3eec4d/mistral/actions/openstack/actions.py#L23
   
   - Congress - 
https://github.com/openstack/congress/blob/88f4a87f4899fc29e9dde6482ceb2a0e42896ece/contrib/nova/congress.py#L92

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1493576/+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 1594926] [NEW] In integration tests loading a new page interferes with dropdown opening

2016-06-21 Thread Timur Sufiev
Public bug reported:

The following scenario has been seen many times in failed integration
tests: all test actions are completed successfully, then test cleanup
method goes to home page, and tries to log out - which fails, because
the test clicks User dropdown menu (in upper right corner) too quickly,
before the dropdown constructors have been finished by bootstrap JS - so
the dropdown which contains Log Out link never opens.

This sometimes happens not only with log out link (if that was true, we
could simply workaround it), but for some other dropdowns as well, but
the failure rate with other dropdowns is lower - simply because they
operated less frequently than Log Out link (which is present in every
test).

The desired solution here is to wait until dropdowns become truly
clickable.

** Affects: horizon
 Importance: High
 Assignee: Timur Sufiev (tsufiev-x)
 Status: New


** Tags: integration-tests

-- 
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/1594926

Title:
  In integration tests loading a new page interferes with dropdown
  opening

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The following scenario has been seen many times in failed integration
  tests: all test actions are completed successfully, then test cleanup
  method goes to home page, and tries to log out - which fails, because
  the test clicks User dropdown menu (in upper right corner) too
  quickly, before the dropdown constructors have been finished by
  bootstrap JS - so the dropdown which contains Log Out link never
  opens.

  This sometimes happens not only with log out link (if that was true,
  we could simply workaround it), but for some other dropdowns as well,
  but the failure rate with other dropdowns is lower - simply because
  they operated less frequently than Log Out link (which is present in
  every test).

  The desired solution here is to wait until dropdowns become truly
  clickable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1594926/+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 1589221] Re: Nova-compute: "ImageNotFound: Image could not be found."

2016-06-21 Thread Junaid Ali
** Also affects: nova
   Importance: Undecided
   Status: New

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

Title:
  Nova-compute: "ImageNotFound: Image  could not be found."

Status in OpenStack Compute (nova):
  New
Status in nova-compute package in Juju Charms Collection:
  New

Bug description:
  Spawning a new instance using a newly created image most of the time
  fails. After 2-3 attempts, the problem gets resolved.

  The configs that I'm using in my HA-environment are:
  nova-compute:
  enable-live-migration: "True"
  enable-resize: "True"
  openstack-origin: "cloud:trusty-mitaka"
  migration-auth-type: "ssh"
  manage-neutron-plugin-legacy-mode: False
  glance:
  openstack-origin: "cloud:trusty-mitaka"
  region: "serverstack"
  vip: 
  nova-cloud-controller:
  network-manager: "Neutron"
  console-access-protocol: "novnc"
  openstack-origin: "cloud:trusty-mitaka"
  region: "serverstack"
  vip: 

  I have one compute. Compute logs: http://paste.ubuntu.com/17026140/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1589221/+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 1594898] [NEW] functional DB tests based on SqlFixture don't actually use non-sqlite DB

2016-06-21 Thread Mike Bayer
Public bug reported:

Currently only neutron/tests/functional/db/test_ipam.py seems to use
this fixture, however it is not interacting correctly with oslo.db such
that it actually uses the engine set up by oslo.

Add a test like this:

diff --git a/neutron/tests/functional/db/test_ipam.py 
b/neutron/tests/functional/db/test_ipam.py
index 0f28f74..d14bf6e 100644
--- a/neutron/tests/functional/db/test_ipam.py
+++ b/neutron/tests/functional/db/test_ipam.py
@@ -156,8 +156,8 @@ class IpamTestCase(base.BaseTestCase):
 
 
 class TestIpamMySql(common_base.MySQLTestCase, IpamTestCase):
-pass
-
+def test_we_are_on_mysql(self):
+self.cxt.session.execute("SELECT CURDATE()")
 
 class TestIpamPsql(common_base.PostgreSQLTestCase, IpamTestCase):
 pass


then run:

[classic@photon2 neutron]$  tox -e functional 
neutron.tests.functional.db.test_ipam
functional develop-inst-nodeps: /home/classic/dev/redhat/openstack/neutron
functional installed:  ( ... output skipped ... )
functional runtests: PYTHONHASHSEED='545881821'
functional runtests: commands[0] | 
/home/classic/dev/redhat/openstack/neutron/tools/ostestr_compat_shim.sh 
neutron.tests.functional.db.test_ipam

( ... output skipped ... )

{3} neutron.tests.functional.db.test_ipam.IpamTestCase.test_allocate_fixed_ip 
[1.510751s] ... ok
{1} neutron.tests.functional.db.test_ipam.TestIpamMySql.test_allocate_fixed_ip 
[1.822431s] ... ok
{2} 
neutron.tests.functional.db.test_ipam.IpamTestCase.test_allocate_ip_exausted_pool
 [2.468420s] ... ok
{1} 
neutron.tests.functional.db.test_ipam.TestIpamPsql.test_allocate_ip_exausted_pool
 ... SKIPPED: backend 'postgresql' unavailable
{0} 
neutron.tests.functional.db.test_ipam.TestIpamMySql.test_allocate_ip_exausted_pool
 [2.873318s] ... ok
{2} neutron.tests.functional.db.test_ipam.TestIpamMySql.test_we_are_on_mysql 
[0.993651s] ... FAILED
{0} neutron.tests.functional.db.test_ipam.TestIpamPsql.test_allocate_fixed_ip 
... SKIPPED: backend 'postgresql' unavailable
{1} 
neutron.tests.functional.db.test_ipam.TestPluggableIpamMySql.test_allocate_fixed_ip
 [1.133034s] ... ok
{0} 
neutron.tests.functional.db.test_ipam.TestPluggableIpamPsql.test_allocate_ip_exausted_pool
 ... SKIPPED: backend 'postgresql' unavailable
{2} 
neutron.tests.functional.db.test_ipam.TestPluggableIpamPsql.test_allocate_fixed_ip
 ... SKIPPED: backend 'postgresql' unavailable
{3} 
neutron.tests.functional.db.test_ipam.TestPluggableIpamMySql.test_allocate_ip_exausted_pool
 [2.740086s] ... ok

==
Failed 1 tests - output below:
==

neutron.tests.functional.db.test_ipam.TestIpamMySql.test_we_are_on_mysql


Captured traceback:
~~~
Traceback (most recent call last):
  File "neutron/tests/functional/db/test_ipam.py", line 160, in 
test_we_are_on_mysql
self.cxt.session.execute("SELECT CURDATE()")
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/orm/session.py",
 line 1034, in execute
bind, close_with_result=True).execute(clause, params or {})
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 914, in execute
return meth(self, multiparams, params)
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/sql/elements.py",
 line 323, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1010, in _execute_clauseelement
compiled_sql, distilled_params
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1146, in _execute_context
context)
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1337, in _handle_dbapi_exception
util.raise_from_cause(newraise, exc_info)
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/util/compat.py",
 line 202, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1139, in _execute_context
context)
  File 
"/home/classic/dev/redhat/openstack/neutron/.tox/functional/lib/python2.7/site-packages/sqlalchemy/engine/default.py",
 line 450, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) no such 
function: CURDATE [SQL: u'SELECT CURDATE()']


At the end there, that's a SQLite error.  You're not 

[Yahoo-eng-team] [Bug 1557495] Re: Possible race conditions when changing image status in v2

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/292855
Committed: 
https://git.openstack.org/cgit/openstack/glance/commit/?id=8708273d485c482007fc0ffafb1549fa2c68dae3
Submitter: Jenkins
Branch:master

commit 8708273d485c482007fc0ffafb1549fa2c68dae3
Author: Mike Fedosin 
Date:   Tue Mar 15 15:15:03 2016 +0300

Fix possible race conditions during status change

To eliminate potential race conditions when image status
is changed it's suggested to use 'from_state' parameter
for 'save' methods everywhere where it's possible.

Also this code prevents image update when status hasn't
been changed in deactivate/reativate methods.

Closes-Bug: #1557495

Change-Id: Ic79224a8686bea6ca79976a7f30e3c87bba4e6ec


** Changed in: glance
   Status: In Progress => Fix Released

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

Title:
  Possible race conditions when changing image status in v2

Status in Glance:
  Fix Released

Bug description:
  Currently Glance architecture (domain model) is affected by possible
  race conditions during image status transition. To eliminate this
  there was introduced a parameter called 'from_state' in 'save' method
  for ImageRepo. Unfortunately it only checks if transition happened
  from 'saving' to 'active':
  
https://github.com/openstack/glance/blob/master/glance/api/v2/image_data.py#L117

  Other cases are still not fixed and it leads to the fact that admin
  can reactivate deleted image and it will have status 'active'. Also
  Glance rewrites the status even if it didn't change. To fix it it's
  suggested to use 'from_state' parameters in other places, where race
  conditions may happen.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1557495/+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 1369465] Re: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend

2016-06-21 Thread Edward Hope-Morley
** Changed in: cloud-archive
   Status: New => Fix Released

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

Title:
  nova resize doesn't resize(extend) rbd disk files when using rbd disk
  backend

Status in Ubuntu Cloud Archive:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) liberty series:
  Fix Committed
Status in nova package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

   * Not able to resize rbd backed disk image.

  [Test Case]

  1 - boot an instance with rbd backed disk image
  2 - resize it
  3 - log into the VM
  4 - the disk is not enlarged without this patch

  [Regression Potential]

   * None

  
  tested with nova trunk commit eb860c2f219b79e4f4c5984415ee433145197570

  Configured Nova to use rbd disk backend

  nova.conf

  [libvirt]
  images_type=rbd

  instances booted successfully and instance disks are in rbd pools,
  when perform a nova resize  to an existing instance,  memory and CPU
  changed to be new flavors but instance disks size doesn't change

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1369465/+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 1594859] Re: Any nova command throws HTTP 503

2016-06-21 Thread Augustina Ragwitz
Hi Erwin, thanks for taking the time to file a bug with Nova. For
support requests, please try the openstack mailing list or the
#openstack channel in IRC.

It looks like some requests made to on cloud.edpsystem.com are timing
out. That looks like a server configuration issue based on the snippet
below. If you have reason to believe this is a bug with Nova, please
feel free to reopen this bug with more detailed logs and/or stack trace.

INFO (connectionpool:213) Starting new HTTP connection (1): cloud.edpsystem.com
DEBUG (connectionpool:393) "GET /v2.1/8b19e7039bdc43408b0d621f554ce320 
HTTP/1.1" 503 100
DEBUG (session:277) RESP: [503] Date: Tue, 21 Jun 2016 14:54:56 GMT Connection: 
keep-alive Content-Type: text/plain; charset=UTF-8 Content-Length: 100 
X-Compute-Request-Id: req-ec9edee7-2e4f
-4ca4-9c2f-549da2fce1bf
RESP BODY: 503 Service Unavailable

** Changed in: nova
   Status: New => Invalid

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

Title:
  Any nova command throws HTTP 503

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Any nova command I get HTTP 503 error:

  $ nova list
  ERROR (ClientException): Unknown Error (HTTP 503) (Request-ID: 
req-db74de5d-b027-4ac0-b628-3c33cf8f7840

  $ nova service-list
  ERROR (ClientException): Unknown Error (HTTP 503) (Request-ID: 
req-819d875e-eb26-405e-baad-76989dcbd843)

  $ nova --debug image-list
  DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token') 
   [54/54]
  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://cloud.edpsystem.com:35357/v3 -H "Accept: application/json" -H 
"User-Agent: keystoneauth1/2.4.1 python-requests/2.9.1 CPython/2.7.5"
  INFO (connectionpool:213) Starting new HTTP connection (1): 
cloud.edpsystem.com
  DEBUG (connectionpool:393) "GET /v3 HTTP/1.1" 200 267
  DEBUG (session:277) RESP: [200] Content-Length: 267 Vary: X-Auth-Token 
Keep-Alive: timeout=5, max=100 Server: Apache/2.4.6 (CentOS) 
OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5 Connection:
  Keep-Alive Date: Tue, 21 Jun 2016 14:54:56 GMT Content-Type: application/json 
x-openstack-request-id: req-608c0e57-54fa-4a9e-9559-713225d459dc
  RESP BODY: {"version": {"status": "stable", "updated": 
"2016-04-04T00:00:00Z", "media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v3+json"}], "id": "v3.
  6", "links": [{"href": "http://cloud.edpsystem.com:35357/v3/;, "rel": 
"self"}]}}

  DEBUG (base:165) Making authentication request to 
http://cloud.edpsystem.com:35357/v3/auth/tokens
  DEBUG (connectionpool:393) "POST /v3/auth/tokens HTTP/1.1" 201 4961
  DEBUG (session:248) REQ: curl -g -i -X GET 
http://cloud.edpsystem.com:8774/v2.1/8b19e7039bdc43408b0d621f554ce320 -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "
  X-Auth-Token: {SHA1}98dba7f25486dedb5fb494a94fe6d61e6a35fc8e"
  INFO (connectionpool:213) Starting new HTTP connection (1): 
cloud.edpsystem.com
  DEBUG (connectionpool:393) "GET /v2.1/8b19e7039bdc43408b0d621f554ce320 
HTTP/1.1" 503 100
  DEBUG (session:277) RESP: [503] Date: Tue, 21 Jun 2016 14:54:56 GMT 
Connection: keep-alive Content-Type: text/plain; charset=UTF-8 Content-Length: 
100 X-Compute-Request-Id: req-ec9edee7-2e4f
  -4ca4-9c2f-549da2fce1bf
  RESP BODY: 503 Service Unavailable

  The server is currently unavailable. Please try again at a later time.


  DEBUG (shell:1082) Unknown Error (HTTP 503) (Request-ID: 
req-ec9edee7-2e4f-4ca4-9c2f-549da2fce1bf)
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 1080, in 
main
  OpenStackComputeShell().main(argv)
File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 914, in 
main
  api_version = api_versions.discover_version(self.cs, api_version)
File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line 
267, in discover_version
  client)
File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line 
248, in _get_server_version_range
  version = client.versions.get_current()
File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 84, 
in get_current
  return self._get_current()
File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 57, 
in _get_current
  return self._get(url, "version")
File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 339, in 
_get
  resp, body = self.api.client.get(url)
File 

[Yahoo-eng-team] [Bug 1594859] [NEW] Any nova command throws HTTP 503

2016-06-21 Thread Erwin
Public bug reported:

Any nova command I get HTTP 503 error:

$ nova list
ERROR (ClientException): Unknown Error (HTTP 503) (Request-ID: 
req-db74de5d-b027-4ac0-b628-3c33cf8f7840

$ nova service-list
ERROR (ClientException): Unknown Error (HTTP 503) (Request-ID: 
req-819d875e-eb26-405e-baad-76989dcbd843)

$ nova --debug image-list
DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token') 
   [54/54]
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://cloud.edpsystem.com:35357/v3 
-H "Accept: application/json" -H "User-Agent: keystoneauth1/2.4.1 
python-requests/2.9.1 CPython/2.7.5"
INFO (connectionpool:213) Starting new HTTP connection (1): cloud.edpsystem.com
DEBUG (connectionpool:393) "GET /v3 HTTP/1.1" 200 267
DEBUG (session:277) RESP: [200] Content-Length: 267 Vary: X-Auth-Token 
Keep-Alive: timeout=5, max=100 Server: Apache/2.4.6 (CentOS) 
OpenSSL/1.0.1e-fips mod_wsgi/3.4 Python/2.7.5 Connection:
Keep-Alive Date: Tue, 21 Jun 2016 14:54:56 GMT Content-Type: application/json 
x-openstack-request-id: req-608c0e57-54fa-4a9e-9559-713225d459dc
RESP BODY: {"version": {"status": "stable", "updated": "2016-04-04T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 
"application/vnd.openstack.identity-v3+json"}], "id": "v3.
6", "links": [{"href": "http://cloud.edpsystem.com:35357/v3/;, "rel": "self"}]}}

DEBUG (base:165) Making authentication request to 
http://cloud.edpsystem.com:35357/v3/auth/tokens
DEBUG (connectionpool:393) "POST /v3/auth/tokens HTTP/1.1" 201 4961
DEBUG (session:248) REQ: curl -g -i -X GET 
http://cloud.edpsystem.com:8774/v2.1/8b19e7039bdc43408b0d621f554ce320 -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "
X-Auth-Token: {SHA1}98dba7f25486dedb5fb494a94fe6d61e6a35fc8e"
INFO (connectionpool:213) Starting new HTTP connection (1): cloud.edpsystem.com
DEBUG (connectionpool:393) "GET /v2.1/8b19e7039bdc43408b0d621f554ce320 
HTTP/1.1" 503 100
DEBUG (session:277) RESP: [503] Date: Tue, 21 Jun 2016 14:54:56 GMT Connection: 
keep-alive Content-Type: text/plain; charset=UTF-8 Content-Length: 100 
X-Compute-Request-Id: req-ec9edee7-2e4f
-4ca4-9c2f-549da2fce1bf
RESP BODY: 503 Service Unavailable

The server is currently unavailable. Please try again at a later time.


DEBUG (shell:1082) Unknown Error (HTTP 503) (Request-ID: 
req-ec9edee7-2e4f-4ca4-9c2f-549da2fce1bf)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 1080, in 
main
OpenStackComputeShell().main(argv)
  File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 914, in main
api_version = api_versions.discover_version(self.cs, api_version)
  File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line 267, 
in discover_version
client)
  File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line 248, 
in _get_server_version_range
version = client.versions.get_current()
  File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 84, 
in get_current
return self._get_current()
  File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 57, 
in _get_current
return self._get(url, "version")
  File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 339, in _get
resp, body = self.api.client.get(url)
  File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 173, 
in get
return self.request(url, 'GET', **kwargs)
  File "/usr/lib/python2.7/site-packages/novaclient/client.py", line 94, in 
request
raise exceptions.from_response(resp, body, url, method)
ClientException: Unknown Error (HTTP 503) (Request-ID: 
req-ec9edee7-2e4f-4ca4-9c2f-549da2fce1bf)
ERROR (ClientException): Unknown Error (HTTP 503) (Request-ID: 
req-ec9edee7-2e4f-4ca4-9c2f-549da2fce1bf)


Same situation in the dashboard, I'm getting " Error: Unable to retrieve
images."


However, if I will issue command using openstack/glance and cinder cli
such as:

$ openstack image list
+--+-++
| ID   | Name| Status |
+--+-++
| 680a4b72-0ed0-4b11-9f60-9dd9d0fed033 | centos7-x86_64-test | active |
| 1d151947-cd60-47e9-a773-19c72054dcb6 | centos7-x86_64  | active |
| 0522ee9c-e6c0-449f-bd6e-a8ab7386acfe | cirros  | active |

$ glance image-list
+--+-+
| ID   | Name|
+--+-+
| 

[Yahoo-eng-team] [Bug 1594592] Re: federated_user table failed db unit test if db engine is MyISAM

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/331872
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=48ccf751ac726638db7aeb8288c457388e870ea9
Submitter: Jenkins
Branch:master

commit 48ccf751ac726638db7aeb8288c457388e870ea9
Author: guang-yee 
Date:   Mon Jun 20 15:20:53 2016 -0700

Make sure to use InnoDB as the DB engine

For certain Fedora based systems the MySQL default DB engine is MyISAM.
Therefore, the MySQLOpportunisticUpgradeTestCase functional test suite
will fail because of MyISAM's known limitations. We've already established
a pattern to mitigate this problem, which is to simply force the upgrade
scripts to use InnoDB engine explicitly.

Change-Id: Idd20ea7f0f0a41c01d62b8730c7bd4ed6ecd6486
Closes-Bug: 1594592


** Changed in: keystone
   Status: In Progress => Fix Released

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

Title:
  federated_user table failed db unit test if db engine is MyISAM

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  094_add_federated_user_table.py failed functional test if the default
  db engine is MyISAM for MySQL. We need to follow the established
  pattern of adding the following

  mysql_engine='InnoDB',
  mysql_charset='utf8'

  to the script during table creation.

  Here's an example of one of the failures.

  
keystone.tests.unit.test_sql_upgrade.MySQLOpportunisticUpgradeTestCase.test_migration_96_constraint_exists
  
--

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "keystone/tests/unit/test_sql_upgrade.py", line 1113, in 
test_migration_96_constraint_exists
  self.upgrade(95)
File "keystone/tests/unit/test_sql_upgrade.py", line 262, in upgrade
  self._migrate(*args, **kwargs)
File "keystone/tests/unit/test_sql_upgrade.py", line 276, in _migrate
  self.schema_.runchange(ver, change, changeset.step)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py",
 line 93, in runchange
  change.run(self.engine, step)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py",
 line 148, in run
  script_func(engine)
File 
"/home/gyee/projects/keystone/keystone/common/sql/migrate_repo/versions/094_add_federated_user_table.py",
 line 39, in upgrade
  federated_table.create(migrate_engine, checkfirst=True)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/schema.py",
 line 725, in create
  checkfirst=checkfirst)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1856, in _run_visitor
  conn._run_visitor(visitorcallable, element, **kwargs)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1481, in _run_visitor
  **kwargs).traverse_single(element)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/visitors.py",
 line 121, in traverse_single
  return meth(obj, **kw)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py",
 line 764, in visit_table
  include_foreign_key_constraints=include_foreign_key_constraints
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 914, in execute
  return meth(self, multiparams, params)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/sql/ddl.py",
 line 68, in _execute_on_connection
  return connection._execute_ddl(self, multiparams, params)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 968, in _execute_ddl
  compiled
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1146, in _execute_context
  context)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py",
 line 1337, in _handle_dbapi_exception
  util.raise_from_cause(newraise, exc_info)
File 
"/home/gyee/projects/keystone/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py",
 line 202, in raise_from_cause
  reraise(type(exception), exception, tb=exc_tb, cause=cause)
File 

[Yahoo-eng-team] [Bug 1572341] Re: Failed migration 90 -> 91 Can't DROP 'ixu_user_name_domain_id'

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/329855
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=8c2412adecc08e7bcb07a3c679fcb45fdc06aeb7
Submitter: Jenkins
Branch:master

commit 8c2412adecc08e7bcb07a3c679fcb45fdc06aeb7
Author: Liam Young 
Date:   Wed Jun 15 10:01:43 2016 +

Correct domain_id and name constraint dropping

The 'domain_id' and 'name' unique constraint was not properly dropped
in some cases because the unique constraint was not consistently
named. In all cases we must search for the constraint expected,
not assume the name of the constraint will be consistent
(especially from older installs that have been moved forward in
releases). This fix is modeled on the fix for a similair issue
authored by Morgan Fainberg & Matthew Thode for Bug #1562934

Migration 091:
Fix to broken migration to prevent failed migrations when database is
upgraded from Kilo (or below) to Mitaka
Migration 097:
Ensure that when Mitaka point release is applied the constraint and 
tables
have been dropped if migration 91 was previously worked around.
Migration 104:
Ensure that when upgrading to Newton the constraint and tables
have been dropped if migration 91 was previously worked around.

Migration 91 drops 3 columns from the user table after the code to disable
the constraint. I have included code in migrations 97 and 104 to also drop
those columns if they are still present in case they were missed when 
working
around Bug #1572341. This may be over kill.

Change-Id: I076d7139b388e30be8826d0a4550256b5617d992
Closes-bug: #1572341


** Changed in: keystone
   Status: In Progress => Fix Released

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

Title:
  Failed migration 90 -> 91 Can't DROP 'ixu_user_name_domain_id'

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Get the following error running DB migration when  upgrading from kilo
  -> mitaka

  2016-04-20 09:31:37.560 10471 INFO migrate.versioning.api [-] 90 -> 91... 
  2016-04-20 09:31:37.822 10471 CRITICAL keystone [-] OperationalError: 
(_mysql_exceptions.OperationalError) (1091, "Can't DROP 
'ixu_user_name_domain_id'; check that column/key exists") [SQL: u'ALTER TABLE 
user DROP INDEX ixu_user_name_domain_id']
  2016-04-20 09:31:37.822 10471 ERROR keystone Traceback (most recent call 
last):
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/usr/bin/keystone-manage", line 10, in 
  2016-04-20 09:31:37.822 10471 ERROR keystone sys.exit(main())
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/keystone/keystone/cmd/manage.py", line 47, in main
  2016-04-20 09:31:37.822 10471 ERROR keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/keystone/keystone/cmd/cli.py", line 992, in main
  2016-04-20 09:31:37.822 10471 ERROR keystone CONF.command.cmd_class.main()
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/keystone/keystone/cmd/cli.py", line 371, in main
  2016-04-20 09:31:37.822 10471 ERROR keystone 
migration_helpers.sync_database_to_version(extension, version)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/keystone/keystone/common/sql/migration_helpers.py", line 210, in 
sync_database_to_version
  2016-04-20 09:31:37.822 10471 ERROR keystone _sync_common_repo(version)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/keystone/keystone/common/sql/migration_helpers.py", line 136, in 
_sync_common_repo
  2016-04-20 09:31:37.822 10471 ERROR keystone init_version=init_version, 
sanity_check=False)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/mitaka/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/migration.py",
 line 79, in db_sync
  2016-04-20 09:31:37.822 10471 ERROR keystone migration = 
versioning_api.upgrade(engine, repository, version)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/api.py", line 
186, in upgrade
  2016-04-20 09:31:37.822 10471 ERROR keystone return _migrate(url, 
repository, version, upgrade=True, err=err, **opts)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File "", 
line 2, in _migrate
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/util/__init__.py",
 line 160, in with_engine
  2016-04-20 09:31:37.822 10471 ERROR keystone return f(*a, **kw)
  2016-04-20 09:31:37.822 10471 ERROR keystone   File 
"/opt/mitaka/local/lib/python2.7/site-packages/migrate/versioning/api.py", line 
366, in _migrate
  2016-04-20 09:31:37.822 10471 ERROR keystone schema.runchange(ver, 
change, 

[Yahoo-eng-team] [Bug 1582279] Re: Glance (swift) download broken after Kilo to Liberty Upgrade

2016-06-21 Thread Bjoern Teipel
** Changed in: openstack-ansible
   Status: In Progress => Fix Committed

** Changed in: openstack-ansible
   Status: Fix Committed => Fix Released

** Changed in: glance
   Status: New => Invalid

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

Title:
  Glance (swift) download broken after Kilo to Liberty Upgrade

Status in Glance:
  Invalid
Status in openstack-ansible:
  Fix Released

Bug description:
  After upgrading a Kilo environment to Liberty I noticed the issue that
  I can not download all glance images backed by swift when they were
  using Keystone v2 API and getting a 401 wrapped into a 404 swift
  error:

  2016-05-13 17:45:51.253 4708 ERROR swiftclient [req-4a041b13-2081-45b4
  -a4dd-f2b1473f9be3 a451fa41b56848a9be6a16a7b4dfe239
  7a1ca9f7cc4e4b13ac0ed2957f1e8c32 - - -] Authorization Failure.
  Authorization failed: The resource could not be found. (HTTP 404)
  (Request-ID: req-dfa80296-9d5c-487f-bbd4-64c91cf819cf) (HTTP 404)

  2016-05-13 17:45:51.253 4708 ERROR swiftclient Traceback (most recent call 
last):
  2016-05-13 17:45:51.253 4708 ERROR swiftclient   File 
"/openstack/venvs/glance-12.0.13/lib/python2.7/site-packages/swiftclient/client.py",
 line 1413, in _retry
  2016-05-13 17:45:51.253 4708 ERROR swiftclient self.url, self.token = 
self.get_auth()
  2016-05-13 17:45:51.253 4708 ERROR swiftclient   File 
"/openstack/venvs/glance-12.0.13/lib/python2.7/site-packages/swiftclient/client.py",
 line 1367, in get_auth
  2016-05-13 17:45:51.253 4708 ERROR swiftclient timeout=self.timeout)
  2016-05-13 17:45:51.253 4708 ERROR swiftclient   File 
"/openstack/venvs/glance-12.0.13/lib/python2.7/site-packages/swiftclient/client.py",
 line 490, in get_auth
  2016-05-13 17:45:51.253 4708 ERROR swiftclient auth_version=auth_version)
  2016-05-13 17:45:51.253 4708 ERROR swiftclient   File 
"/openstack/venvs/glance-12.0.13/lib/python2.7/site-packages/swiftclient/client.py",
 line 418, in get_auth_keystone
  2016-05-13 17:45:51.253 4708 ERROR swiftclient raise 
ClientException('Authorization Failure. %s' % err)
  2016-05-13 17:45:51.253 4708 ERROR swiftclient ClientException: Authorization 
Failure. Authorization failed: The resource could not be found. (HTTP 404) 
(Request-ID: req-dfa80296-9d5c-487f-bbd4-64c91cf819cf) (HTTP 404)
  2016-05-13 17:45:51.253 4708 ERROR swiftclient
  2016-05-13 17:45:51.254 4708 WARNING glance.location 
[req-4a041b13-2081-45b4-a4dd-f2b1473f9be3 a451fa41b56848a9be6a16a7b4dfe239 
7a1ca9f7cc4e4b13ac0ed2957f1e8c32 - - -] Get image 
95576f28-afed-4b63-93b4-1d07928930da data failed: Authorization Failure. 
Authorization failed: The resource could not be found. (HTTP 404) (Request-ID: 
req-dfa80296-9d5c-487f-bbd4-64c91cf819cf) (HTTP 404).

  2016-05-13 17:45:51.254 4708 ERROR glance.location [req-
  4a041b13-2081-45b4-a4dd-f2b1473f9be3 a451fa41b56848a9be6a16a7b4dfe239
  7a1ca9f7cc4e4b13ac0ed2957f1e8c32 - - -] Glance tried all active
  locations to get data for image 95576f28-afed-4b63-93b4-1d07928930da
  but all have failed.

  2016-05-13 17:45:51.256 4708 INFO eventlet.wsgi.server 
[req-4a041b13-2081-45b4-a4dd-f2b1473f9be3 a451fa41b56848a9be6a16a7b4dfe239 
7a1ca9f7cc4e4b13ac0ed2957f1e8c32 - - -] Traceback (most recent call last):
    File 
"/openstack/venvs/glance-12.0.13/lib/python2.7/site-packages/eventlet/wsgi.py", 
line

  On further debugging I noticed that the swift client tried to retrieve
  a token from a Keystone v3 URL on a v2 API endpoint:

  POST /v2.0/auth/tokens HTTP/1.1
  Host: 1.2.3.4:5000
  Content-Length: 254
  Accept-Encoding: gzip, deflate
  Accept: application/json
  User-Agent: python-keystoneclient
  Connection: keep-alive
  Content-Type: application/json

  {"auth": {"scope": {"project": {"domain": {"id": "default"}, "name": 
"service"}}, "identity": {"password": {"user": {"domain": {"id": "default"}, 
"password": "x"
  , "name": "glance"}}, "methods": ["password"]}}}

  HTTP/1.1 404 Not Found
  Date: Fri, 13 May 2016 22:54:23 GMT
  Server: Apache
  Vary: X-Auth-Token
  x-openstack-request-id: req-22a9f19a-e72c-4f22-87d3-c3f25fb78a9f
  Content-Length: 93
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: application/json

  {"error": {"message": "The resource could not be found.", "code": 404,
  "title": "Not Found"}}

  which seems to be related to the config change
  swift_store_auth_version from 2 in Kilo to 3 in Liberty.

  Current Glance config

  default_store = swift
  stores = swift,http,cinder
  swift_store_auth_version = 3
  swift_store_auth_address = http://1.2.3.4:5000/v3
  swift_store_auth_insecure = False
  swift_store_user = service:glance
  swift_store_key = x
  swift_store_region = RegionOne
  swift_store_container = glance_images
  swift_store_endpoint_type = internalURL

  To overcome this issue I updated all glance image_locations to point
  to a V3 keystone 

[Yahoo-eng-team] [Bug 1586253] Re: [RFE] Add VPNaaS support for OVN networking

2016-06-21 Thread Kyle Mestery
I don't think we should allow new features into VPN while the current
VPN CI is a giant disaster and the team isn't focusing on fixing that.
So I agree with armax in that settling VPN itself should be more
important here.

** Also affects: networking-ovn
   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/1586253

Title:
  [RFE] Add VPNaaS support for OVN networking

Status in networking-ovn:
  Confirmed
Status in neutron:
  Confirmed

Bug description:
  Problem Description

  Currently VPNaaS service plugin only has support for the reference
  Neutron software routers, such as neutron L3 router. It can't work
  together with OVN distributed router.

  Proposed Change

  Add a new VPN agent to support VPN+OVN, the new VPN agent can support
  any distributed router solution. Together with the new agent, changes
  for VPNaaS plugin service driver are also needed. This will have no
  impact on existing VPN solution. The existing VPN agent can still work
  with neutron l3 router. This does not need any changes for OVN l3
  plugin. So it is compatible with current OVN L3 plugin.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-ovn/+bug/1586253/+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 1594812] [NEW] domain + ldap configuration breaks ability to add admin user to admin project

2016-06-21 Thread Christiaan
Public bug reported:

Ubuntu 16.04 LTS with Mitaka installation from ubuntu repo packages.

All seems to work until I tested keystone using domain configurations +
ldap

With the following configuration enabled:

domain_specific_drivers_enabled = true
domain_configurations_from_database = false

I am only able to create a role, project and user.

When I try using assignment to assign the user to the project with role admin 
it fails. 
root@supafly /home/chris $ openstack role add --domain default --user admin 
admin
Could not find resource admin

But I was able to successfully create the user and its visible in the
LDAP database using the openstack python cli.

When I try login with the user admin that I created, i get an error user
not assigned to any domains or projects.

So I disabled domain_Sepcific_drivers_enabled by setting it to false:
domain_specific_drivers_enabled = false

I tried to create the user again, which was also succesfully.
Then when I tried to assign role it worked fine.

However does not work with domain_specific_drivers_enabled.

>From my understanding is if I remove the domain_specific_configuration
file /etc/keystone/keystone_default.conf

Then login with domain default then it should not be using LDAP. Since
the driver is only set to LDAP within the domain specific configuration.
It should then be using SQL. But the results are exactly the same. So
its something related to enable the domain_specific_configuration.

Please advice what output is necessary.

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  domain + ldap configuration breaks ability to add admin user to admin
  project

Status in OpenStack Identity (keystone):
  New

Bug description:
  Ubuntu 16.04 LTS with Mitaka installation from ubuntu repo packages.

  All seems to work until I tested keystone using domain configurations
  + ldap

  With the following configuration enabled:

  domain_specific_drivers_enabled = true
  domain_configurations_from_database = false

  I am only able to create a role, project and user.

  When I try using assignment to assign the user to the project with role admin 
it fails. 
  root@supafly /home/chris $ openstack role add --domain default --user admin 
admin
  Could not find resource admin

  But I was able to successfully create the user and its visible in the
  LDAP database using the openstack python cli.

  When I try login with the user admin that I created, i get an error
  user not assigned to any domains or projects.

  So I disabled domain_Sepcific_drivers_enabled by setting it to false:
  domain_specific_drivers_enabled = false

  I tried to create the user again, which was also succesfully.
  Then when I tried to assign role it worked fine.

  However does not work with domain_specific_drivers_enabled.

  From my understanding is if I remove the domain_specific_configuration
  file /etc/keystone/keystone_default.conf

  Then login with domain default then it should not be using LDAP. Since
  the driver is only set to LDAP within the domain specific
  configuration. It should then be using SQL. But the results are
  exactly the same. So its something related to enable the
  domain_specific_configuration.

  Please advice what output is necessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1594812/+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 1594810] [NEW] Remove deprecated config options for default subnetpools

2016-06-21 Thread John Davidge
Public bug reported:

These options were deprecated in the Mitaka cycle by
https://review.openstack.org/#/c/230983/

They can now be removed in Newton.

** Affects: neutron
 Importance: Undecided
 Assignee: John Davidge (john-davidge)
 Status: In Progress


** Tags: deprecation

** Changed in: neutron
 Assignee: (unassigned) => John Davidge (john-davidge)

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

Title:
  Remove deprecated config options for default subnetpools

Status in neutron:
  In Progress

Bug description:
  These options were deprecated in the Mitaka cycle by
  https://review.openstack.org/#/c/230983/

  They can now be removed in Newton.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1594810/+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 1594795] [NEW] AttributeError: 'unicode' object has no attribute 'get'

2016-06-21 Thread Turbo Fredriksson
Public bug reported:

I'm getting this when running

  openstack flavor list

and many other commands. Running with --debug, I see:

  Making authentication request to http://control:35357/v3/auth/tokens
  "POST /v3/auth/tokens HTTP/1.1" 201 11701
  run(Namespace(all=False, columns=[], formatter='table', limit=None, 
long=False, marker=None, max_width=0, noindent=False, public=True, 
quote_mode='nonnumeric'))
  Instantiating compute client for VAPI Version Major: 2, Minor: 0
  Making authentication request to http://control:35357/v3/auth/tokens
  "POST /v3/auth/tokens HTTP/1.1" 201 11701
  REQ: curl -g -i -X GET 
http://10.0.4.1:8774/v2/1857a7b08b8046038005b98e8b238843/flavors/detail -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}226eb1000d0f69fb06823fefb599f559729e0969"
  Starting new HTTP connection (1): 10.0.4.1
  "GET /v2/1857a7b08b8046038005b98e8b238843/flavors/detail HTTP/1.1" 503 170
  RESP: [503] Content-Length: 170 Content-Type: application/json; charset=UTF-8 
X-Compute-Request-Id: req-f296672e-afa4-455a-ab14-2d9749658521 Date: Tue, 21 
Jun 2016 12:33:58 GMT Connection: keep-alive
  RESP BODY: {"message": "The server is currently unavailable. Please try again 
at a later time.\n\n\n", "code": "503 Service Unavailable", 
"title": "Service Unavailable"}

So it would be "nice" (!!) if it could actually SAY that - that it can't
connect to the service! Not just some descriptive Python code error.

** Affects: nova
 Importance: Undecided
 Status: New

** Description changed:

  I'm getting this when running
  
-   openstack flavor list
+   openstack flavor list
  
  and many other commands. Running with --debug, I see:
  
-   Making authentication request to 
http://openstack.bayour.com:35357/v3/auth/tokens
-   "POST /v3/auth/tokens HTTP/1.1" 201 11701
-   run(Namespace(all=False, columns=[], formatter='table', limit=None, 
long=False, marker=None, max_width=0, noindent=False, public=True, 
quote_mode='nonnumeric'))
-   Instantiating compute client for VAPI Version Major: 2, Minor: 0
-   Making authentication request to 
http://openstack.bayour.com:35357/v3/auth/tokens
-   "POST /v3/auth/tokens HTTP/1.1" 201 11701
-   REQ: curl -g -i -X GET 
http://10.0.4.1:8774/v2/1857a7b08b8046038005b98e8b238843/flavors/detail -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}226eb1000d0f69fb06823fefb599f559729e0969"
-   Starting new HTTP connection (1): 10.0.4.1
-   "GET /v2/1857a7b08b8046038005b98e8b238843/flavors/detail HTTP/1.1" 503 170
-   RESP: [503] Content-Length: 170 Content-Type: application/json; 
charset=UTF-8 X-Compute-Request-Id: req-f296672e-afa4-455a-ab14-2d9749658521 
Date: Tue, 21 Jun 2016 12:33:58 GMT Connection: keep-alive
-   RESP BODY: {"message": "The server is currently unavailable. Please try 
again at a later time.\n\n\n", "code": "503 Service Unavailable", 
"title": "Service Unavailable"}
+   Making authentication request to http://control:35357/v3/auth/tokens
+   "POST /v3/auth/tokens HTTP/1.1" 201 11701
+   run(Namespace(all=False, columns=[], formatter='table', limit=None, 
long=False, marker=None, max_width=0, noindent=False, public=True, 
quote_mode='nonnumeric'))
+   Instantiating compute client for VAPI Version Major: 2, Minor: 0
+   Making authentication request to http://control:35357/v3/auth/tokens
+   "POST /v3/auth/tokens HTTP/1.1" 201 11701
+   REQ: curl -g -i -X GET 
http://10.0.4.1:8774/v2/1857a7b08b8046038005b98e8b238843/flavors/detail -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}226eb1000d0f69fb06823fefb599f559729e0969"
+   Starting new HTTP connection (1): 10.0.4.1
+   "GET /v2/1857a7b08b8046038005b98e8b238843/flavors/detail HTTP/1.1" 503 170
+   RESP: [503] Content-Length: 170 Content-Type: application/json; 
charset=UTF-8 X-Compute-Request-Id: req-f296672e-afa4-455a-ab14-2d9749658521 
Date: Tue, 21 Jun 2016 12:33:58 GMT Connection: keep-alive
+   RESP BODY: {"message": "The server is currently unavailable. Please try 
again at a later time.\n\n\n", "code": "503 Service Unavailable", 
"title": "Service Unavailable"}
  
  So it would be "nice" (!!) if it could actually SAY that - that it can't
  connect to the service! Not just some descriptive Python code error.

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

Title:
  AttributeError: 'unicode' object has no attribute 'get'

Status in OpenStack Compute (nova):
  New

Bug description:
  I'm getting this when running

    openstack flavor list

  and many other commands. Running with --debug, I see:

    Making authentication request to http://control:35357/v3/auth/tokens
    "POST /v3/auth/tokens HTTP/1.1" 201 11701
    run(Namespace(all=False, columns=[], formatter='table', limit=None, 
long=False, marker=None, max_width=0, noindent=False, 

[Yahoo-eng-team] [Bug 1594796] [NEW] test_api_extension_validation_with_good_dns_names fails with 500 error

2016-06-21 Thread Armando Migliaccio
Public bug reported:

The trace:

ft296.52: 
neutron.tests.unit.extensions.test_dns.DnsExtensionTestCase.test_api_extension_validation_with_good_dns_names_StringException:
 Empty attachments:
  pythonlogging:''
  stdout

stderr: {{{
/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/paste/deploy/loadwsgi.py:22:
 DeprecationWarning: Parameters to load are deprecated.  Call .resolve and 
.require separately.
  return pkg_resources.EntryPoint.parse("x=" + s).load(False)
}}}

Traceback (most recent call last):
  File 
"/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/extensions/test_dns.py",
 line 497, in test_api_extension_validation_with_good_dns_names
self.assertEqual(201, res.status_code)
  File 
"/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
 line 411, in assertEqual
self.assertThat(observed, matcher, message)
  File 
"/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
 line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 201 != 500

A few instances:

http://logs.openstack.org/99/331999/2/check/gate-neutron-python34/ecd478b/testr_results.html.gz
http://logs.openstack.org/68/330368/2/check/gate-neutron-python34/f0beed0/testr_results.html.gz

Logstash:

http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22test_api_extension_validation_with_good_dns_names%5C%22

** Affects: neutron
 Importance: Critical
 Status: Confirmed


** Tags: dns gate-failure

** Changed in: neutron
   Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Critical

** Tags added: dns gate-failure

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

Title:
  test_api_extension_validation_with_good_dns_names fails with 500 error

Status in neutron:
  Confirmed

Bug description:
  The trace:

  ft296.52: 
neutron.tests.unit.extensions.test_dns.DnsExtensionTestCase.test_api_extension_validation_with_good_dns_names_StringException:
 Empty attachments:
pythonlogging:''
stdout

  stderr: {{{
  
/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/paste/deploy/loadwsgi.py:22:
 DeprecationWarning: Parameters to load are deprecated.  Call .resolve and 
.require separately.
return pkg_resources.EntryPoint.parse("x=" + s).load(False)
  }}}

  Traceback (most recent call last):
File 
"/home/jenkins/workspace/gate-neutron-python34/neutron/tests/unit/extensions/test_dns.py",
 line 497, in test_api_extension_validation_with_good_dns_names
  self.assertEqual(201, res.status_code)
File 
"/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
 line 411, in assertEqual
  self.assertThat(observed, matcher, message)
File 
"/home/jenkins/workspace/gate-neutron-python34/.tox/py34/lib/python3.4/site-packages/testtools/testcase.py",
 line 498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: 201 != 500

  A few instances:

  
http://logs.openstack.org/99/331999/2/check/gate-neutron-python34/ecd478b/testr_results.html.gz
  
http://logs.openstack.org/68/330368/2/check/gate-neutron-python34/f0beed0/testr_results.html.gz

  Logstash:

  
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22test_api_extension_validation_with_good_dns_names%5C%22

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1594796/+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 1583419] Re: Make dict.keys() PY3 compatible

2016-06-21 Thread Dinesh Bhor
Hi All,

This issue is also present in nova, cinder and python-manilaclient as
well.

nova:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/volumes.py#L71

cinder:
https://github.com/openstack/cinder/blob/master/cinder/backup/manager.py#L128

python-manilaclient:
https://github.com/openstack/python-manilaclient/blob/master/manilaclient/tests/functional/test_shares_metadata.py#L139

** Also affects: cinder
   Importance: Undecided
   Status: New

** Changed in: cinder
 Assignee: (unassigned) => Dinesh Bhor (dinesh-bhor)

** Also affects: python-manilaclient
   Importance: Undecided
   Status: New

** Changed in: python-manilaclient
 Assignee: (unassigned) => Dinesh Bhor (dinesh-bhor)

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: nova
 Assignee: (unassigned) => Dinesh Bhor (dinesh-bhor)

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

Title:
  Make dict.keys() PY3 compatible

Status in Cinder:
  In Progress
Status in OpenStack Compute (nova):
  New
Status in python-cinderclient:
  Fix Released
Status in python-manilaclient:
  In Progress
Status in python-troveclient:
  New

Bug description:
  In PY3, dict.keys() will return a view of list but not a list anymore, i.e.
  $ python3.4
  Python 3.4.3 (default, Mar 31 2016, 20:42:37) 
  >>> body={"11":"22"}
  >>> body[body.keys()[0]]
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: 'dict_keys' object does not support indexing

  so for py3 compatible we should change it as follows:
  >>> body[list(body.keys())[0]]
  '22'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1583419/+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 1540254] Re: "#flake8: noqa" is using incorrectly

2016-06-21 Thread Bhagyashri Shewale
** Also affects: python-saharaclient
   Importance: Undecided
   Status: New

** Changed in: python-saharaclient
 Assignee: (unassigned) => Bhagyashri Shewale (bhagyashri-shewale)

-- 
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/1540254

Title:
  "#flake8: noqa" is using incorrectly

Status in Designate:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Murano:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in Python client library for Sahara:
  New

Bug description:
  "# flake8: noqa" option disables all checks for the whole file. To
  disable one line we should use "# noqa".

  Refer to: https://pypi.python.org/pypi/flake8
  
https://github.com/openstack/python-keystoneclient/commit/3b766c51438396a0ab0032de309c9d56e275e0cb

To manage notifications about this bug go to:
https://bugs.launchpad.net/designate/+bug/1540254/+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 1594760] [NEW] Project switching gets stuck in firefox

2016-06-21 Thread lahari
Public bug reported:

Openstack doesn't log me out in firefox browser. 
I use cache based session-engine
Firefox logs me out intially, but after navigating it
redirects me to the admin page. This doesn't happen with Chrome
The project switcher gets stuck as well in firefox

** Affects: horizon
 Importance: Undecided
 Assignee: lahari (ananda-bhavaraju)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => lahari (ananda-bhavaraju)

** Changed in: horizon
   Status: New => In Progress

-- 
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/1594760

Title:
  Project switching gets stuck in firefox

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Openstack doesn't log me out in firefox browser. 
  I use cache based session-engine
  Firefox logs me out intially, but after navigating it
  redirects me to the admin page. This doesn't happen with Chrome
  The project switcher gets stuck as well in firefox

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1594760/+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 1594756] [NEW] pep8 job runs a single check only

2016-06-21 Thread Jakub Libosvar
Public bug reported:

Due to https://github.com/PyCQA/pycodestyle/issues/390 , we now run only
check that makes sure we use unittest2 instead of unittest.

** 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/1594756

Title:
  pep8 job runs a single check only

Status in neutron:
  New

Bug description:
  Due to https://github.com/PyCQA/pycodestyle/issues/390 , we now run
  only check that makes sure we use unittest2 instead of unittest.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1594756/+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 1586267] Re: python 3.4 support for urlparse

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/322088
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=a70a787a6be16e3bac109a19c957f00295150431
Submitter: Jenkins
Branch:master

commit a70a787a6be16e3bac109a19c957f00295150431
Author: Yatin Kumbhare 
Date:   Fri May 27 15:15:19 2016 +0530

python 3.4 support for urlparse

Instead of using import urlparse
Make use of import six.moves.urllib.parse as urlparse

Change-Id: I8c0a3291c86366838ec53f7f04e1ea63550e631f
Closes-Bug: #1586267


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1586267

Title:
  python 3.4 support for urlparse

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Murano:
  Fix Released
Status in OpenStack Search (Searchlight):
  Fix Released

Bug description:
  Instead of using import urlparse

  Make use of import six.moves.urllib.parse as urlparse

  for python3.4 support into searchlight.

  Similar work pointer from core project:
  https://blueprints.launchpad.net/nova/+spec/nova-python3-newton

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1586267/+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 1593039] Re: a networking-sfc document error

2016-06-21 Thread JianGang Weng
https://review.openstack.org/#/c/330472/

** Changed in: neutron
   Status: Confirmed => Fix Released

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

Title:
  a networking-sfc document error

Status in neutron:
  Fix Released

Bug description:
  
http://docs.openstack.org/developer/networking-sfc/api.html#problem-description
  In this document:
  In order to create a chain, the user needs to have the actual port objects. 
The work flow would typically be:

  1.create the ports
  2.create the chain
  3.boot the vm’s passing the ports as nic’s parameters
  The sequence of b) and c) can be switched.

  I think "The sequence of b) and c) can be switched." change to "The
  sequence of 2) and 3) can be switched." will be better.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593039/+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 1594711] [NEW] Remove the deprecated config "router_id"

2016-06-21 Thread Hong Hui Xiao
Public bug reported:

This option is deprecated at https://review.openstack.org/#/c/248498/ at
M release and can be removed in N release now.

** Affects: neutron
 Importance: Undecided
 Assignee: Hong Hui Xiao (xiaohhui)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Hong Hui Xiao (xiaohhui)

** Description changed:

- This option is removed at https://review.openstack.org/#/c/248498/ at M
- release and can be removed in N release now.
+ This option is deprecated at https://review.openstack.org/#/c/248498/ at
+ M release and can be removed in N release now.

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

Title:
  Remove the deprecated config "router_id"

Status in neutron:
  New

Bug description:
  This option is deprecated at https://review.openstack.org/#/c/248498/
  at M release and can be removed in N release now.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1594711/+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 1577996] Re: Unable to distinguish between not is_admin_project and feature not enabled

2016-06-21 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/331374
Committed: 
https://git.openstack.org/cgit/openstack/keystonemiddleware/commit/?id=0562670d4e56c257aec8db5a2bb651b5e59fddb2
Submitter: Jenkins
Branch:master

commit 0562670d4e56c257aec8db5a2bb651b5e59fddb2
Author: Jamie Lennox 
Date:   Sat Jun 18 09:14:26 2016 +1000

Pass X_IS_ADMIN_PROJECT header from auth_token

To do policy enforcement around admin projects we need for auth_token
middleware to pass this information down to context objects.

Closes-Bug: #1577996
Change-Id: Ic680e6eaa683926914cf4b2152ec3bb67c6601ff


** Changed in: keystonemiddleware
   Status: In Progress => Fix Released

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

Title:
  Unable to distinguish between not is_admin_project and feature not
  enabled

Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Released
Status in oslo.context:
  New
Status in oslo.policy:
  New

Bug description:
  The is_admin_project flag is used in a token to indicate that the
  current token is scoped to a project that is indicated as the admin
  project. Currently this is only added to the token when the
  admin_project is True and nothing added when False.

  From a policy perspective we need to write policy files that are
  backwards compatible, however we cannot determine the difference in
  policy between is_admin_project == False and the admin project not
  being set from config because both result in no flag being set in the
  token.

  If we were to enforce is_admin_project == True on a deployment that
  did not use it this would completely break backwards compatibility as
  the is_admin_project check would never pass.

  To fix this we need to make is_admin_project a required field of a
  token at least when the admin project is set.

  Because the current default is that every project can be the admin
  project, the default value of is_admin_project must be True. For
  deployments that do not configure an admin project we can either set
  is_admin_project=True for every project, or we can exclude the field
  from the token. I think exclude makes sense because the check from a
  policy perspective is going to have to default to True for backwards
  compatibility and you can then tell from a token whether the
  admin_project concept is in use (i'm not sure if this is an
  information leakage problem - please comment on preference).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1577996/+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 1594702] [NEW] The ConsumerBase should be changed into Consumer in trace log

2016-06-21 Thread zhaolihui
Public bug reported:

The ConsumerBase should be changed into Consumer in trace log

** Affects: oslo.messaging
 Importance: Undecided
 Assignee: zhaolihui (zhaolh)
 Status: New

** Project changed: nova => oslo.messaging

** Changed in: oslo.messaging
 Assignee: (unassigned) => zhaolihui (zhaolh)

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

Title:
  The ConsumerBase should be changed into Consumer in trace log

Status in oslo.messaging:
  New

Bug description:
  The ConsumerBase should be changed into Consumer in trace log

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo.messaging/+bug/1594702/+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 1594674] [NEW] glance image size incorrectly shown, when deploying from stack

2016-06-21 Thread Sudheer Kalla
Public bug reported:

Define a parameter with glance.image constraint, something like this:
   test_image_name:
description: Name of the Glance image to create test volumes
type: string
constraints:
  - custom_constraint: glance.image

When deploying this stack, you will be able to choose the available
glance images via a dropdown list, that also states the size of the
glance images.The size shown in the dropdown list is ~1.000.000 times
bigger than the actual value. See attached screenshot.

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "data.png"
   https://bugs.launchpad.net/bugs/1594674/+attachment/4687661/+files/data.png

-- 
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/1594674

Title:
  glance image size incorrectly shown, when deploying from stack

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Define a parameter with glance.image constraint, something like this:
 test_image_name:
  description: Name of the Glance image to create test volumes
  type: string
  constraints:
- custom_constraint: glance.image

  When deploying this stack, you will be able to choose the available
  glance images via a dropdown list, that also states the size of the
  glance images.The size shown in the dropdown list is ~1.000.000 times
  bigger than the actual value. See attached screenshot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1594674/+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