[Yahoo-eng-team] [Bug 1428495] Re: Does not enable ssh even with ssh_enabled: True

2015-03-05 Thread Launchpad Bug Tracker
This bug was fixed in the package cloud-init - 0.7.7~bzr1078-0ubuntu1

---
cloud-init (0.7.7~bzr1078-0ubuntu1) vivid; urgency=medium

  * New upstream snapshot.
* run snappy module only on snappy (LP: #1428495)
* MAAS: adjust timestamp on oauthlib when needed (LP: #1427939)
 -- Scott Moser smo...@ubuntu.com   Thu, 05 Mar 2015 15:22:53 -0500

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed = Fix Released

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

Title:
  Does not enable ssh even with ssh_enabled: True

Status in Init scripts for use on cloud images:
  In Progress
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  The latest cloud images from vivid with cloud-init
  0.7.7~bzr1076-0ubuntu1 now stop enabling ssh by default, as they
  create an /etc/ssh/ssh_not_to_be_run stamp file. Aside from the fact
  that there was no warning about it and it's not documented in the
  changelog or documentation or anywhere, re-enabling also does not seem
  to work. I found the new ssh_enabled key in
  cloudinit/config/cc_snappy.py, but setting it in my user-data (for
  generating a local seed iso) does not work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1428495/+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 1427939] Re: oauthlib code does not adjust timestamp

2015-03-05 Thread Launchpad Bug Tracker
This bug was fixed in the package cloud-init - 0.7.7~bzr1078-0ubuntu1

---
cloud-init (0.7.7~bzr1078-0ubuntu1) vivid; urgency=medium

  * New upstream snapshot.
* run snappy module only on snappy (LP: #1428495)
* MAAS: adjust timestamp on oauthlib when needed (LP: #1427939)
 -- Scott Moser smo...@ubuntu.com   Thu, 05 Mar 2015 15:22:53 -0500

** Changed in: cloud-init (Ubuntu)
   Status: Confirmed = Fix Released

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

Title:
  oauthlib code does not adjust timestamp

Status in Init scripts for use on cloud images:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  in the python3 port, we moved from python-oauth to python-oauthlib.
  That change lost the functionality added to solve bug 978127 
(http://pad.lv/978127).

  We really need to have this in order to do oauth from systems that do
  not have a clock that retains time across reboots.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1427939/+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 1428821] [NEW] n-api fails to start on juno grenade

2015-03-05 Thread gordon chung
Public bug reported:

possibly related to this:
https://github.com/openstack/nova/commit/a657582c5cd8a39580c44ad401fd3e69870068b1

grenade tests are not passing due to n-api not starting

logs here: http://logs.openstack.org/56/161256/1/check/check-grenade-
dsvm/6fb9bfa/logs/

from n-api log:

2015-03-05 14:04:34.874 10501 INFO nova.openstack.common.service [-] Started 
child 10508
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
timer()
  File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
cb(*args, **kw)
  File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, in 
main
result = function(*args, **kwargs)
TypeError: server() got an unexpected keyword argument 'socket_timeout'
2015-03-05 14:04:34.876 10501 INFO nova.openstack.common.service [-] Started 
child 10509
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
timer()
  File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
cb(*args, **kw)
  File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, in 
main
result = function(*args, **kwargs)
TypeError: server() got an unexpected keyword argument 'socket_timeout'
2015-03-05 14:04:34.878 10501 INFO nova.openstack.common.service [-] Started 
child 10510
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
timer()
  File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
cb(*args, **kw)
  File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, in 
main
result = function(*args, **kwargs)
TypeError: server() got an unexpected keyword argument 'socket_timeout'

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

Title:
  n-api fails to start on juno grenade

Status in OpenStack Compute (Nova):
  New

Bug description:
  possibly related to this:
  
https://github.com/openstack/nova/commit/a657582c5cd8a39580c44ad401fd3e69870068b1

  grenade tests are not passing due to n-api not starting

  logs here: http://logs.openstack.org/56/161256/1/check/check-grenade-
  dsvm/6fb9bfa/logs/

  from n-api log:

  2015-03-05 14:04:34.874 10501 INFO nova.openstack.common.service [-] Started 
child 10508
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
  timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
  cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, 
in main
  result = function(*args, **kwargs)
  TypeError: server() got an unexpected keyword argument 'socket_timeout'
  2015-03-05 14:04:34.876 10501 INFO nova.openstack.common.service [-] Started 
child 10509
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
  timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
  cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, 
in main
  result = function(*args, **kwargs)
  TypeError: server() got an unexpected keyword argument 'socket_timeout'
  2015-03-05 14:04:34.878 10501 INFO nova.openstack.common.service [-] Started 
child 10510
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
  timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
  cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, 
in main
  result = function(*args, **kwargs)
  TypeError: server() got an unexpected keyword argument 'socket_timeout'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428821/+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 1428774] Re: Neutron-LBaaS: Stats Call API Spec mismatch with Actual Response

2015-03-05 Thread Franklin Naval
** Changed in: neutron
   Status: New = 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/1428774

Title:
  Neutron-LBaaS: Stats Call API Spec mismatch with Actual Response

Status in OpenStack Neutron (virtual network service):
  Fix Released

Bug description:
  
  1.  Create Load Balancer
  2.  Do a stats call
  3.  See response.

  Result:  stats response looks like this:
  {stats: {bytes_in: 0, total_connections: 0, active_connections: 0, 
bytes_out: 0}}

  Expected:  according to api spec,
  
(https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Retrieve_a_specific_Load_Balancer.27s_Statistics)
  it should look like this:

  {
  stats: {
  loadbalancer: {
  total_bytes_in: 0,
  total_bytes_out: 0,
  total_connections: 0,
  total_active_connections: 0,
  }
  }
  }

  Missing 'loadbalancer' attribute.   Or, update the wiki to remove
  'loadbalancer'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428774/+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 1428728] Re: nova.tests.unit.test_context.ContextTestCase.test_store_when_no_overwrite intermittently fails with MismatchError

2015-03-05 Thread Matt Riedemann
Fixed here: https://review.openstack.org/#/c/161784/

** Also affects: oslo.context
   Importance: Undecided
   Status: New

** Changed in: nova
   Status: In Progress = Invalid

** Changed in: oslo.context
   Status: New = Fix Committed

** Changed in: oslo.context
   Importance: Undecided = Critical

** Changed in: oslo.context
 Assignee: (unassigned) = Davanum Srinivas (DIMS) (dims-v)

** Changed in: oslo.context
   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/1428728

Title:
  nova.tests.unit.test_context.ContextTestCase.test_store_when_no_overwrite
  intermittently fails with MismatchError

Status in OpenStack Compute (Nova):
  Invalid
Status in Oslo Context library for OpenStack projects:
  Fix Released

Bug description:
  http://logs.openstack.org/53/155853/16/check/gate-nova-
  python27/1f928bf/console.html#_2015-03-05_15_33_13_116

  2015-03-05 15:33:13.116 | Captured traceback:
  2015-03-05 15:33:13.116 | ~~~
  2015-03-05 15:33:13.116 | Traceback (most recent call last):
  2015-03-05 15:33:13.116 |   File nova/tests/unit/test_context.py, line 
147, in test_store_when_no_overwrite
  2015-03-05 15:33:13.117 | self.assertIs(o_context.get_current(), ctx)
  2015-03-05 15:33:13.117 |   File 
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 382, in assertIs
  2015-03-05 15:33:13.117 | self.assertThat(observed, matcher, message)
  2015-03-05 15:33:13.117 |   File 
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 433, in assertThat
  2015-03-05 15:33:13.117 | raise mismatch_error
  2015-03-05 15:33:13.117 | MismatchError: is not:
  2015-03-05 15:33:13.117 | reference = nova.context.RequestContext object 
at 0x7f610d4b8650
  2015-03-05 15:33:13.117 | actual= nova.context.RequestContext object 
at 0x7f610d4b1410
  2015-03-05 15:33:13.117 | 
  2015-03-05 15:33:13.117 | Traceback (most recent call last):
  2015-03-05 15:33:13.117 | _StringException: Empty attachments:
  2015-03-05 15:33:13.118 |   pythonlogging:''
  2015-03-05 15:33:13.118 |   stderr
  2015-03-05 15:33:13.118 |   stdout

  Looks like it's just this test:

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRmlsZSBcXFwibm92YS90ZXN0cy91bml0L3Rlc3RfY29udGV4dC5weVxcXCIsIGxpbmVcIiBBTkQgYnVpbGRfcXVldWU6XCJnYXRlXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5vdmEtcHl0aG9uMjdcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyNTU3MzEzNzE0NSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==

  18 hits in the last 7 days, 2 different changes in the gate hit on
  this.

  Note that RequestContext doesn't implement __eq__ or __ne__.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428728/+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 1428829] [NEW] Fernet tokens don't return audit_ids

2015-03-05 Thread Lance Bragstad
Public bug reported:

The Fernet token formatters accidentally pop the audit_ids from the
token_data [1]. The audit_ids shouldn't be removed from the token_data
because we need them in the response.

[1]
https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126

** Affects: keystone
 Importance: Medium
 Assignee: Dolph Mathews (dolph)
 Status: In Progress


** Tags: fernet security

** Description changed:

- The Fernet token formatters don't accidentally pop the audit_ids from
- the token_data [1]. The audit_ids shouldn't be removed from the
- token_data because we need them in the response.
- 
+ The Fernet token formatters accidentally pop the audit_ids from the
+ token_data [1]. The audit_ids shouldn't be removed from the token_data
+ because we need them in the response.
  
  [1]
  
https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126

** Tags added: fernet

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

Title:
  Fernet tokens don't return audit_ids

Status in OpenStack Identity (Keystone):
  In Progress

Bug description:
  The Fernet token formatters accidentally pop the audit_ids from the
  token_data [1]. The audit_ids shouldn't be removed from the token_data
  because we need them in the response.

  [1]
  
https://github.com/openstack/keystone/blob/d36e499a837074d65365ffa440470516c64e2ab6/keystone/token/providers/fernet/token_formatters.py#L126

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428829/+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 1428598] Re: Horizon for Manila throws ERROR UNAUTHORIZED notification

2015-03-05 Thread Gary W. Smith
** Changed in: horizon
   Status: New = Invalid

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

Title:
  Horizon for Manila throws ERROR UNAUTHORIZED notification

Status in OpenStack Dashboard (Horizon):
  Invalid
Status in Manila:
  New

Bug description:
  I have devstack setup of stable/juno release  with Manila enabled. 
  Configured with Horizon custom project of Manila. All Manila operations works 
fine with Command line but throws below errors on logging in to Horizon

  Error: Unauthorized: Unable to retrieve share limit information.

  On click of Shares tab throws : 
  Error: Unauthorized: Unable to retrieve share list.
  ×
  Error: Unauthorized: Unable to retrieve snapshot list.
  ×
  Error: Unauthorized: Unable to retrieve share networks
  ×
  Error: Unauthorized: Unable to retrieve security services
  ×
  Error: Unauthorized: Unable to retrieve volume types
  ×
  Error: Unauthorized: Unable to retrieve share servers

  I am using stable/juno version of devstack and manila
  manila_juno version of HORIZON_REPO=https://github.com/NetApp/horizon.git

  Request you to please have a look.

  Have also tried the same with Kilo release as per instructions in
  https://wiki.openstack.org/wiki/Manila/KiloDevstack and Horizon setup
  instruction in
  https://wiki.openstack.org/wiki/Manila/docs/HOWTO_use_manila_with_horizon.

  Gives me same ERROR in horizon

  Regards,
  Vinay P

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428598/+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 1415474] Re: Images and Volumes should be filtered by projects

2015-03-05 Thread Gary W. Smith
Closing this, since it has had no responses in a while. I would prefer
that this change go through the blueprint process since it is a
significant enough change in presentation that warrants some discussion.

** Changed in: horizon
   Status: New = Invalid

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

Title:
  Images and Volumes should be filtered by projects

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  As the admin, I should be able to select any tenant and view the
  instances, networks, and images associated with that tenant w/o
  specifically being a member of that tenant.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1415474/+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 1428887] [NEW] Unable to communicate to floatingip on a same network

2015-03-05 Thread Itsuro Oda
Public bug reported:

If one try to communicate from a tenant network to floatingip which attached to
a port on the same network, the communication fails.


for example, unable to communicate from 10.0.0.3 to 100.0.0.5

  +-   exeternal
  |   100.0.0.0/24
 +++
 | router  |
 +++
  | 10.0.0.0/24
  --+-++   internal
|  |
  10.0.0.3  10.0.0.4 
   (100.0.0.5)
-

Note that ping is not adequate to check connection.
icmp reply is returned thus ping success but the from address is different. 
---
10.0.0.3 host: $ ping 100.0.0.5
PING 100.0.0.5 (100.0.0.5) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=3.45 ms   (must be returned from 
100.0.0.5)
---
(This is because destination address (100.0.0.5) is DNATed to fixed ip 
(10.0.0.4)
on the router, but reply does not go through the router.)

Use TCP/IP (ex. ssh) to check connection.

This problem is a regression cased by https://review.openstack.org/#/c/131905/ .
(it is my fault.)
This maybe not common use case but should be fixed since it was OK before the 
patch.

** Affects: neutron
 Importance: Undecided
 Assignee: Itsuro Oda (oda-g)
 Status: New


** Tags: l3-ipam-dhcp

** Tags added: l3-ipam-dhcp

** Changed in: neutron
 Assignee: (unassigned) = Itsuro Oda (oda-g)

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

Title:
  Unable to communicate to floatingip on a same network

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  If one try to communicate from a tenant network to floatingip which attached 
to
  a port on the same network, the communication fails.

  
  for example, unable to communicate from 10.0.0.3 to 100.0.0.5

+-   exeternal
|   100.0.0.0/24
   +++
   | router  |
   +++
| 10.0.0.0/24
--+-++   internal
  |  |
10.0.0.3  10.0.0.4 
 (100.0.0.5)
  -

  Note that ping is not adequate to check connection.
  icmp reply is returned thus ping success but the from address is different. 
  ---
  10.0.0.3 host: $ ping 100.0.0.5
  PING 100.0.0.5 (100.0.0.5) 56(84) bytes of data.
  64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=3.45 ms   (must be returned 
from 100.0.0.5)
  ---
  (This is because destination address (100.0.0.5) is DNATed to fixed ip 
(10.0.0.4)
  on the router, but reply does not go through the router.)

  Use TCP/IP (ex. ssh) to check connection.

  This problem is a regression cased by 
https://review.openstack.org/#/c/131905/ .
  (it is my fault.)
  This maybe not common use case but should be fixed since it was OK before the 
patch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428887/+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 1428949] [NEW] Fernet tokens do not support domain scopes

2015-03-05 Thread Dolph Mathews
Public bug reported:

Attempting to get a domain-scoped token with the Fernet token provider
returns a token - everything appears to have worked. When validating
that token though, it appears to be unpacked as a project-scoped token,
which ultimately fails.

The short of it is that domain-scope support doesn't really exist yet,
and the current behavior will only work if the hierarchical multitenancy
effort successfully migrates domains to be projects.

** Affects: keystone
 Importance: High
 Assignee: Dolph Mathews (dolph)
 Status: Triaged


** Tags: fernet

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

Title:
  Fernet tokens do not support domain scopes

Status in OpenStack Identity (Keystone):
  Triaged

Bug description:
  Attempting to get a domain-scoped token with the Fernet token provider
  returns a token - everything appears to have worked. When validating
  that token though, it appears to be unpacked as a project-scoped
  token, which ultimately fails.

  The short of it is that domain-scope support doesn't really exist yet,
  and the current behavior will only work if the hierarchical
  multitenancy effort successfully migrates domains to be projects.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428949/+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 1421999] Re: Create Edit Project is Broken

2015-03-05 Thread Gary W. Smith
*** This bug is a duplicate of bug 1421616 ***
https://bugs.launchpad.net/bugs/1421616

** This bug has been marked a duplicate of bug 1421616
   Cannot create project using Horizon - Could not find default role _member_

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

Title:
  Create  Edit Project is Broken

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Goto Identity - Projects and the click on create Project. It gives
  an error An Error occured. Please try again later..

  This is happening because code is not able to find the _member_ user
  in the keystone.

  [Sat Feb 14 18:18:54.223434 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/debug.py, line 
78, in render_node
  [Sat Feb 14 18:18:54.223572 2015] [:error] [pid 8690:tid 140651877480192] 
return node.render(context)
  [Sat Feb 14 18:18:54.223697 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/defaulttags.py, 
line 196, in render
  [Sat Feb 14 18:18:54.223837 2015] [:error] [pid 8690:tid 140651877480192] 
nodelist.append(node.render(context))
  [Sat Feb 14 18:18:54.224005 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/defaulttags.py, 
line 298, in render
  [Sat Feb 14 18:18:54.224158 2015] [:error] [pid 8690:tid 140651877480192] 
match = condition.eval(context)
  [Sat Feb 14 18:18:54.224330 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/defaulttags.py, 
line 867, in eval
  [Sat Feb 14 18:18:54.224517 2015] [:error] [pid 8690:tid 140651877480192] 
return self.value.resolve(context, ignore_failures=True)
  [Sat Feb 14 18:18:54.225774 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/base.py, line 
585, in resolve
  [Sat Feb 14 18:18:54.226659 2015] [:error] [pid 8690:tid 140651877480192] 
obj = self.var.resolve(context)
  [Sat Feb 14 18:18:54.226931 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/base.py, line 
735, in resolve
  [Sat Feb 14 18:18:54.227073 2015] [:error] [pid 8690:tid 140651877480192] 
value = self._resolve_lookup(context)
  [Sat Feb 14 18:18:54.227153 2015] [:error] [pid 8690:tid 140651877480192]   
File /usr/local/lib/python2.7/dist-packages/django/template/base.py, line 
789, in _resolve_lookup
  [Sat Feb 14 18:18:54.227271 2015] [:error] [pid 8690:tid 140651877480192] 
current = current()
  [Sat Feb 14 18:18:54.227349 2015] [:error] [pid 8690:tid 140651877480192]   
File 
/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/workflows/base.py, 
line 439, in has_required_fields
  [Sat Feb 14 18:18:54.227433 2015] [:error] [pid 8690:tid 140651877480192] 
return any(field.required for field in self.action.fields.values())
  [Sat Feb 14 18:18:54.227516 2015] [:error] [pid 8690:tid 140651877480192]   
File 
/opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/workflows/base.py, 
line 368, in action
  [Sat Feb 14 18:18:54.227599 2015] [:error] [pid 8690:tid 140651877480192] 
context)
  [Sat Feb 14 18:18:54.227673 2015] [:error] [pid 8690:tid 140651877480192]   
File 
/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/identity/projects/workflows.py,
 line 204, in __init__
  [Sat Feb 14 18:18:54.227758 2015] [:error] [pid 8690:tid 140651877480192] 
redirect=reverse(INDEX_URL))
  [Sat Feb 14 18:18:54.227848 2015] [:error] [pid 8690:tid 140651877480192]   
File /opt/stack/horizon/openstack_dashboard/wsgi/../../horizon/exceptions.py, 
line 364, in handle
  [Sat Feb 14 18:18:54.227978 2015] [:error] [pid 8690:tid 140651877480192] 
six.reraise(exc_type, exc_value, exc_traceback)
  [Sat Feb 14 18:18:54.228069 2015] [:error] [pid 8690:tid 140651877480192]   
File 
/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/identity/projects/workflows.py,
 line 200, in __init__
  [Sat Feb 14 18:18:54.228155 2015] [:error] [pid 8690:tid 140651877480192] 
raise exceptions.NotFound(msg)
  [Sat Feb 14 18:18:54.228230 2015] [:error] [pid 8690:tid 140651877480192] 
NotFound: Could not find default role _member_ in Keystone

  
  And when i queried Keystone api for the role-list, the _member_  was missing.

  stack@ubuntu:~/devstack$ keystone role-list
  +--+-+
  |id|   name  |
  +--+-+
  | beb167e318c24a91a03b35ceb727691b |  Member |
  | 0e89a82771144ac4997dfd5a3348bbb6 |  ResellerAdmin  |
  | 8b4e346d05164038a17b750c6ea8e5ed |  admin  |
  | 2f096118163e4914bb91fd63283accd5 

[Yahoo-eng-team] [Bug 1428907] [NEW] FWaaS: Fix UT breakage in neutron-fwaas

2015-03-05 Thread vishwanath jayaraman
Public bug reported:

The commit for namespaces in neutron (under review 147744, which is
approved, but awaiting upstreaming), changes the router creation logic.
This breaks the neutron-fwaas unit tests.

** Affects: neutron
 Importance: Undecided
 Assignee: vishwanath jayaraman (vishwanathj)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = vishwanath jayaraman (vishwanathj)

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

Title:
  FWaaS: Fix UT breakage in neutron-fwaas

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  The commit for namespaces in neutron (under review 147744, which is
  approved, but awaiting upstreaming), changes the router creation
  logic. This breaks the neutron-fwaas unit tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428907/+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 1428909] [NEW] Arista L3 Service Plugin decomposition

2015-03-05 Thread Sukhdev Kapur
Public bug reported:

Move back-end drivers for Arista L3 Service Plugin from neutron tree to
stackforge networking-arista project

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

Title:
  Arista L3 Service Plugin decomposition

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  Move back-end drivers for Arista L3 Service Plugin from neutron tree
  to stackforge networking-arista project

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428909/+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 1428821] Re: n-api fails to start on juno grenade

2015-03-05 Thread Joe Gordon
** Also affects: nova/icehouse
   Importance: Undecided
   Status: New

** Changed in: nova/icehouse
   Status: New = In Progress

** Changed in: nova/icehouse
   Importance: Undecided = Critical

** Changed in: nova
   Status: In Progress = Invalid

** Changed in: nova
   Importance: Critical = Undecided

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

Title:
  n-api fails to start on juno grenade

Status in OpenStack Compute (Nova):
  Invalid
Status in OpenStack Compute (nova) icehouse series:
  In Progress

Bug description:
  possibly related to this:
  
https://github.com/openstack/nova/commit/a657582c5cd8a39580c44ad401fd3e69870068b1

  grenade tests are not passing due to n-api not starting

  logs here: http://logs.openstack.org/56/161256/1/check/check-grenade-
  dsvm/6fb9bfa/logs/

  from n-api log:

  2015-03-05 14:04:34.874 10501 INFO nova.openstack.common.service [-] Started 
child 10508
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
  timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
  cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, 
in main
  result = function(*args, **kwargs)
  TypeError: server() got an unexpected keyword argument 'socket_timeout'
  2015-03-05 14:04:34.876 10501 INFO nova.openstack.common.service [-] Started 
child 10509
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
  timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
  cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, 
in main
  result = function(*args, **kwargs)
  TypeError: server() got an unexpected keyword argument 'socket_timeout'
  2015-03-05 14:04:34.878 10501 INFO nova.openstack.common.service [-] Started 
child 10510
  Traceback (most recent call last):
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 346, in 
fire_timers
  timer()
File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in 
__call__
  cb(*args, **kw)
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 194, 
in main
  result = function(*args, **kwargs)
  TypeError: server() got an unexpected keyword argument 'socket_timeout'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428821/+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 1428936] [NEW] ofagent broken with the latest version of ryu

2015-03-05 Thread YAMAMOTO Takashi
Public bug reported:

ofagent broken with the latest version of ryu.

recent versions of ryu stopped populating cfg.CONF with its options as it 
turned out to be a bad idea as a library.
ofagent in neutron juno tree still has references to the options and crashes.

an example of the crash:
http://180.37.183.32/ryuci/30/161930/1/check/check-tempest-dsvm-ofagent/82a5cd9/logs/screen-q-agt.txt.gz

upstream (networking-ofagent) fix:
https://review.openstack.org/#/c/153130/

the relevant Ryu change:
https://github.com/osrg/ryu/commit/305e41f47bf5e51ad5ade1ec1590c965586ed10a

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: openflowagent

** Description changed:

  ofagent broken with the latest version of ryu.
  
  recent versions of ryu stopped populating cfg.CONF with its options as it 
turned out to be a bad idea as a library.
  ofagent in neutron juno tree still has references to the options and crashes.
- for example:
+ 
+ an example of the crash:
  
http://180.37.183.32/ryuci/30/161930/1/check/check-tempest-dsvm-ofagent/82a5cd9/logs/screen-q-agt.txt.gz
  
  upstream (networking-ofagent) fix:
  https://review.openstack.org/#/c/153130/
  
- the relevant change Ryu:
+ the relevant Ryu change:
  https://github.com/osrg/ryu/commit/305e41f47bf5e51ad5ade1ec1590c965586ed10a

** Tags added: openflowagent

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

Title:
  ofagent broken with the latest version of ryu

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  ofagent broken with the latest version of ryu.

  recent versions of ryu stopped populating cfg.CONF with its options as it 
turned out to be a bad idea as a library.
  ofagent in neutron juno tree still has references to the options and crashes.

  an example of the crash:
  
http://180.37.183.32/ryuci/30/161930/1/check/check-tempest-dsvm-ofagent/82a5cd9/logs/screen-q-agt.txt.gz

  upstream (networking-ofagent) fix:
  https://review.openstack.org/#/c/153130/

  the relevant Ryu change:
  https://github.com/osrg/ryu/commit/305e41f47bf5e51ad5ade1ec1590c965586ed10a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428936/+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 1428717] [NEW] Fernet tokens have redundant creation timestamps

2015-03-05 Thread Dolph Mathews
Public bug reported:

The creation time of a Fernet token is actually encoded into the token
twice. One of these should be removed.

In the payload of every fernet token, we insert the creation time as an
integer timestamp. That timestamp gets encrypted along with the rest of
the payload.

In addition, the Fernet format itself encodes a timestamp outside the
payload. See the 64-bit timestamp in the specification:

  https://github.com/fernet/spec/blob/master/Spec.md#token-format

The application-controlled timestamp should be removed in favor of
parsing the creation timestamp out. It requires some bitwise operations,
but this library demonstrates how easy the timestamp is to extract
without having the Fernet encryption key:

  https://pypi.python.org/pypi/keyless_fernet

** Affects: keystone
 Importance: Medium
 Assignee: Dolph Mathews (dolph)
 Status: New


** Tags: fernet

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

Title:
  Fernet tokens have redundant creation timestamps

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The creation time of a Fernet token is actually encoded into the token
  twice. One of these should be removed.

  In the payload of every fernet token, we insert the creation time as
  an integer timestamp. That timestamp gets encrypted along with the
  rest of the payload.

  In addition, the Fernet format itself encodes a timestamp outside the
  payload. See the 64-bit timestamp in the specification:

https://github.com/fernet/spec/blob/master/Spec.md#token-format

  The application-controlled timestamp should be removed in favor of
  parsing the creation timestamp out. It requires some bitwise
  operations, but this library demonstrates how easy the timestamp is to
  extract without having the Fernet encryption key:

https://pypi.python.org/pypi/keyless_fernet

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428717/+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 1428728] [NEW] nova.tests.unit.test_context.ContextTestCase.test_store_when_no_overwrite intermittently fails with MismatchError

2015-03-05 Thread Matt Riedemann
Public bug reported:

http://logs.openstack.org/53/155853/16/check/gate-nova-
python27/1f928bf/console.html#_2015-03-05_15_33_13_116

2015-03-05 15:33:13.116 | Captured traceback:
2015-03-05 15:33:13.116 | ~~~
2015-03-05 15:33:13.116 | Traceback (most recent call last):
2015-03-05 15:33:13.116 |   File nova/tests/unit/test_context.py, line 
147, in test_store_when_no_overwrite
2015-03-05 15:33:13.117 | self.assertIs(o_context.get_current(), ctx)
2015-03-05 15:33:13.117 |   File 
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 382, in assertIs
2015-03-05 15:33:13.117 | self.assertThat(observed, matcher, message)
2015-03-05 15:33:13.117 |   File 
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 433, in assertThat
2015-03-05 15:33:13.117 | raise mismatch_error
2015-03-05 15:33:13.117 | MismatchError: is not:
2015-03-05 15:33:13.117 | reference = nova.context.RequestContext object 
at 0x7f610d4b8650
2015-03-05 15:33:13.117 | actual= nova.context.RequestContext object 
at 0x7f610d4b1410
2015-03-05 15:33:13.117 | 
2015-03-05 15:33:13.117 | Traceback (most recent call last):
2015-03-05 15:33:13.117 | _StringException: Empty attachments:
2015-03-05 15:33:13.118 |   pythonlogging:''
2015-03-05 15:33:13.118 |   stderr
2015-03-05 15:33:13.118 |   stdout

Looks like it's just this test:

http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRmlsZSBcXFwibm92YS90ZXN0cy91bml0L3Rlc3RfY29udGV4dC5weVxcXCIsIGxpbmVcIiBBTkQgYnVpbGRfcXVldWU6XCJnYXRlXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5vdmEtcHl0aG9uMjdcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyNTU3MzEzNzE0NSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==

18 hits in the last 7 days, 2 different changes in the gate hit on this.

Note that RequestContext doesn't implement __eq__ or __ne__.

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

Title:
  nova.tests.unit.test_context.ContextTestCase.test_store_when_no_overwrite
  intermittently fails with MismatchError

Status in OpenStack Compute (Nova):
  New

Bug description:
  http://logs.openstack.org/53/155853/16/check/gate-nova-
  python27/1f928bf/console.html#_2015-03-05_15_33_13_116

  2015-03-05 15:33:13.116 | Captured traceback:
  2015-03-05 15:33:13.116 | ~~~
  2015-03-05 15:33:13.116 | Traceback (most recent call last):
  2015-03-05 15:33:13.116 |   File nova/tests/unit/test_context.py, line 
147, in test_store_when_no_overwrite
  2015-03-05 15:33:13.117 | self.assertIs(o_context.get_current(), ctx)
  2015-03-05 15:33:13.117 |   File 
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 382, in assertIs
  2015-03-05 15:33:13.117 | self.assertThat(observed, matcher, message)
  2015-03-05 15:33:13.117 |   File 
/home/jenkins/workspace/gate-nova-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py,
 line 433, in assertThat
  2015-03-05 15:33:13.117 | raise mismatch_error
  2015-03-05 15:33:13.117 | MismatchError: is not:
  2015-03-05 15:33:13.117 | reference = nova.context.RequestContext object 
at 0x7f610d4b8650
  2015-03-05 15:33:13.117 | actual= nova.context.RequestContext object 
at 0x7f610d4b1410
  2015-03-05 15:33:13.117 | 
  2015-03-05 15:33:13.117 | Traceback (most recent call last):
  2015-03-05 15:33:13.117 | _StringException: Empty attachments:
  2015-03-05 15:33:13.118 |   pythonlogging:''
  2015-03-05 15:33:13.118 |   stderr
  2015-03-05 15:33:13.118 |   stdout

  Looks like it's just this test:

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRmlsZSBcXFwibm92YS90ZXN0cy91bml0L3Rlc3RfY29udGV4dC5weVxcXCIsIGxpbmVcIiBBTkQgYnVpbGRfcXVldWU6XCJnYXRlXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLW5vdmEtcHl0aG9uMjdcIiIsImZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiNjA0ODAwIiwiZ3JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7InVzZXJfaW50ZXJ2YWwiOjB9LCJzdGFtcCI6MTQyNTU3MzEzNzE0NSwibW9kZSI6IiIsImFuYWx5emVfZmllbGQiOiIifQ==

  18 hits in the last 7 days, 2 different changes in the gate hit on
  this.

  Note that RequestContext doesn't implement __eq__ or __ne__.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428728/+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 1428424] Re: Remove use of contextlib.nested

2015-03-05 Thread Sean McGinnis
** Also affects: cinder
   Importance: Undecided
   Status: New

** Changed in: cinder
   Status: New = In Progress

** Changed in: cinder
 Assignee: (unassigned) = Sean McGinnis (sean-mcginnis)

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

Title:
  Remove use of contextlib.nested

Status in Cinder:
  In Progress
Status in OpenStack Image Registry and Delivery Service (Glance):
  New
Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  The contextlib.nested call has been deprecated
  in Python 2.7. This causes DeprecationWarning
  messages in the unit tests.
  
  There are also known issues with contextlib.nested
  that were addressed by the native support for
  multiple with variables. For instance, if the
  first object is created but the second one throws
  an exception, the first object's __exit__ is never
  called. For more information see
  https://docs.python.org/2/library/contextlib.html#contextlib.nested
  contextlib.nested is also not compatible in Python 3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1428424/+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 1428542] [NEW] Live Migration (block_migrate): Disk of instance is too large, with cinder LVM based volume

2015-03-05 Thread Tom Patzig
Public bug reported:

When live migrating (block_migrate), an instance, cinder volumes based on LVM, 
that are attached via iscsi to the compute node, are  included within the 
MigrationPreCheck disk-size calculation. 
Because the cinder iscsi volume is just attached to the migration target node, 
these devices need to be skipped.

In the past only devices with type 'file' got included in that disk_size
calculation; But with commit 5fa74bc0b2ab6fe5149a9b684b4beadb67877622
(Adds ephemeral storage encryption for LVM back-end images ), disks with
type 'block' got included as well, which also includes iscsi devices.

I experienced that with stable juno.

I worked around that with this additional check:

diff --git a/nova/virt/libvirt/driver.py b/nova/virt/libvirt/driver.py
index 0809f09..566b2b2 100644
--- a/nova/virt/libvirt/driver.py
+++ b/nova/virt/libvirt/driver.py
@@ -6000,6 +6000,10 @@ class LibvirtDriver(driver.ComputeDriver):
   'volume', {'path': path, 'target': target})
 continue

+if disk_type == 'block' and path.find('iqn.2010-10.org.openstack') 
 0:
+LOG.debug('skipping disk because it looks like an iscsi 
volume', path)
+continue
+
 # get the real disk size or
 # raise a localized error if image is unavailable
 if disk_type == 'file':


If this is the right place to exclude that disks, I can submit that little 
patch for review. Or you can point me to the right location for that and I'll 
give it a try.

What do you think?

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

Title:
  Live Migration (block_migrate): Disk of instance is too large, with
  cinder LVM based volume

Status in OpenStack Compute (Nova):
  New

Bug description:
  When live migrating (block_migrate), an instance, cinder volumes based on 
LVM, that are attached via iscsi to the compute node, are  included within the 
MigrationPreCheck disk-size calculation. 
  Because the cinder iscsi volume is just attached to the migration target 
node, these devices need to be skipped.

  In the past only devices with type 'file' got included in that
  disk_size calculation; But with commit
  5fa74bc0b2ab6fe5149a9b684b4beadb67877622 (Adds ephemeral storage
  encryption for LVM back-end images ), disks with type 'block' got
  included as well, which also includes iscsi devices.

  I experienced that with stable juno.

  I worked around that with this additional check:

  diff --git a/nova/virt/libvirt/driver.py b/nova/virt/libvirt/driver.py
  index 0809f09..566b2b2 100644
  --- a/nova/virt/libvirt/driver.py
  +++ b/nova/virt/libvirt/driver.py
  @@ -6000,6 +6000,10 @@ class LibvirtDriver(driver.ComputeDriver):
 'volume', {'path': path, 'target': target})
   continue

  +if disk_type == 'block' and 
path.find('iqn.2010-10.org.openstack')  0:
  +LOG.debug('skipping disk because it looks like an iscsi 
volume', path)
  +continue
  +
   # get the real disk size or
   # raise a localized error if image is unavailable
   if disk_type == 'file':

  
  If this is the right place to exclude that disks, I can submit that little 
patch for review. Or you can point me to the right location for that and I'll 
give it a try.

  What do you think?

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428542/+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 1428505] [NEW] Hyper-V: console logging stops if VM reboots by itself

2015-03-05 Thread Petrut Lucian
Public bug reported:

The Hyper-V driver restart VM log workers only in case the instance
power changes are triggered by Nova.

As the driver is unaware of VMs that reboot themselves, the VM logging
will be stopped in the moment the according seial port named pipe is
closed.

The fix consists in emiting and handling instance lifecycle events.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: hyper-v

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

Title:
  Hyper-V: console logging stops if VM reboots by itself

Status in OpenStack Compute (Nova):
  New

Bug description:
  The Hyper-V driver restart VM log workers only in case the instance
  power changes are triggered by Nova.

  As the driver is unaware of VMs that reboot themselves, the VM logging
  will be stopped in the moment the according seial port named pipe is
  closed.

  The fix consists in emiting and handling instance lifecycle events.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428505/+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 1428504] [NEW] Hyper-V: console logging stops if VM reboots by itself

2015-03-05 Thread Petrut Lucian
*** This bug is a duplicate of bug 1428505 ***
https://bugs.launchpad.net/bugs/1428505

Public bug reported:

The Hyper-V driver restart VM log workers only in case the instance
power changes are triggered by Nova.

As the driver is unaware of VMs that reboot themselves, the VM logging
will be stopped in the moment the according seial port named pipe is
closed.

The fix consists in emiting and handling instance lifecycle events.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: hyper-v

** This bug has been marked a duplicate of bug 1428505
   Hyper-V: console logging stops if VM reboots by itself

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

Title:
  Hyper-V: console logging stops if VM reboots by itself

Status in OpenStack Compute (Nova):
  New

Bug description:
  The Hyper-V driver restart VM log workers only in case the instance
  power changes are triggered by Nova.

  As the driver is unaware of VMs that reboot themselves, the VM logging
  will be stopped in the moment the according seial port named pipe is
  closed.

  The fix consists in emiting and handling instance lifecycle events.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428504/+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 1428539] [NEW] nova instance actions don't have finish time

2015-03-05 Thread Eli Qiao
Public bug reported:

taget@taget-ThinkStation-P300:~/devstack$ nova instance-action-list tt2
++--+-++
| Action | Request_ID   | Message | Start_Time  
   |
++--+-++
| create | req-76bac38a-2b04-44cd-a2aa-1b169581c82a | -   | 
2015-03-05T06:50:06.00 |
| stop   | req-6431b956-d790-4f9e-95a7-a25b5e697910 | -   | 
2015-03-05T08:08:26.00 |
| start  | req-0da5a5d1-d9f7-4c97-b2cd-7a652c282597 | -   | 
2015-03-05T08:14:52.00 |
++--+-++

query from db , got the finish time is null.

mysql select * from instance_actions;
+-+-++++--+--+--+--+-+-+-+-+
| created_at  | updated_at  | deleted_at | id | action | 
instance_uuid| request_id   
| user_id  | project_id   | 
start_time  | finish_time | message | deleted |
+-+-++++--+--+--+--+-+-+-+-+
| 2015-03-05 06:42:31 | 2015-03-05 06:42:42 | NULL   |  1 | create | 
8e126d7b-afbe-4d40-b924-57c3e1a64ca8 | req-7ae89424-c3c3-4d04-8f22-23cc96b1edbd 
| 4950987b531840e3b546d72476c3d3c2 | 15e4a8cf15da4271ba4e38b5c40e93cc | 
2015-03-05 06:42:30 | 2015-03-05 06:42:42 | NULL|   0 |
| 2015-03-05 06:50:07 | 2015-03-05 06:50:26 | NULL   |  2 | create | 
a3f69c3c-f922-4418-8464-508d4740f447 | req-76bac38a-2b04-44cd-a2aa-1b169581c82a 
| 4950987b531840e3b546d72476c3d3c2 | 15e4a8cf15da4271ba4e38b5c40e93cc | 
2015-03-05 06:50:06 | 2015-03-05 06:50:26 | NULL|   0 |
| 2015-03-05 08:08:26 | 2015-03-05 08:08:40 | NULL   |  3 | stop   | 
a3f69c3c-f922-4418-8464-508d4740f447 | req-6431b956-d790-4f9e-95a7-a25b5e697910 
| 4950987b531840e3b546d72476c3d3c2 | 15e4a8cf15da4271ba4e38b5c40e93cc | 
2015-03-05 08:08:26 | 2015-03-05 08:08:40 | NULL|   0 |
| 2015-03-05 08:14:52 | 2015-03-05 08:14:53 | NULL   |  4 | start  | 
a3f69c3c-f922-4418-8464-508d4740f447 | req-0da5a5d1-d9f7-4c97-b2cd-7a652c282597 
| 4950987b531840e3b546d72476c3d3c2 | 15e4a8cf15da4271ba4e38b5c40e93cc | 
2015-03-05 08:14:52 | 2015-03-05 08:14:53 | NULL|   0 |
+-+-++++--+--+--+--+-+-+-+-+


the reason is that we save the start_time in compute api layer and for some 
async operations we don't 
have a chance to save the finish time.

but instance_actions_events does, it saves the time by create a event (save it 
in __enter__ and __exit__), we can add
the finish time when instance action event exit , just like what 
instance_action_event did.

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

Title:
  nova instance actions don't have finish time

Status in OpenStack Compute (Nova):
  New

Bug description:
  taget@taget-ThinkStation-P300:~/devstack$ nova instance-action-list tt2
  
++--+-++
  | Action | Request_ID   | Message | Start_Time
 |
  
++--+-++
  | create | req-76bac38a-2b04-44cd-a2aa-1b169581c82a | -   | 
2015-03-05T06:50:06.00 |
  | stop   | req-6431b956-d790-4f9e-95a7-a25b5e697910 | -   | 
2015-03-05T08:08:26.00 |
  | start  | req-0da5a5d1-d9f7-4c97-b2cd-7a652c282597 | -   | 
2015-03-05T08:14:52.00 |
  
++--+-++

  query from db , got the finish time is null.

  mysql select * from instance_actions;
  

[Yahoo-eng-team] [Bug 1428551] [NEW] creating vm may fails with large page vm and ordinary vm on the same numa node

2015-03-05 Thread zhangtralon
Public bug reported:

creating ordinary vm may fails with large page vm and ordinary vm on the
same numa node.

the following scene can reproduce the problem:
1. Assumpt that a host with two numa nodes are used to create vm, and the 
memory of each numa node consists of 5GB huge page and 5GB ordinary page.

2. create a vm with huge page  that use 3GB huge page memory in the host
numa node 0. Now, the usable memory of the host numa node 0 consists of
2GB huge page and 5GB ordinary page.

3. At this time, we create an ordinary numa vm with 6GB and the
NUMATopologyFilter filter may select the host numa node 0. If the host
numa node 0 is selected, the libvirt will report OOM error.

** Affects: nova
 Importance: Undecided
 Status: New

** Description changed:

  creating ordinary vm may fails with large page vm and ordinary vm on the
  same numa node.
  
  the following scene can reproduce the problem:
  1. Assumpt that a host with two numa nodes are used to create vm, and the 
memory of each numa node consists of 5GB huge page and 5GB ordinary page.
  
  2. create a vm with huge page  that use 3GB huge page memory in the host
  numa node 0. Now, the usable memory of the host numa node 0 consists of
  2GB huge page and 5GB ordinary page.
  
- 3. At this time, we create an ordinary numa vm with 6GB and the 
NUMATopologyFilter filter may select the host numa node 0.
- If the host numa node 0 is selected, the libvirt will report OOM error.
+ 3. At this time, we create an ordinary numa vm with 6GB and the
+ NUMATopologyFilter filter may select the host numa node 0. If the host
+ numa node 0 is selected, the libvirt will report OOM 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/1428551

Title:
  creating vm may fails with large page vm and ordinary vm on the same
  numa node

Status in OpenStack Compute (Nova):
  New

Bug description:
  creating ordinary vm may fails with large page vm and ordinary vm on
  the same numa node.

  the following scene can reproduce the problem:
  1. Assumpt that a host with two numa nodes are used to create vm, and the 
memory of each numa node consists of 5GB huge page and 5GB ordinary page.

  2. create a vm with huge page  that use 3GB huge page memory in the
  host numa node 0. Now, the usable memory of the host numa node 0
  consists of 2GB huge page and 5GB ordinary page.

  3. At this time, we create an ordinary numa vm with 6GB and the
  NUMATopologyFilter filter may select the host numa node 0. If the host
  numa node 0 is selected, the libvirt will report OOM error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428551/+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 1428687] [NEW] Available Volume Limit label don`t counts how much resources remains

2015-03-05 Thread Kyrylo Romanenko
Public bug reported:

Steps: 
1. Login to Horizon.
2. Go to http://horizon_ip/project/volumes/
3. Click on Create Volume button.
4. Create several volumes of some sizes.

Create Volume dialog contains graphical ans textual labels of limits:
Total Gigabytes (X) - 1000 GB Available
Number of Volumes (Y) - 10 Available

X and Y counts how much Gigs and Volumes used.  
1000 GB and 10 volumes are set as Default Quotas.

Actual: Available number is not changed according to actual amount of
remained resources. Therefore Available label just shows Default Quota
limit.

Expected: we can see good behaviour in Allocate Floating IP dialog.
There Available number calculated as: Available =  Quota - Allocated.

Screenshot attached.

Devstack:
os|distro=trusty
os|vendor=Ubuntu
os|release=14.04
git|cinder|master[2079b0f]
git|glance|master[8d21220]
git|heat|master[6d6e417]
git|heat-cfntools|master[a7ffb71]
git|heat-templates|master[35e6837]
git|horizon|master[680488d]
git|keystone|master[e54c323]
git|nova|master[422b22e]

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: available.png
   
https://bugs.launchpad.net/bugs/1428687/+attachment/4335295/+files/available.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/1428687

Title:
  Available Volume Limit label don`t counts how much resources remains

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Steps: 
  1. Login to Horizon.
  2. Go to http://horizon_ip/project/volumes/
  3. Click on Create Volume button.
  4. Create several volumes of some sizes.

  Create Volume dialog contains graphical ans textual labels of limits:
  Total Gigabytes (X) - 1000 GB Available
  Number of Volumes (Y) - 10 Available

  X and Y counts how much Gigs and Volumes used.  
  1000 GB and 10 volumes are set as Default Quotas.

  Actual: Available number is not changed according to actual amount of
  remained resources. Therefore Available label just shows Default Quota
  limit.

  Expected: we can see good behaviour in Allocate Floating IP dialog.
  There Available number calculated as: Available =  Quota -
  Allocated.

  Screenshot attached.

  Devstack:
  os|distro=trusty
  os|vendor=Ubuntu
  os|release=14.04
  git|cinder|master[2079b0f]
  git|glance|master[8d21220]
  git|heat|master[6d6e417]
  git|heat-cfntools|master[a7ffb71]
  git|heat-templates|master[35e6837]
  git|horizon|master[680488d]
  git|keystone|master[e54c323]
  git|nova|master[422b22e]

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428687/+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 1428708] [NEW] Fernet token expiration is redundant with key rotation

2015-03-05 Thread Dolph Mathews
Public bug reported:

Each Fernet token carries an expiration timestamp: the point in time at
which an otherwise valid Fernet token is considered to be expired.
This design element is a holdover from previous token formats
(especially UUID).

With key rotation, there's no reason for tokens to carry expiry
timestamps.

Instead, the deployer should tune their key rotation configuration to
discard keys that are older than their desired *maximum* token lifespan.
For example, if a deployer wishes to rotate encryption keys every hour
(by calling keystone-manage fernet_rotate every hour via cron), and
maintain a token lifespan of up to 24 hours, then they should configure
keystone.conf as follows:

  [fernet_tokens]
  max_active_keys = 25

The effect is that 1 staged key, 1 primary key, and 23 secondary keys
are held in the rotation (1 + 1 + 23 = 25). This means that tokens will
expire somewhere between 23-24 hours (depending on how lucky you get
with the timing of token creation and key rotation).

A less aggressive security policy might be to rotate encryption keys
with a daily cron job, and hold keys in the rotation for a week
(max_active_keys = 15). Or to rotate encryption keys with a weekly cron
job, and hold keys in the rotation for a year (max_active_keys = 53).

Unlike with persistent tokens (UUID), deployers are not faced with the
challenge of persisting a year's worth of tokens all at once, so the
tradeoffs are primarily driven by security considerations, rather than
the cost of performance.

** Affects: keystone
 Importance: Wishlist
 Assignee: Dolph Mathews (dolph)
 Status: New


** Tags: fernet

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

Title:
  Fernet token expiration is redundant with key rotation

Status in OpenStack Identity (Keystone):
  New

Bug description:
  Each Fernet token carries an expiration timestamp: the point in time
  at which an otherwise valid Fernet token is considered to be
  expired. This design element is a holdover from previous token
  formats (especially UUID).

  With key rotation, there's no reason for tokens to carry expiry
  timestamps.

  Instead, the deployer should tune their key rotation configuration to
  discard keys that are older than their desired *maximum* token
  lifespan. For example, if a deployer wishes to rotate encryption keys
  every hour (by calling keystone-manage fernet_rotate every hour via
  cron), and maintain a token lifespan of up to 24 hours, then they
  should configure keystone.conf as follows:

[fernet_tokens]
max_active_keys = 25

  The effect is that 1 staged key, 1 primary key, and 23 secondary keys
  are held in the rotation (1 + 1 + 23 = 25). This means that tokens
  will expire somewhere between 23-24 hours (depending on how lucky
  you get with the timing of token creation and key rotation).

  A less aggressive security policy might be to rotate encryption keys
  with a daily cron job, and hold keys in the rotation for a week
  (max_active_keys = 15). Or to rotate encryption keys with a weekly
  cron job, and hold keys in the rotation for a year (max_active_keys =
  53).

  Unlike with persistent tokens (UUID), deployers are not faced with the
  challenge of persisting a year's worth of tokens all at once, so the
  tradeoffs are primarily driven by security considerations, rather than
  the cost of performance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428708/+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 1428713] [NEW] migrate non-dvr to dvr case, snat netns not created

2015-03-05 Thread ZongKai LI
Public bug reported:

On a 1+2 env, router has external network attached.
Use follow steps to migrate from non-dvr to dvr:
1) modify related config files.
2) restart related services.
3) run command neutron router-update --distributed=True ROUTER.

Now, there's no snat-* netns create on controller node.
As a workaround, restart neutron-l3-agent on controller node will work.

And in l3-agent.log, we can find:
2015-02-28 01:26:21.377 5283 ERROR neutron.agent.l3.agent [-] 'LegacyRouter' 
object has no attribute 'dist_fip_count'
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent Traceback (most 
recent call last):
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent   File 
/usr/lib/python2.7/site-packages/neutron/common/utils.py, line 342, in call
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent return 
func(*args, **kwargs)
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent   File 
/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py, line 592, in 
process_router
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent 
self.scan_fip_ports(ri)
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent   File 
/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr.py, line 128, in 
scan_fip_ports
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent if not 
ri.router.get('distributed') or ri.dist_fip_count is not None:
2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent AttributeError: 
'LegacyRouter' object has no attribute 'dist_fip_count'

It seems current code is not ready to migrate LegacyRouter to DvrRouter.

** Affects: neutron
 Importance: Undecided
 Assignee: ZongKai LI (lzklibj)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) = ZongKai LI (lzklibj)

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

Title:
  migrate non-dvr to dvr case, snat netns not created

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  On a 1+2 env, router has external network attached.
  Use follow steps to migrate from non-dvr to dvr:
  1) modify related config files.
  2) restart related services.
  3) run command neutron router-update --distributed=True ROUTER.

  Now, there's no snat-* netns create on controller node.
  As a workaround, restart neutron-l3-agent on controller node will work.

  And in l3-agent.log, we can find:
  2015-02-28 01:26:21.377 5283 ERROR neutron.agent.l3.agent [-] 'LegacyRouter' 
object has no attribute 'dist_fip_count'
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent Traceback (most 
recent call last):
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent   File 
/usr/lib/python2.7/site-packages/neutron/common/utils.py, line 342, in call
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent return 
func(*args, **kwargs)
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent   File 
/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py, line 592, in 
process_router
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent 
self.scan_fip_ports(ri)
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent   File 
/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr.py, line 128, in 
scan_fip_ports
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent if not 
ri.router.get('distributed') or ri.dist_fip_count is not None:
  2015-02-28 01:26:21.377 5283 TRACE neutron.agent.l3.agent AttributeError: 
'LegacyRouter' object has no attribute 'dist_fip_count'

  It seems current code is not ready to migrate LegacyRouter to
  DvrRouter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428713/+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 1428774] [NEW] Neutron-LBaaS: Stats Call API Spec mismatch with Actual Response

2015-03-05 Thread Franklin Naval
Public bug reported:


1.  Create Load Balancer
2.  Do a stats call
3.  See response.

Result:  stats response looks like this:
{stats: {bytes_in: 0, total_connections: 0, active_connections: 0, 
bytes_out: 0}}

Expected:  according to api spec,
(https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Retrieve_a_specific_Load_Balancer.27s_Statistics)
it should look like this:

{
stats: {
loadbalancer: {
total_bytes_in: 0,
total_bytes_out: 0,
total_connections: 0,
total_active_connections: 0,
}
}
}

Missing 'loadbalancer' attribute.   Or, update the wiki to remove
'loadbalancer'.

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

Title:
  Neutron-LBaaS: Stats Call API Spec mismatch with Actual Response

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  
  1.  Create Load Balancer
  2.  Do a stats call
  3.  See response.

  Result:  stats response looks like this:
  {stats: {bytes_in: 0, total_connections: 0, active_connections: 0, 
bytes_out: 0}}

  Expected:  according to api spec,
  
(https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Retrieve_a_specific_Load_Balancer.27s_Statistics)
  it should look like this:

  {
  stats: {
  loadbalancer: {
  total_bytes_in: 0,
  total_bytes_out: 0,
  total_connections: 0,
  total_active_connections: 0,
  }
  }
  }

  Missing 'loadbalancer' attribute.   Or, update the wiki to remove
  'loadbalancer'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1428774/+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 1428600] [NEW] Domain Config updates for specific group/option don't honor NotFound

2015-03-05 Thread Henry Nash
Public bug reported:

The manager API for domain-config database updates should raise a
DomainConfigNotFound exception if an explicit group or option as been
specified in the url (i.e. passed as a parameter to the manager method)
and that group/option is not present in the existing config.  Currently
the code does check that

a) the group/option is one we support (i.e. whitelisted or sensitive), and
b) the contents of the new config passed contains (and ONLY contains) the 
specified group or option

...but it doesn't check that the group/option exists in the original
config.

** Affects: keystone
 Importance: High
 Assignee: Henry Nash (henry-nash)
 Status: New

** Description changed:

  The manager API for domain-config database updates should raise a
  DomainConfigNotFound exception if an explicit group or option as been
- specified in the url (i.e. passed as a parameter to the manager method).
- Currently the code does check that
+ specified in the url (i.e. passed as a parameter to the manager method)
+ and that group/option is not present in the existing config.  Currently
+ the code does check that
  
  a) the group/option is one we support (i.e. whitelisted or sensitive), and
  b) the contents of the new config passed contains (and ONLY contains) the 
specified group or option
  
  ...but it doesn't check that the group/option exists in the original
  config.

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

Title:
  Domain Config updates for specific group/option don't honor NotFound

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The manager API for domain-config database updates should raise a
  DomainConfigNotFound exception if an explicit group or option as been
  specified in the url (i.e. passed as a parameter to the manager
  method) and that group/option is not present in the existing config.
  Currently the code does check that

  a) the group/option is one we support (i.e. whitelisted or sensitive), and
  b) the contents of the new config passed contains (and ONLY contains) the 
specified group or option

  ...but it doesn't check that the group/option exists in the original
  config.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428600/+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 1428580] [NEW] Doubled Stack status

2015-03-05 Thread Kyrylo Romanenko
Public bug reported:

Steps: 
1. Login to Horizon.
2. Go to Project - Orchestration - Stacks. 
3. Create one or several stacks. 
4. Go into Stack details - Topology. 
5. In top-left corner stack status displayed twice. 

Env:
MOS:
{build_id: 2015-03-01_22-54-44, ostf_sha: 
5cc59010fd4db71dc45e87b31ff24325d9a7f28f, build_number: 153, 
release_versions: {2014.2-6.1: {VERSION: {build_id: 
2015-03-01_22-54-44, ostf_sha: 5cc59010fd4db71dc45e87b31ff24325d9a7f28f, 
build_number: 153, api: 1.0, nailgun_sha: 
c2b857b040a2e2121727aa874d0dff1374d6e5ce, production: docker, 
python-fuelclient_sha: 3ebfa9c14a192d0298ff787526bf990055a23694, 
astute_sha: 3a39ae300b8b3b02afbee03ea5116cd5357f8fc5, feature_groups: 
[mirantis], release: 6.1, fuelmain_sha: 
baf24424a4e056c6753913de5f8c94851903f718, fuellib_sha: 
510e82f3fd21e45fe757058bf5e658669765f02e}}}, auth_required: true, api: 
1.0, nailgun_sha: c2b857b040a2e2121727aa874d0dff1374d6e5ce, production: 
docker, python-fuelclient_sha: 3ebfa9c14a192d0298ff787526bf990055a23694, 
astute_sha: 3a39ae300b8b3b02afbee03ea5116cd5357f8fc5, feature_groups: 
[mirantis], release: 6.1, fuelmain_sha: baf24424a4e
 056c6753913de5f8c94851903f718, fuellib_sha: 
510e82f3fd21e45fe757058bf5e658669765f02e}

Devstack:
os|distro=trusty
os|vendor=Ubuntu
os|release=14.04
git|cinder|master[2079b0f]
git|glance|master[8d21220]
git|heat|master[6d6e417]
git|heat-cfntools|master[a7ffb71]
git|heat-templates|master[35e6837]
git|horizon|master[680488d]

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: StackStatus.PNG
   
https://bugs.launchpad.net/bugs/1428580/+attachment/4335065/+files/StackStatus.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/1428580

Title:
  Doubled Stack status

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Steps: 
  1. Login to Horizon.
  2. Go to Project - Orchestration - Stacks. 
  3. Create one or several stacks. 
  4. Go into Stack details - Topology. 
  5. In top-left corner stack status displayed twice. 

  Env:
  MOS:
  {build_id: 2015-03-01_22-54-44, ostf_sha: 
5cc59010fd4db71dc45e87b31ff24325d9a7f28f, build_number: 153, 
release_versions: {2014.2-6.1: {VERSION: {build_id: 
2015-03-01_22-54-44, ostf_sha: 5cc59010fd4db71dc45e87b31ff24325d9a7f28f, 
build_number: 153, api: 1.0, nailgun_sha: 
c2b857b040a2e2121727aa874d0dff1374d6e5ce, production: docker, 
python-fuelclient_sha: 3ebfa9c14a192d0298ff787526bf990055a23694, 
astute_sha: 3a39ae300b8b3b02afbee03ea5116cd5357f8fc5, feature_groups: 
[mirantis], release: 6.1, fuelmain_sha: 
baf24424a4e056c6753913de5f8c94851903f718, fuellib_sha: 
510e82f3fd21e45fe757058bf5e658669765f02e}}}, auth_required: true, api: 
1.0, nailgun_sha: c2b857b040a2e2121727aa874d0dff1374d6e5ce, production: 
docker, python-fuelclient_sha: 3ebfa9c14a192d0298ff787526bf990055a23694, 
astute_sha: 3a39ae300b8b3b02afbee03ea5116cd5357f8fc5, feature_groups: 
[mirantis], release: 6.1, fuelmain_sha: baf24424a
 4e056c6753913de5f8c94851903f718, fuellib_sha: 
510e82f3fd21e45fe757058bf5e658669765f02e}

  Devstack:
  os|distro=trusty
  os|vendor=Ubuntu
  os|release=14.04
  git|cinder|master[2079b0f]
  git|glance|master[8d21220]
  git|heat|master[6d6e417]
  git|heat-cfntools|master[a7ffb71]
  git|heat-templates|master[35e6837]
  git|horizon|master[680488d]

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428580/+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 1428553] [NEW] migration and live migration fails with image-type=rbd

2015-03-05 Thread Yogev Rabl
Public bug reported:

Description of problem:
The migration and live migration of instances fail when Nova is set to work 
with RBD as a back end for the instances disks. 
When attempting to migrate an instance from one host to another an error prompt:

Error: Failed to launch instance osp5: Please try again later [Error:
Unexpected error while running command. Command: ssh host address
mkdir -p /var/lib/nova/instances/98cc014a-0d6d-48bc-9d76-4fe361b67f3b
Exit code: 1 Stdout: u'This account is currently not available.\n'
Stderr: u''].

The log show: http://pastebin.test.redhat.com/267337

when attempting to run live migration this is the output:
http://pastebin.test.redhat.com/267340

There's a work around, to change the nova user settings on all the
compute nodes, on the /etc/passwd file from sbin/nologin to bin/bash and
run the command. I wouldn't recommend it, it creates a security breach
IMO.

Version-Release number of selected component (if applicable):
openstack-nova-api-2014.2.2-2.el7ost.noarch
python-nova-2014.2.2-2.el7ost.noarch
openstack-nova-compute-2014.2.2-2.el7ost.noarch
openstack-nova-common-2014.2.2-2.el7ost.noarch
openstack-nova-scheduler-2014.2.2-2.el7ost.noarch
python-novaclient-2.20.0-1.el7ost.noarch
openstack-nova-conductor-2014.2.2-2.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Set the nova to work with RBD as the back end of the instances disks, 
according to the Ceph documentation
2. Launch an instance
3. migrate the instance to a different host 

Actual results:
The migration fails and the instance status moves to error.

Expected results:
the instance migrates to the other host

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

Title:
  migration and live migration fails with image-type=rbd

Status in OpenStack Compute (Nova):
  New

Bug description:
  Description of problem:
  The migration and live migration of instances fail when Nova is set to work 
with RBD as a back end for the instances disks. 
  When attempting to migrate an instance from one host to another an error 
prompt:

  Error: Failed to launch instance osp5: Please try again later
  [Error: Unexpected error while running command. Command: ssh host
  address mkdir -p /var/lib/nova/instances/98cc014a-0d6d-48bc-
  9d76-4fe361b67f3b Exit code: 1 Stdout: u'This account is currently not
  available.\n' Stderr: u''].

  The log show: http://pastebin.test.redhat.com/267337

  when attempting to run live migration this is the output:
  http://pastebin.test.redhat.com/267340

  There's a work around, to change the nova user settings on all the
  compute nodes, on the /etc/passwd file from sbin/nologin to bin/bash
  and run the command. I wouldn't recommend it, it creates a security
  breach IMO.

  Version-Release number of selected component (if applicable):
  openstack-nova-api-2014.2.2-2.el7ost.noarch
  python-nova-2014.2.2-2.el7ost.noarch
  openstack-nova-compute-2014.2.2-2.el7ost.noarch
  openstack-nova-common-2014.2.2-2.el7ost.noarch
  openstack-nova-scheduler-2014.2.2-2.el7ost.noarch
  python-novaclient-2.20.0-1.el7ost.noarch
  openstack-nova-conductor-2014.2.2-2.el7ost.noarch

  How reproducible:
  100%

  Steps to Reproduce:
  1. Set the nova to work with RBD as the back end of the instances disks, 
according to the Ceph documentation
  2. Launch an instance
  3. migrate the instance to a different host 

  Actual results:
  The migration fails and the instance status moves to error.

  Expected results:
  the instance migrates to the other host

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428553/+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 1428585] [NEW] Filtering compute host in admin page makes an internal server error

2015-03-05 Thread Masahito Muroi
Public bug reported:

Horizon returns Internal Server Error when you push filter button in
admin's compute host page.

How to reproduce:
1. login as admin
2. moving System - Hypervisors - Compute Host
3. clicking Filter button

I received following error on my browser:

TemplateSyntaxError at /admin/hypervisors/

'Service' object is not iterable

Request Method: POST
Request URL:http://10.10.1.10/admin/hypervisors/
Django Version: 1.6.10
Exception Type: TemplateSyntaxError
Exception Value:

'Service' object is not iterable

Exception Location: 
/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/admin/hypervisors/compute/tables.py
 in filter, line 63
Python Executable:  /usr/bin/python
Python Version: 2.7.6
Python Path:

['/opt/stack/horizon/openstack_dashboard/wsgi/../..',
 '/opt/stack/keystone',
 '/opt/stack/glance',
 '/opt/stack/cinder',
 '/opt/stack/neutron',
 '/opt/stack/nova',
 '/opt/stack/horizon',
 '/opt/stack/heat',
 '/usr/lib/python2.7',
 '/usr/lib/python2.7/plat-x86_64-linux-gnu',
 '/usr/lib/python2.7/lib-tk',
 '/usr/lib/python2.7/lib-old',
 '/usr/lib/python2.7/lib-dynload',
 '/usr/local/lib/python2.7/dist-packages',
 '/usr/lib/python2.7/dist-packages',
 '/opt/stack/horizon/openstack_dashboard']

Server time:Thu, 5 Mar 2015 10:42:18 +

I attach horizon.log in this report.

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: horizon-error.log.txt
   
https://bugs.launchpad.net/bugs/1428585/+attachment/4335066/+files/horizon-error.log.txt

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

Title:
  Filtering compute host in admin page makes an internal server error

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Horizon returns Internal Server Error when you push filter button in
  admin's compute host page.

  How to reproduce:
  1. login as admin
  2. moving System - Hypervisors - Compute Host
  3. clicking Filter button

  I received following error on my browser:

  TemplateSyntaxError at /admin/hypervisors/

  'Service' object is not iterable

  Request Method:   POST
  Request URL:  http://10.10.1.10/admin/hypervisors/
  Django Version:   1.6.10
  Exception Type:   TemplateSyntaxError
  Exception Value:  

  'Service' object is not iterable

  Exception Location:   
/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/admin/hypervisors/compute/tables.py
 in filter, line 63
  Python Executable:/usr/bin/python
  Python Version:   2.7.6
  Python Path:  

  ['/opt/stack/horizon/openstack_dashboard/wsgi/../..',
   '/opt/stack/keystone',
   '/opt/stack/glance',
   '/opt/stack/cinder',
   '/opt/stack/neutron',
   '/opt/stack/nova',
   '/opt/stack/horizon',
   '/opt/stack/heat',
   '/usr/lib/python2.7',
   '/usr/lib/python2.7/plat-x86_64-linux-gnu',
   '/usr/lib/python2.7/lib-tk',
   '/usr/lib/python2.7/lib-old',
   '/usr/lib/python2.7/lib-dynload',
   '/usr/local/lib/python2.7/dist-packages',
   '/usr/lib/python2.7/dist-packages',
   '/opt/stack/horizon/openstack_dashboard']

  Server time:Thu, 5 Mar 2015 10:42:18 +

  I attach horizon.log in this report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428585/+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 1428497] Re: Switch to oslo_messaging in entry_points.txt

2015-03-05 Thread Qin Zhao
It seems that it is already fixed by
https://review.openstack.org/#/c/153092/


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

Title:
  Switch to oslo_messaging in entry_points.txt

Status in OpenStack Compute (Nova):
  Invalid

Bug description:
  oslo.messaging 1.6.0 has moved notification implementation to
  oslo_messaging directory. Need to change the class path in
  entry_points.txt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428497/+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 1428598] [NEW] Horizon for Manila throws ERROR UNAUTHORIZED notification

2015-03-05 Thread Vinay Prasad M
Public bug reported:

I have devstack setup of stable/juno release  with Manila enabled. 
Configured with Horizon custom project of Manila. All Manila operations works 
fine with Command line but throws below errors on logging in to Horizon

Error: Unauthorized: Unable to retrieve share limit information.

On click of Shares tab throws : 
Error: Unauthorized: Unable to retrieve share list.
×
Error: Unauthorized: Unable to retrieve snapshot list.
×
Error: Unauthorized: Unable to retrieve share networks
×
Error: Unauthorized: Unable to retrieve security services
×
Error: Unauthorized: Unable to retrieve volume types
×
Error: Unauthorized: Unable to retrieve share servers

I am using stable/juno version of devstack and manila
manila_juno version of HORIZON_REPO=https://github.com/NetApp/horizon.git

Request you to please have a look.

Have also tried the same with Kilo release as per instructions in
https://wiki.openstack.org/wiki/Manila/KiloDevstack and Horizon setup
instruction in
https://wiki.openstack.org/wiki/Manila/docs/HOWTO_use_manila_with_horizon.

Gives me same ERROR in horizon

Regards,
Vinay P

** Affects: horizon
 Importance: Undecided
 Status: New

** Affects: manila
 Importance: Undecided
 Status: New

** Attachment added: Horizon.png
   
https://bugs.launchpad.net/bugs/1428598/+attachment/4335067/+files/Horizon.png

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

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

Title:
  Horizon for Manila throws ERROR UNAUTHORIZED notification

Status in OpenStack Dashboard (Horizon):
  New
Status in Manila:
  New

Bug description:
  I have devstack setup of stable/juno release  with Manila enabled. 
  Configured with Horizon custom project of Manila. All Manila operations works 
fine with Command line but throws below errors on logging in to Horizon

  Error: Unauthorized: Unable to retrieve share limit information.

  On click of Shares tab throws : 
  Error: Unauthorized: Unable to retrieve share list.
  ×
  Error: Unauthorized: Unable to retrieve snapshot list.
  ×
  Error: Unauthorized: Unable to retrieve share networks
  ×
  Error: Unauthorized: Unable to retrieve security services
  ×
  Error: Unauthorized: Unable to retrieve volume types
  ×
  Error: Unauthorized: Unable to retrieve share servers

  I am using stable/juno version of devstack and manila
  manila_juno version of HORIZON_REPO=https://github.com/NetApp/horizon.git

  Request you to please have a look.

  Have also tried the same with Kilo release as per instructions in
  https://wiki.openstack.org/wiki/Manila/KiloDevstack and Horizon setup
  instruction in
  https://wiki.openstack.org/wiki/Manila/docs/HOWTO_use_manila_with_horizon.

  Gives me same ERROR in horizon

  Regards,
  Vinay P

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428598/+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 1428630] [NEW] keystone [-] TypeError: _get_value() takes exactly 4 arguments (5 given)

2015-03-05 Thread Launchpad Bug Tracker
You have been subscribed to a public bug:

+ /opt/stack/keystone/bin/keystone-manage db_sync
2015-03-05 12:22:29.036 | 14818 CRITICAL keystone [-] TypeError: _get_value() 
takes exactly 4 arguments (5 given)
2015-03-05 12:22:29.037 | 14818 TRACE keystone Traceback (most recent call 
last):
2015-03-05 12:22:29.040 | 14818 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
2015-03-05 12:22:29.042 | 14818 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
2015-03-05 12:22:29.042 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 370, in main
2015-03-05 12:22:29.043 | 14818 TRACE keystone CONF.command.cmd_class.main()
2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
2015-03-05 12:22:29.043 | 14818 TRACE keystone 
migration_helpers.sync_database_to_version(extension, version)
2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 209, in 
sync_database_to_version
2015-03-05 12:22:29.043 | 14818 TRACE keystone _sync_common_repo(version)
2015-03-05 12:22:29.045 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 162, in 
_sync_common_repo
2015-03-05 12:22:29.045 | 14818 TRACE keystone engine = sql.get_engine()
2015-03-05 12:22:29.045 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/core.py, line 188, in get_engine
2015-03-05 12:22:29.046 | 14818 TRACE keystone return 
_get_engine_facade().get_engine()
2015-03-05 12:22:29.046 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/core.py, line 176, in 
_get_engine_facade
2015-03-05 12:22:29.046 | 14818 TRACE keystone _engine_facade = 
db_session.EngineFacade.from_config(CONF)
2015-03-05 12:22:29.046 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.py, line 
833, in from_config
2015-03-05 12:22:29.046 | 14818 TRACE keystone return 
cls(sql_connection=conf.database.connection,
2015-03-05 12:22:29.047 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2516, in 
__getattr__
2015-03-05 12:22:29.047 | 14818 TRACE keystone return self._conf._get(name, 
self._group)
2015-03-05 12:22:29.050 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2238, in _get
2015-03-05 12:22:29.050 | 14818 TRACE keystone value = self._do_get(name, 
group, namespace)
2015-03-05 12:22:29.051 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2275, in 
_do_get
2015-03-05 12:22:29.052 | 14818 TRACE keystone return 
convert(opt._get_from_namespace(namespace, group_name))
2015-03-05 12:22:29.052 | 14818 TRACE keystone   File 
/usr/lib/python2.7/dist-packages/oslo/config/cfg.py, line 598, in 
_get_from_namespace
2015-03-05 12:22:29.052 | 14818 TRACE keystone self._convert_value)
2015-03-05 12:22:29.052 | 14818 TRACE keystone TypeError: _get_value() takes 
exactly 4 arguments (5 given)
2015-03-05 12:22:29.052 | 14818 TRACE keystone
2015-03-05 12:22:29.213 | + exit_trap
2015-03-05 12:22:29.214 | + local r=1
2015-03-05 12:22:29.219 | ++ jobs -p
2015-03-05 12:22:29.256 | + jobs=
2015-03-05 12:22:29.257 | + [[ -n '' ]]
2015-03-05 12:22:29.260 | + kill_spinner
2015-03-05 12:22:29.262 | + '[' '!' -z '' ']'
2015-03-05 12:22:29.266 | + [[ 1 -ne 0 ]]
2015-03-05 12:22:29.267 | + echo 'Error on exit'
2015-03-05 12:22:29.267 | Error on exit
2015-03-05 12:22:29.267 | + [[ -z . ]]
2015-03-05 12:22:29.269 | + /home/swami/devstack/tools/worlddump.py -d .
2015-03-05 12:22:29.524 | + exit 1

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
keystone [-] TypeError: _get_value() takes exactly 4 arguments (5 given)
https://bugs.launchpad.net/bugs/1428630
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to Keystone.

-- 
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 1428630] [NEW] keystone [-] TypeError: _get_value() takes exactly 4 arguments (5 given)

2015-03-05 Thread Swami Reddy
Public bug reported:

+ /opt/stack/keystone/bin/keystone-manage db_sync
2015-03-05 12:22:29.036 | 14818 CRITICAL keystone [-] TypeError: _get_value() 
takes exactly 4 arguments (5 given)
2015-03-05 12:22:29.037 | 14818 TRACE keystone Traceback (most recent call 
last):
2015-03-05 12:22:29.040 | 14818 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
2015-03-05 12:22:29.042 | 14818 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
2015-03-05 12:22:29.042 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 370, in main
2015-03-05 12:22:29.043 | 14818 TRACE keystone CONF.command.cmd_class.main()
2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
2015-03-05 12:22:29.043 | 14818 TRACE keystone 
migration_helpers.sync_database_to_version(extension, version)
2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 209, in 
sync_database_to_version
2015-03-05 12:22:29.043 | 14818 TRACE keystone _sync_common_repo(version)
2015-03-05 12:22:29.045 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 162, in 
_sync_common_repo
2015-03-05 12:22:29.045 | 14818 TRACE keystone engine = sql.get_engine()
2015-03-05 12:22:29.045 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/core.py, line 188, in get_engine
2015-03-05 12:22:29.046 | 14818 TRACE keystone return 
_get_engine_facade().get_engine()
2015-03-05 12:22:29.046 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/core.py, line 176, in 
_get_engine_facade
2015-03-05 12:22:29.046 | 14818 TRACE keystone _engine_facade = 
db_session.EngineFacade.from_config(CONF)
2015-03-05 12:22:29.046 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.py, line 
833, in from_config
2015-03-05 12:22:29.046 | 14818 TRACE keystone return 
cls(sql_connection=conf.database.connection,
2015-03-05 12:22:29.047 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2516, in 
__getattr__
2015-03-05 12:22:29.047 | 14818 TRACE keystone return self._conf._get(name, 
self._group)
2015-03-05 12:22:29.050 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2238, in _get
2015-03-05 12:22:29.050 | 14818 TRACE keystone value = self._do_get(name, 
group, namespace)
2015-03-05 12:22:29.051 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2275, in 
_do_get
2015-03-05 12:22:29.052 | 14818 TRACE keystone return 
convert(opt._get_from_namespace(namespace, group_name))
2015-03-05 12:22:29.052 | 14818 TRACE keystone   File 
/usr/lib/python2.7/dist-packages/oslo/config/cfg.py, line 598, in 
_get_from_namespace
2015-03-05 12:22:29.052 | 14818 TRACE keystone self._convert_value)
2015-03-05 12:22:29.052 | 14818 TRACE keystone TypeError: _get_value() takes 
exactly 4 arguments (5 given)
2015-03-05 12:22:29.052 | 14818 TRACE keystone
2015-03-05 12:22:29.213 | + exit_trap
2015-03-05 12:22:29.214 | + local r=1
2015-03-05 12:22:29.219 | ++ jobs -p
2015-03-05 12:22:29.256 | + jobs=
2015-03-05 12:22:29.257 | + [[ -n '' ]]
2015-03-05 12:22:29.260 | + kill_spinner
2015-03-05 12:22:29.262 | + '[' '!' -z '' ']'
2015-03-05 12:22:29.266 | + [[ 1 -ne 0 ]]
2015-03-05 12:22:29.267 | + echo 'Error on exit'
2015-03-05 12:22:29.267 | Error on exit
2015-03-05 12:22:29.267 | + [[ -z . ]]
2015-03-05 12:22:29.269 | + /home/swami/devstack/tools/worlddump.py -d .
2015-03-05 12:22:29.524 | + exit 1

** Affects: keystone
 Importance: Undecided
 Status: New

** Project changed: ceilometer = keystone

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

Title:
  keystone [-] TypeError: _get_value() takes exactly 4 arguments (5
  given)

Status in OpenStack Identity (Keystone):
  New

Bug description:
  + /opt/stack/keystone/bin/keystone-manage db_sync
  2015-03-05 12:22:29.036 | 14818 CRITICAL keystone [-] TypeError: _get_value() 
takes exactly 4 arguments (5 given)
  2015-03-05 12:22:29.037 | 14818 TRACE keystone Traceback (most recent call 
last):
  2015-03-05 12:22:29.040 | 14818 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
  2015-03-05 12:22:29.042 | 14818 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2015-03-05 12:22:29.042 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 370, in main
  2015-03-05 12:22:29.043 | 14818 TRACE keystone 
CONF.command.cmd_class.main()
  2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
  2015-03-05 12:22:29.043 | 14818 TRACE keystone 

[Yahoo-eng-team] [Bug 1428495] Re: Does not enable ssh even with ssh_enabled: True

2015-03-05 Thread Martin Gerhard Loschwitz
** Also affects: cloud-init
   Importance: Undecided
   Status: New

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

Title:
  Does not enable ssh even with ssh_enabled: True

Status in Init scripts for use on cloud images:
  New
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  The latest cloud images from vivid with cloud-init
  0.7.7~bzr1076-0ubuntu1 now stop enabling ssh by default, as they
  create an /etc/ssh/ssh_not_to_be_run stamp file. Aside from the fact
  that there was no warning about it and it's not documented in the
  changelog or documentation or anywhere, re-enabling also does not seem
  to work. I found the new ssh_enabled key in
  cloudinit/config/cc_snappy.py, but setting it in my user-data (for
  generating a local seed iso) does not work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1428495/+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 1428630] Re: keystone [-] TypeError: _get_value() takes exactly 4 arguments (5 given)

2015-03-05 Thread Swami Reddy
** Also affects: devstack
   Importance: Undecided
   Status: New

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

Title:
  keystone [-] TypeError: _get_value() takes exactly 4 arguments (5
  given)

Status in devstack - openstack dev environments:
  New
Status in OpenStack Identity (Keystone):
  New

Bug description:
  + /opt/stack/keystone/bin/keystone-manage db_sync
  2015-03-05 12:22:29.036 | 14818 CRITICAL keystone [-] TypeError: _get_value() 
takes exactly 4 arguments (5 given)
  2015-03-05 12:22:29.037 | 14818 TRACE keystone Traceback (most recent call 
last):
  2015-03-05 12:22:29.040 | 14818 TRACE keystone   File 
/opt/stack/keystone/bin/keystone-manage, line 44, in module
  2015-03-05 12:22:29.042 | 14818 TRACE keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2015-03-05 12:22:29.042 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 370, in main
  2015-03-05 12:22:29.043 | 14818 TRACE keystone 
CONF.command.cmd_class.main()
  2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/cli.py, line 74, in main
  2015-03-05 12:22:29.043 | 14818 TRACE keystone 
migration_helpers.sync_database_to_version(extension, version)
  2015-03-05 12:22:29.043 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 209, in 
sync_database_to_version
  2015-03-05 12:22:29.043 | 14818 TRACE keystone _sync_common_repo(version)
  2015-03-05 12:22:29.045 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/migration_helpers.py, line 162, in 
_sync_common_repo
  2015-03-05 12:22:29.045 | 14818 TRACE keystone engine = sql.get_engine()
  2015-03-05 12:22:29.045 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/core.py, line 188, in get_engine
  2015-03-05 12:22:29.046 | 14818 TRACE keystone return 
_get_engine_facade().get_engine()
  2015-03-05 12:22:29.046 | 14818 TRACE keystone   File 
/opt/stack/keystone/keystone/common/sql/core.py, line 176, in 
_get_engine_facade
  2015-03-05 12:22:29.046 | 14818 TRACE keystone _engine_facade = 
db_session.EngineFacade.from_config(CONF)
  2015-03-05 12:22:29.046 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/session.py, line 
833, in from_config
  2015-03-05 12:22:29.046 | 14818 TRACE keystone return 
cls(sql_connection=conf.database.connection,
  2015-03-05 12:22:29.047 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2516, in 
__getattr__
  2015-03-05 12:22:29.047 | 14818 TRACE keystone return 
self._conf._get(name, self._group)
  2015-03-05 12:22:29.050 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2238, in _get
  2015-03-05 12:22:29.050 | 14818 TRACE keystone value = self._do_get(name, 
group, namespace)
  2015-03-05 12:22:29.051 | 14818 TRACE keystone   File 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py, line 2275, in 
_do_get
  2015-03-05 12:22:29.052 | 14818 TRACE keystone return 
convert(opt._get_from_namespace(namespace, group_name))
  2015-03-05 12:22:29.052 | 14818 TRACE keystone   File 
/usr/lib/python2.7/dist-packages/oslo/config/cfg.py, line 598, in 
_get_from_namespace
  2015-03-05 12:22:29.052 | 14818 TRACE keystone self._convert_value)
  2015-03-05 12:22:29.052 | 14818 TRACE keystone TypeError: _get_value() takes 
exactly 4 arguments (5 given)
  2015-03-05 12:22:29.052 | 14818 TRACE keystone
  2015-03-05 12:22:29.213 | + exit_trap
  2015-03-05 12:22:29.214 | + local r=1
  2015-03-05 12:22:29.219 | ++ jobs -p
  2015-03-05 12:22:29.256 | + jobs=
  2015-03-05 12:22:29.257 | + [[ -n '' ]]
  2015-03-05 12:22:29.260 | + kill_spinner
  2015-03-05 12:22:29.262 | + '[' '!' -z '' ']'
  2015-03-05 12:22:29.266 | + [[ 1 -ne 0 ]]
  2015-03-05 12:22:29.267 | + echo 'Error on exit'
  2015-03-05 12:22:29.267 | Error on exit
  2015-03-05 12:22:29.267 | + [[ -z . ]]
  2015-03-05 12:22:29.269 | + /home/swami/devstack/tools/worlddump.py -d .
  2015-03-05 12:22:29.524 | + exit 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1428630/+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 1179008] Re: rename requires files to standard names

2015-03-05 Thread Matthew Treinish
** No longer affects: tempest

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

Title:
  rename requires files to standard names

Status in OpenStack Telemetry (Ceilometer):
  Fix Released
Status in Cinder:
  Fix Released
Status in Python Gearman Interface:
  New
Status in Git Review:
  Fix Committed
Status in OpenStack Image Registry and Delivery Service (Glance):
  Fix Released
Status in Orchestration API (Heat):
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Identity (Keystone):
  Fix Released
Status in OpenStack Neutron (virtual network service):
  Fix Released
Status in OpenStack Compute (Nova):
  Fix Released
Status in The Oslo library incubator:
  Fix Released
Status in Python client library for Ceilometer:
  Fix Committed
Status in Python client library for Cinder:
  Fix Committed
Status in Python client library for Glance:
  Fix Committed
Status in Python client library for Keystone:
  Fix Released
Status in Python client library for Neutron:
  Fix Committed
Status in Python client library for Nova:
  Fix Released
Status in OpenStack Command Line Client:
  Fix Committed
Status in Python client library for Swift:
  Fix Committed
Status in Python client library for Zaqar:
  In Progress
Status in OpenStack Object Storage (Swift):
  Fix Released
Status in Openstack Database (Trove):
  Fix Released
Status in Zuul: A project gating system:
  In Progress

Bug description:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  Rename tools/pip-requires to requirements.txt and tools/test-requires
  to test-requirements.txt. These are standard files and tools in the
  general world are growing intelligence about them.

   affects ceilometer
   affects cinder
   affects git-review
   affects glance
   affects heat-cfntools
   affects heat
   affects horizon
   affects keystone
   affects nova
   affects openstack-ci
   affects oslo
   affects python-ceilometerclient
   affects python-cinderclient
   affects python-gear
   affects python-glanceclient
   affects python-heatclient
   affects python-keystoneclient
   affects python-novaclient
   affects python-openstackclient
   affects python-quantumclient
   affects python-swiftclient
   affects quantum
   affects reddwarf
   affects swift
   affects tempest
   affects zuul
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with undefined - http://www.enigmail.net/

  iEYEARECAAYFAlGObegACgkQ2Jv7/VK1RgH+yQCbBuxIZvk/Ra4TEK0TlLqr3xAU
  cj8An1NPMiQ47VubNdsKg6ybymtRRjto
  =fwhb
  -END PGP SIGNATURE-

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1179008/+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 1428946] [NEW] add keystone service id to observer audit

2015-03-05 Thread Steve Martinelli
Public bug reported:

When a CADF notification is sent off, the 'observer' portion looks like
the following:

observer: {
typeURI: service/security,
id: openstack:3d4a50a9-2b59-438b-bf19-c231f9c7625a
},

The ID field should be the ID of the keystone/identity service.

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  add keystone service id to observer audit

Status in OpenStack Identity (Keystone):
  New

Bug description:
  When a CADF notification is sent off, the 'observer' portion looks
  like the following:

  observer: {
  typeURI: service/security,
  id: openstack:3d4a50a9-2b59-438b-bf19-c231f9c7625a
  },

  The ID field should be the ID of the keystone/identity service.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428946/+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 1428945] [NEW] add project id to initiator data for auditing

2015-03-05 Thread Steve Martinelli
Public bug reported:

as seen below, for a CADF notification, the initiator data contains the
user id

initiator: {
typeURI: service/security/account/user,
host: {
agent: curl/7.22.0(x86_64-pc-linux-gnu),
address: 127.0.0.1
},
id: c9f76d3c31e142af9291de2935bde98a
},

It would also be helpful to add the id of the scope (project or domain)
that the user performed the operation on.

I'm not sure what the best way to represent this data is, but it seems
relevant to add.

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  add project id to initiator data for auditing

Status in OpenStack Identity (Keystone):
  New

Bug description:
  as seen below, for a CADF notification, the initiator data contains
  the user id

  initiator: {
  typeURI: service/security/account/user,
  host: {
  agent: curl/7.22.0(x86_64-pc-linux-gnu),
  address: 127.0.0.1
  },
  id: c9f76d3c31e142af9291de2935bde98a
  },

  It would also be helpful to add the id of the scope (project or
  domain) that the user performed the operation on.

  I'm not sure what the best way to represent this data is, but it seems
  relevant to add.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1428945/+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 1426645] Re: keystone_bug_test

2015-03-05 Thread Steve Martinelli
@stanek - regardless i'm closing it as it's been open for too long to be
a test bug.

** Changed in: keystone
   Status: New = Invalid

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

Title:
  keystone_bug_test

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  I want to test commit keystone bug test

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1426645/+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 1428585] Re: Filtering compute host in admin page makes an internal server error

2015-03-05 Thread Kahou Lei
This was fixed in this commit:

https://github.com/openstack/horizon/commit/dd487f236db15fe6d6de76eb86fe98b75e2987b6

** Changed in: horizon
   Status: New = 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/1428585

Title:
  Filtering compute host in admin page makes an internal server error

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Horizon returns Internal Server Error when you push filter button in
  admin's compute host page.

  How to reproduce:
  1. login as admin
  2. moving System - Hypervisors - Compute Host
  3. clicking Filter button

  I received following error on my browser:

  TemplateSyntaxError at /admin/hypervisors/

  'Service' object is not iterable

  Request Method:   POST
  Request URL:  http://10.10.1.10/admin/hypervisors/
  Django Version:   1.6.10
  Exception Type:   TemplateSyntaxError
  Exception Value:  

  'Service' object is not iterable

  Exception Location:   
/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/admin/hypervisors/compute/tables.py
 in filter, line 63
  Python Executable:/usr/bin/python
  Python Version:   2.7.6
  Python Path:  

  ['/opt/stack/horizon/openstack_dashboard/wsgi/../..',
   '/opt/stack/keystone',
   '/opt/stack/glance',
   '/opt/stack/cinder',
   '/opt/stack/neutron',
   '/opt/stack/nova',
   '/opt/stack/horizon',
   '/opt/stack/heat',
   '/usr/lib/python2.7',
   '/usr/lib/python2.7/plat-x86_64-linux-gnu',
   '/usr/lib/python2.7/lib-tk',
   '/usr/lib/python2.7/lib-old',
   '/usr/lib/python2.7/lib-dynload',
   '/usr/local/lib/python2.7/dist-packages',
   '/usr/lib/python2.7/dist-packages',
   '/opt/stack/horizon/openstack_dashboard']

  Server time:Thu, 5 Mar 2015 10:42:18 +

  I attach horizon.log in this report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428585/+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 1428916] [NEW] The confirm resize button doesn't hide immediately when I confirmed

2015-03-05 Thread lei.tang
Public bug reported:

The driver is VMwareVCDriver. 
After resize  instance, confirm it. The button doesn't hide. In fact, it's 
already resized.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: button confirm resize

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

Title:
  The confirm resize button doesn't hide immediately when I confirmed

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The driver is VMwareVCDriver. 
  After resize  instance, confirm it. The button doesn't hide. In fact, it's 
already resized.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1428916/+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 1421616] Re: Cannot create project using Horizon - Could not find default role _member_

2015-03-05 Thread Steve Martinelli
Sounds like keystone was working as designed, and the fix to devstack
resolved the issue

** Changed in: keystone
   Status: New = Invalid

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

Title:
  Cannot create project using Horizon - Could not find default role
  _member_

Status in devstack - openstack dev environments:
  Fix Released
Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  The following error occurs when i try to create a new project using
  Horizon

  On the dashboard - Danger: An error occurred. Please try again later.
  On the horizon screen - NotFound: Could not find default role _member_ in 
Keystone

  Steps to reproduce:
  ===
  1. Install openstack using devstack
  2. Log in with your admin credentials
  3. Go to Identity - Projects
  4. Click on + Create Project

  It would throw the error mentioned above.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1421616/+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 1428598] Re: Horizon for Manila throws ERROR UNAUTHORIZED notification

2015-03-05 Thread Vinay Prasad M
Thanks Gary. I will follow it up with the custom fork owner. Can you
please let me know when is Manila available with the actual Horizon.
Waiting for it.

** Changed in: manila
   Status: New = Invalid

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

Title:
  Horizon for Manila throws ERROR UNAUTHORIZED notification

Status in OpenStack Dashboard (Horizon):
  Invalid
Status in Manila:
  Invalid

Bug description:
  I have devstack setup of stable/juno release  with Manila enabled. 
  Configured with Horizon custom project of Manila. All Manila operations works 
fine with Command line but throws below errors on logging in to Horizon

  Error: Unauthorized: Unable to retrieve share limit information.

  On click of Shares tab throws : 
  Error: Unauthorized: Unable to retrieve share list.
  ×
  Error: Unauthorized: Unable to retrieve snapshot list.
  ×
  Error: Unauthorized: Unable to retrieve share networks
  ×
  Error: Unauthorized: Unable to retrieve security services
  ×
  Error: Unauthorized: Unable to retrieve volume types
  ×
  Error: Unauthorized: Unable to retrieve share servers

  I am using stable/juno version of devstack and manila
  manila_juno version of HORIZON_REPO=https://github.com/NetApp/horizon.git

  Request you to please have a look.

  Have also tried the same with Kilo release as per instructions in
  https://wiki.openstack.org/wiki/Manila/KiloDevstack and Horizon setup
  instruction in
  https://wiki.openstack.org/wiki/Manila/docs/HOWTO_use_manila_with_horizon.

  Gives me same ERROR in horizon

  Regards,
  Vinay P

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