date:20160503

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

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

Title:
  test_dhcp6_stateless_from_os fails to ping intermittently

Status in neutron:
  Expired

Bug description:
  This appears to be spiking since 7/22:

  http://logs.openstack.org/80/200380/3/gate/gate-tempest-dsvm-neutron-
  full/2b49b0d/console.html#_2015-07-22_09_57_50_146

  2015-07-22 09:57:50.146 | 
tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac[compute,id-dec222b1-180c-4098-b8c5-cc1b8342d611,network]
  2015-07-22 09:57:50.146 | 

  2015-07-22 09:57:50.146 | 
  2015-07-22 09:57:50.146 | Captured traceback:
  2015-07-22 09:57:50.146 | ~~~
  2015-07-22 09:57:50.147 | Traceback (most recent call last):
  2015-07-22 09:57:50.147 |   File "tempest/test.py", line 126, in wrapper
  2015-07-22 09:57:50.147 | return f(self, *func_args, **func_kwargs)
  2015-07-22 09:57:50.147 |   File "tempest/scenario/test_network_v6.py", 
line 183, in test_multi_prefix_slaac
  2015-07-22 09:57:50.147 | 
self._prepare_and_test(address6_mode='slaac', n_subnets6=2)
  2015-07-22 09:57:50.147 |   File "tempest/scenario/test_network_v6.py", 
line 150, in _prepare_and_test
  2015-07-22 09:57:50.147 | result = 
sshv4_2.ping_host(ips_from_api_1['4'])
  2015-07-22 09:57:50.147 |   File 
"tempest/common/utils/linux/remote_client.py", line 101, in ping_host
  2015-07-22 09:57:50.147 | return self.exec_command(cmd)
  2015-07-22 09:57:50.147 |   File 
"tempest/common/utils/linux/remote_client.py", line 56, in exec_command
  2015-07-22 09:57:50.147 | return self.ssh_client.exec_command(cmd)
  2015-07-22 09:57:50.147 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 146, in exec_command
  2015-07-22 09:57:50.148 | strerror=''.join(err_data))
  2015-07-22 09:57:50.148 | tempest_lib.exceptions.SSHExecCommandFailed: 
Command 'set -eu -o pipefail; PATH=$PATH:/sbin; ping -c1 -w1 -s56 10.100.0.3', 
exit status: 1, Error:

  There are so many errors in the neutron logs for false negatives that
  I can't really tell what could be causing the failures, see related
  bug 1455320 and related bug 1477190.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1477192/+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 1540983] Re: Gate failures for neutron in test_dualnet_multi_prefix_slaac

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

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

Title:
  Gate failures for neutron in test_dualnet_multi_prefix_slaac

Status in neutron:
  Expired
Status in OpenStack-Gate:
  Expired

Bug description:
  24 hits in 7 days for logstash query : message:"in
  test_dualnet_multi_prefix_slaac" AND voting:1

  2016-02-02 14:35:49.054 | Captured traceback:
  2016-02-02 14:35:49.054 | ~~~
  2016-02-02 14:35:49.054 | Traceback (most recent call last):
  2016-02-02 14:35:49.054 |   File "tempest/test.py", line 113, in wrapper
  2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 246, in test_dualnet_multi_prefix_slaac
  2016-02-02 14:35:49.055 | dualnet=True)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 155, in _prepare_and_test
  2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = 
self.prepare_server(networks=net_list)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 128, in prepare_server
  2016-02-02 14:35:49.055 | username=username)
  2016-02-02 14:35:49.056 |   File "tempest/scenario/manager.py", line 390, 
in get_remote_client
  2016-02-02 14:35:49.056 | linux_client.validate_authentication()
  2016-02-02 14:35:49.056 |   File 
"tempest/common/utils/linux/remote_client.py", line 63, in 
validate_authentication
  2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth()
  2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 172, in test_connection_auth
  2016-02-02 14:35:49.056 | connection = self._get_ssh_connection()
  2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 87, in _get_ssh_connection
  2016-02-02 14:35:49.057 | password=self.password)
  2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection 
to the 172.24.5.141 via SSH timed out.
  2016-02-02 14:35:49.057 | User: cirros, Password: None

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1540983/+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 1540983] Re: Gate failures for neutron in test_dualnet_multi_prefix_slaac

[Expired for OpenStack-Gate because there has been no activity for 60
days.]

** Changed in: openstack-gate
   Status: Incomplete => Expired

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

Title:
  Gate failures for neutron in test_dualnet_multi_prefix_slaac

Status in neutron:
  Expired
Status in OpenStack-Gate:
  Expired

Bug description:
  24 hits in 7 days for logstash query : message:"in
  test_dualnet_multi_prefix_slaac" AND voting:1

  2016-02-02 14:35:49.054 | Captured traceback:
  2016-02-02 14:35:49.054 | ~~~
  2016-02-02 14:35:49.054 | Traceback (most recent call last):
  2016-02-02 14:35:49.054 |   File "tempest/test.py", line 113, in wrapper
  2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 246, in test_dualnet_multi_prefix_slaac
  2016-02-02 14:35:49.055 | dualnet=True)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 155, in _prepare_and_test
  2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = 
self.prepare_server(networks=net_list)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 128, in prepare_server
  2016-02-02 14:35:49.055 | username=username)
  2016-02-02 14:35:49.056 |   File "tempest/scenario/manager.py", line 390, 
in get_remote_client
  2016-02-02 14:35:49.056 | linux_client.validate_authentication()
  2016-02-02 14:35:49.056 |   File 
"tempest/common/utils/linux/remote_client.py", line 63, in 
validate_authentication
  2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth()
  2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 172, in test_connection_auth
  2016-02-02 14:35:49.056 | connection = self._get_ssh_connection()
  2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 87, in _get_ssh_connection
  2016-02-02 14:35:49.057 | password=self.password)
  2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection 
to the 172.24.5.141 via SSH timed out.
  2016-02-02 14:35:49.057 | User: cirros, Password: None

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1540983/+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 1578009] [NEW] Add 'help_url' example to local_settings.py

2016-05-03 Thread Rodrigo Castrillon

Public bug reported:

Following instructions here: http://docs.openstack.org/admin-
guide/common/dashboard_customizing.html, in section #Help URL, will
break Horizon.

Docs say to edit 'help_url' in local_settings.py, but the option isnt there. 
Please add a line:
HORIZON_CONFIG["help_url"] = "http://openstack.mycompany.org;

I have also opened another bug in openstack-manuals to get docs updated:
https://bugs.launchpad.net/openstack-manuals/+bug/1578008

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

Title:
  Add 'help_url' example to local_settings.py

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Following instructions here: http://docs.openstack.org/admin-
  guide/common/dashboard_customizing.html, in section #Help URL, will
  break Horizon.

  Docs say to edit 'help_url' in local_settings.py, but the option isnt there. 
Please add a line:
  HORIZON_CONFIG["help_url"] = "http://openstack.mycompany.org;

  I have also opened another bug in openstack-manuals to get docs updated:
  https://bugs.launchpad.net/openstack-manuals/+bug/1578008

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

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

[Yahoo-eng-team] [Bug 1577996] [NEW] Unable to distinguish between not is_admin_project and feature not enabled

2016-05-03 Thread Jamie Lennox

Public bug reported:

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

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

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

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

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

** Affects: keystone
 Importance: Undecided
 Assignee: Adam Young (ayoung)
 Status: New

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

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

Status in OpenStack Identity (keystone):
  New

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

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

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

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

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

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

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

[Yahoo-eng-team] [Bug 1490531] Re: api: deprecate the concept of extensions in v2.1

Reviewed:  https://review.openstack.org/310399
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=75280e582e6d607b38bc2af9f51f80fd5135453c
Submitter: Jenkins
Branch:master

commit 75280e582e6d607b38bc2af9f51f80fd5135453c
Author: sharat.sharma 
Date:   Wed Apr 27 15:26:03 2016 +0530

Deprecated the concept of extensions in v2.1.

The extensions in api-ref-compute-v2.1 is deprecated. This patch
depricates the extension infrastructure in v2.1.

Change-Id: Ie7731c25ee7c5c662c22835add3314ffa51f37bc
Closes-Bug: #1490531


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

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

Title:
  api: deprecate the concept of extensions in v2.1

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  https://review.openstack.org/214592
  commit 11507eeceb2c56e50e9fe030a70470a02f577f2a
  Author: John Garbutt 
  Date:   Wed Aug 19 13:46:52 2015 +0100

  api: deprecate the concept of extensions in v2.1
  
  We want to remove the extension infrastructure in the v2.1 API during
  the next release. To make that possible, we must deprecate the
  configuration now.
  
  Also deprecating the osapi_v3 group, and moving to osapi_v21.
  
  UpgradeImpact
  DocImpact
  
  Part of blueprint nova-api-deprecate-extensions
  
  Change-Id: I08b11dceda7cf8f88c157aa67d36490fce49

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1490531/+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 1521791] Re: Nova client incorrectly lists block storage size units in GB

Reviewed:  https://review.openstack.org/310414
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=4c5ba52b7421734e1910d2611cb72bbaa2536d69
Submitter: Jenkins
Branch:master

commit 4c5ba52b7421734e1910d2611cb72bbaa2536d69
Author: sharat.sharma 
Date:   Wed Apr 27 16:40:01 2016 +0530

Changed the storage size from GB to GiB.

Change-Id: Iede32b2764b9329bf9dc3d8aec02064db1f16d05
Closes-Bug: #1521791


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

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

Title:
  Nova client incorrectly lists block storage size units in GB

Status in OpenStack Compute (nova):
  Fix Released
Status in openstack-api-site:
  Invalid
Status in python-novaclient:
  In Progress

Bug description:
  Both Horizon and the nova client documents the block storage size
  parameters in gigabytes(GB), when it should be in gibibytes (GiB).

  Both the cinder and manila clients and associated Horizon panels have
  been changed to address this issue. Nova should follow suit for
  consistency.

  Related bugs:
  https://bugs.launchpad.net/horizon/+bug/1511167
  https://bugs.launchpad.net/python-manilaclient/+bug/1516841
  https://bugs.launchpad.net/horizon/+bug/1516848

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1521791/+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 1577991] [NEW] No exception mapping between glance and glance_store

2016-05-03 Thread Fei Long Wang

Public bug reported:

2016-05-04 11:06:59.717 2854 ERROR glance.common.wsgi 
[req-9f9d9912-e5ba-4ed1-89bd-e8e13b7a97fc 79f60e6ab1bf4b2fbe7987c6c2b57e63 
94b566de52f9423fab80ceee8c0a4a23 - - -] Caught error: The image cannot be 
deleted because it is in use through the backend store outside of Glance.
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi Traceback (most recent 
call last):
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/wsgi.py",
 line 881, in __call__
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi request, 
**action_args)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/wsgi.py",
 line 909, in dispatch
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return method(*args, 
**kwargs)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/utils.py",
 line 508, in wrapped
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return func(self, 
req, *args, **kwargs)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/api/v1/images.py",
 line 1099, in delete
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi {'status': 
ori_status})
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 85, in __exit__
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi 
six.reraise(self.type_, self.value, self.tb)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/api/v1/images.py",
 line 1095, in delete
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi 
upload_utils.initiate_deletion(req, loc_data, id)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/api/v1/upload_utils.py",
 line 46, in initiate_deletion
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi id, location_data)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/store_utils.py",
 line 124, in delete_image_location_from_backend
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi 
safe_delete_from_backend(context, image_id, location)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance/common/store_utils.py",
 line 58, in safe_delete_from_backend
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi ret = 
store_api.delete_from_backend(location['url'], context=context)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/backend.py",
 line 290, in delete_from_backend
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return 
store.delete(loc, context=context)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/capabilities.py",
 line 226, in op_checker
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi return 
store_op_fun(store, *args, **kwargs)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/_drivers/rbd.py",
 line 410, in delete
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi 
self._delete_image(target_pool, loc.image, loc.snapshot)
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi   File 
"/opt/cat/openstack/glance/local/lib/python2.7/site-packages/glance_store/_drivers/rbd.py",
 line 304, in _delete_image
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi raise 
exceptions.InUseByStore()
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi InUseByStore: The image 
cannot be deleted because it is in use through the backend store outside of 
Glance.
2016-05-04 11:06:59.717 2854 TRACE glance.common.wsgi 
2016-05-04 11:06:59.722 2854 INFO eventlet.wsgi.server 
[req-9f9d9912-e5ba-4ed1-89bd-e8e13b7a97fc 79f60e6ab1bf4b2fbe7987c6c2b57e63 
94b566de52f9423fab80ceee8c0a4a23 - - -] 10.13.0.41 - - [04/May/2016 11:06:59] 
"DELETE /v1/images/a8876333-16c5-4a21-a3fb-7b24c29a7308 HTTP/1.1" 500 430 
0.513240

** Affects: glance
 Importance: Undecided
 Assignee: Fei Long Wang (flwang)
 Status: Invalid

** Changed in: glance
 Assignee: (unassigned) => Fei Long Wang (flwang)

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

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

Title:
  No exception mapping between glance and glance_store

[Yahoo-eng-team] [Bug 1577987] [NEW] neutron-lbaas v2 - update pool's session_persistence to None fails

2016-05-03 Thread Madhusudhan Kandadai

Public bug reported:

When updating a pool's session_persistence to None, I get the following
error: Invalid input for session_persistence


1.  Create a loadbalancer, listener 

2. Create a pool with default args:

using postman:

{
"pool": {
"name": "pool1",
"description": "simple pool",
"listener_id": "39de4d56-d663-46e5-85a1-5b9d5fa17829",
"lb_algorithm": "ROUND_ROBIN",
"protocol": "HTTP",
"session_persistence": {
"type": "APP_COOKIE",
"cookie_name": "my_cookie"
},
"admin_state_up": true
}
}

Update pool with below data:

{
"pool": {
"session_persistence": {"type": ""}
}
}


neutron-server logs: 

2016-05-03 16:39:54.698 DEBUG neutron.wsgi [-] (66382) accepted 
('192.168.109.128', 58400) from (pid=66382) server 
/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py:867
2016-05-03 16:39:55.025 DEBUG neutron.api.v2.base 
[req-78bc175f-374d-403c-b5a5-845d4bc79632 admin 
be81e9163d074036913aa52b1b9785a7] Request body: {u'pool': 
{u'session_persistence': {u'type': u''}}} from (pid=66382) prepare_request_body 
/opt/stack/neutron/neutron/api/v2/base.py:658
2016-05-03 16:39:55.025 DEBUG neutron_lib.api.validators 
[req-78bc175f-374d-403c-b5a5-845d4bc79632 admin 
be81e9163d074036913aa52b1b9785a7] ' ' is not in ('SOURCE_IP', 'HTTP_COOKIE', 
'APP_COOKIE') from (pid=66382) validate_values 
/usr/local/lib/python2.7/dist-packages/neutron_lib/api/validators.py:91
2016-05-03 16:39:55.026 INFO neutron.api.v2.resource 
[req-78bc175f-374d-403c-b5a5-845d4bc79632 admin 
be81e9163d074036913aa52b1b9785a7] update failed (client error): Invalid input 
for session_persistence. Reason: '' is not in ('SOURCE_IP', 'HTTP_COOKIE', 
'APP_COOKIE').
2016-05-03 16:39:55.027 INFO neutron.wsgi 
[req-78bc175f-374d-403c-b5a5-845d4bc79632 admin 
be81e9163d074036913aa52b1b9785a7] 192.168.109.128 - - [03/May/2016 16:39:55] 
"PUT /v2.0/lbaas/pools/aa341feb-ff6f-4d87-a613-52812c665bc0 HTTP/1.1" 400 400 
0.327893


using CLI:


neutron lbaas-pool-update pool1 --session_persistence type=dict type=none
Invalid input for session_persistence. Reason: 'none' is not in ('SOURCE_IP', 
'HTTP_COOKIE', 'APP_COOKIE').
Neutron server returns request_ids: ['req-93cc8a21-4243-4498-899c-fc9646cddb71']


neutron-server logs:

2016-05-03 16:41:31.834 DEBUG 
neutron_lbaas.drivers.octavia.octavia_messaging_consumer [-] Received event 
from stream {u'info_type': u'listener_stats', u'info_id': 
u'04c16cac-b748-47a6-975f-b109bd80a419', u'info_payload': {u'bytes_in': 0, 
u'total_connections': 0, u'active_connections': 0, u'bytes_out': 0}} from 
(pid=66202) update_info 
/opt/stack/neutron-lbaas/neutron_lbaas/drivers/octavia/octavia_messaging_consumer.py:74
2016-05-03 16:41:34.571 DEBUG neutron.wsgi [-] (66383) accepted 
('192.168.109.128', 59130) from (pid=66383) server 
/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py:867
2016-05-03 16:41:35.079 INFO neutron.wsgi 
[req-695f0831-c84d-43b3-ae37-764cd4a4fd9c admin 
be81e9163d074036913aa52b1b9785a7] 192.168.109.128 - - [03/May/2016 16:41:35] 
"GET /v2.0/lbaas/pools.json?fields=id=pool1 HTTP/1.1" 200 607 0.506676
2016-05-03 16:41:35.333 DEBUG neutron.api.v2.base 
[req-93cc8a21-4243-4498-899c-fc9646cddb71 admin 
be81e9163d074036913aa52b1b9785a7] Request body: {u'pool': 
{u'session_persistence': {u'type': u'none'}}} from (pid=66383) 
prepare_request_body /opt/stack/neutron/neutron/api/v2/base.py:658
2016-05-03 16:41:35.335 DEBUG neutron_lib.api.validators 
[req-93cc8a21-4243-4498-899c-fc9646cddb71 admin 
be81e9163d074036913aa52b1b9785a7] 'none' is not in ('SOURCE_IP', 'HTTP_COOKIE', 
'APP_COOKIE') from (pid=66383) validate_values 
/usr/local/lib/python2.7/dist-packages/neutron_lib/api/validators.py:91
2016-05-03 16:41:35.336 INFO neutron.api.v2.resource 
[req-93cc8a21-4243-4498-899c-fc9646cddb71 admin 
be81e9163d074036913aa52b1b9785a7] update failed (client error): Invalid input 
for session_persistence. Reason: 'none' is not in ('SOURCE_IP', 'HTTP_COOKIE', 
'APP_COOKIE').
2016-05-03 16:41:35.342 INFO neutron.wsgi 
[req-93cc8a21-4243-4498-899c-fc9646cddb71 admin 
be81e9163d074036913aa52b1b9785a7] 192.168.109.128 - - [03/May/2016 16:41:35] 
"PUT /v2.0/lbaas/pools/aa341feb-ff6f-4d87-a613-52812c665bc0.json HTTP/1.1" 400 
403 0.258400
2016-05-03 16:41:36.258 DEBUG oslo_messaging._drivers.amqpdriver [-] received 
message msg_id: None reply to None from (pid=66384) __call__ 
/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:201

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: lbaas

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

Title:
  neutron-lbaas v2 - update pool's session_persistence to None fails

Status in neutron:
  New

Bug description:
  When updating a pool's session_persistence to None, I get the
  following error: Invalid

[Yahoo-eng-team] [Bug 1577982] [NEW] ConfigDrive: cloud-init fails to configure network from network_data.json

2016-05-03 Thread Mathieu Gagné

Public bug reported:

When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly
configure the network from network_data.json found in ConfigDrive.

When instance boots, network is configured fine until next reboot where
it falls back to dhcp.

The /etc/network/interfaces.d/50-cloud-init.cfg file has the following
content when instance is initially booted, this could explain why dhcp
is used on second boot:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

When debugging, if this line in stages.py [1] is commented, we can see
that cloud-init initially copy the /etc/network/interfaces file found in
the configdrive (the network template injected by Nova) and isn't using
the network config found in network_data.json. But later it falls back
to "dhcp" and rewrites yet again the network config.

I also found that within self._find_networking_config(), it looks like
no datasource is found at this point. This could be because cloud-init
is still in "local" dsmode and then refuses to use the network config
found in the ConfigDrive. (triggering the "dhcp" fallback logic)

Manually forcing "net" dsmode makes cloud-init configure
/etc/network/interfaces.d/50-cloud-init.cfg properly with network config
found in the ConfigDrive. However no gateway is configured and so,
instance doesn't respond to ping or SSH.

At that point, I'm not sure what's going on and how I can debug further.

Notes:
* The image used for testing uses "net.ifnames=0". Removing this config makes 
things much worst. (no ping at all on first boot)
* Logs, configs and configdrive can be found attached to this bug report.

[1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-
init/trunk/view/head:/cloudinit/stages.py#L604

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

** Attachment added: "cloud-init configs, logs and configdrive"
   
https://bugs.launchpad.net/bugs/1577982/+attachment/4654849/+files/debug.tar.gz

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

Title:
  ConfigDrive: cloud-init fails to configure network from
  network_data.json

Status in cloud-init:
  New

Bug description:
  When running Ubuntu 16.04 on OpenStack, cloud-init fails to properly
  configure the network from network_data.json found in ConfigDrive.

  When instance boots, network is configured fine until next reboot
  where it falls back to dhcp.

  The /etc/network/interfaces.d/50-cloud-init.cfg file has the following
  content when instance is initially booted, this could explain why dhcp
  is used on second boot:

  auto lo
  iface lo inet loopback
  
  auto eth0
  iface eth0 inet dhcp

  When debugging, if this line in stages.py [1] is commented, we can see
  that cloud-init initially copy the /etc/network/interfaces file found
  in the configdrive (the network template injected by Nova) and isn't
  using the network config found in network_data.json. But later it
  falls back to "dhcp" and rewrites yet again the network config.

  I also found that within self._find_networking_config(), it looks like
  no datasource is found at this point. This could be because cloud-init
  is still in "local" dsmode and then refuses to use the network config
  found in the ConfigDrive. (triggering the "dhcp" fallback logic)

  Manually forcing "net" dsmode makes cloud-init configure
  /etc/network/interfaces.d/50-cloud-init.cfg properly with network
  config found in the ConfigDrive. However no gateway is configured and
  so, instance doesn't respond to ping or SSH.

  At that point, I'm not sure what's going on and how I can debug
  further.

  Notes:
  * The image used for testing uses "net.ifnames=0". Removing this config makes 
things much worst. (no ping at all on first boot)
  * Logs, configs and configdrive can be found attached to this bug report.

  [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud-
  init/trunk/view/head:/cloudinit/stages.py#L604

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1577982/+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 1544720] Re: In response template processing, some values are set to u'' instead of None

2016-05-03 Thread Sujitha

I couldn't reproduce the bug.

I changed the value for OS-EXT-SRV-ATTR:kernel_id from null to
"test_kernel" in both server-get-resp.json.tpl and server-get-resp.json.
Test fails because value in template(test_kernel) and actual
response('') is different. This is expected. Also value in Response is
not u'' as mentioned in the description.

I don't see any unexpected behavior. Moving the bug to invalid.

** Changed in: nova
Status: Confirmed => 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/1544720

Title:
In response template processing, some values are set to u'' instead of
None

Status in OpenStack Compute (nova):
Invalid

Bug description:
I discovered this bug while refactoring functional tests. This happens
in the current Nova master.

Update the following files:
-
nova/tests/functional/api_sample_tests/api_samples/os-extended-server-attributes/v2.16/server-get-resp.json.tpl
-
nova/doc/api_samples/os-extended-server-attributes/v2.16/server-get-resp.json

Set the field "OS-EXT-SRV-ATTR:kernel_id" from "null" to a value.
Run functional tests (or just
nova/tests/functional/api_sample_tests/test_extended_server_attributes.py) and
you'll see that the value you for the response has been replaced with u''.

Not sure if this is in nova itself or just the test framework, more
research needed.

I'm creating this bug to make sure I don't forget to come back and
troubleshoot this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1544720/+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 1577913] [NEW] [RFE] On-demand segment and subnet allocation

2016-05-03 Thread Han Zhou

Public bug reported:

While routed networks [1] provides us the capability of managing L2
segments and related subnets with a view of L3 network, it assumes that
the related infrastructure resources are always provisioned (vlans,
host-segment bindings, subnets) beforehand and is not managed by
neutron. However, in a large deployment cloud, there are use cases for
on-demand resource provisioning.

- On-demand segment provisioning:

A host can be multi-tenancy, so when a host is provisioned, it may be
unknown which tenant's VMs will be scheduled to the host. So some
segments may not be needed for the host. It will be good if we can
dynamically create the segment (i.e. create the vlan on the ToR) when
the first VM of the tenant is scheduled under the ToR, then we don't
need to pre-allocate all the possible vlans and create segments for all
the ToRs.

The information that is known duiring host onboarding is the ToR that
the host is located. So we can model this as a BridgeGroup object (a
group of vlans/l2 segments spanning across the same set of hosts, which
are usually connected to a group of devices, and number of devices are
usually 1, e.g. the ToR connecting the hosts under a rack), and
BridgeGroup-Host mapping. And when the first neutron port is requested
to be created on a routed network for a host under a BridgeGroup, a new
segment is created and bound to the host.

- On-demand subnet provisioning:

In a shared infrastructure the workload location is flexible, so it is
hard to predict the number of IPs required for a segment. To use IP
resource (especially IPv4) efficiently, it will be good to be able to
dynamically allocate subnets to a segment only when it is needed, i.e.
when there are workloads scheduled to the segment.

This feature request requires [1] but put additional requirements on top
of it.

[1] https://review.openstack.org/#/c/225384/

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: rfe

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

Title:
  [RFE] On-demand segment and subnet allocation

Status in neutron:
  New

Bug description:
  While routed networks [1] provides us the capability of managing L2
  segments and related subnets with a view of L3 network, it assumes
  that the related infrastructure resources are always provisioned
  (vlans, host-segment bindings, subnets) beforehand and is not managed
  by neutron. However, in a large deployment cloud, there are use cases
  for on-demand resource provisioning.

  - On-demand segment provisioning:

  A host can be multi-tenancy, so when a host is provisioned, it may be
  unknown which tenant's VMs will be scheduled to the host. So some
  segments may not be needed for the host. It will be good if we can
  dynamically create the segment (i.e. create the vlan on the ToR) when
  the first VM of the tenant is scheduled under the ToR, then we don't
  need to pre-allocate all the possible vlans and create segments for
  all the ToRs.

  The information that is known duiring host onboarding is the ToR that
  the host is located. So we can model this as a BridgeGroup object (a
  group of vlans/l2 segments spanning across the same set of hosts,
  which are usually connected to a group of devices, and number of
  devices are usually 1, e.g. the ToR connecting the hosts under a
  rack), and BridgeGroup-Host mapping. And when the first neutron port
  is requested to be created on a routed network for a host under a
  BridgeGroup, a new segment is created and bound to the host.

  - On-demand subnet provisioning:

  In a shared infrastructure the workload location is flexible, so it is
  hard to predict the number of IPs required for a segment. To use IP
  resource (especially IPv4) efficiently, it will be good to be able to
  dynamically allocate subnets to a segment only when it is needed, i.e.
  when there are workloads scheduled to the segment.

  This feature request requires [1] but put additional requirements on
  top of it.

  [1] https://review.openstack.org/#/c/225384/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1577913/+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 1577909] [NEW] hz-dynamic-table has two magic-search bars

2016-05-03 Thread Matt Borland

Public bug reported:

The hz-dynamic-table directive's template has two magic-search bars, one
correctly outside the table, the other incorrectly placed inside the
table.

The one inside the table should be removed.

A proper implementation of the hz-dynamic-table directive using magic-
search will illustrate the problem.

** Affects: horizon
 Importance: Undecided
 Assignee: Matt Borland (palecrow)
 Status: In Progress

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

Title:
  hz-dynamic-table has two magic-search bars

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The hz-dynamic-table directive's template has two magic-search bars,
  one correctly outside the table, the other incorrectly placed inside
  the table.

  The one inside the table should be removed.

  A proper implementation of the hz-dynamic-table directive using magic-
  search will illustrate the problem.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1577909/+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 1361554] Re: Missing sort_key and sort_dir for server list api

2016-05-03 Thread Pushkar Umaranikar

Marking it as "invalid" due to existing similar patch
https://review.openstack.org/#/c/96345/

** Changed in: nova
   Status: Confirmed => 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/1361554

Title:
  Missing sort_key and sort_dir for server list api

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Since the compute api now supporting sort_dir and sort_key [1], we may
  need to add this to the REST api.

  [1]:
  https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1790

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1361554/+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 1525806] Re: An incorrect value for block_device_mapping_v2 causes HTTP 500 response when creating a VM instance

Reviewed:  https://review.openstack.org/258788
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=9ad3dad0c6ab868566e74f0c35a5375d4eaad560
Submitter: Jenkins
Branch:master

commit 9ad3dad0c6ab868566e74f0c35a5375d4eaad560
Author: Takashi NATSUME 
Date:   Mon Mar 14 14:26:11 2016 +0900

Add validations for volume_size and destination_type

Add validations for volume_size and destination_type of
block device mapping when creating an instance
in order to avoid HTTP 500 errors.
Validations has been added in V2.1 API only.
Validations that has been added are as follows:

* volume_size: an empty string
* volume_size: zero
* volume_size: greater than DB column's limit
* destination_type: an empty string
* destination_type: invalid value

Change-Id: I2d3084cccd15f409616031f106c611ff07ac4abf
Closes-Bug: #1525806


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

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

Title:
  An incorrect value for block_device_mapping_v2 causes HTTP 500
  response when creating a VM instance

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  An incorrect value for block_device_mapping_v2 causes HTTP 500 response when 
creating a VM instance.
  It should be validated and not to return HTTP 500 response.

  [How to reproduce]
  a) destination_type is ""(an empty string)
  Execute the following command(REST API).
  curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X POST 
http://10.0.2.15:8774/v2.1/e7e043ffac8d4325b2872bd2b53cce2b/os-volumes_boot -H 
"User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: 
{SHA1}00abb28e025a6770fc13d70fc6a41e327bca90d6" -d '{"server": {"name": 
"server1", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", 
"uuid": "4115a0d1-eee2-4c3e-847d-e50250a989a3", "volume_size": "1", 
"source_type": "image", "destination_type": "", "delete_on_termination": 
false}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'

  The response is as follows:
  --
  HTTP/1.1 500 Internal Server Error
  X-Openstack-Nova-Api-Version: 2.6
  Vary: X-OpenStack-Nova-API-Version
  Content-Length: 194
  Content-Type: application/json; charset=UTF-8
  X-Compute-Request-Id: req-29fb2efe-eda8-43dd-8ea1-5f73b86f6171
  Date: Mon, 14 Dec 2015 07:17:24 GMT

  {"computeFault": {"message": "Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n", "code": 500}}
  --

  b) destination_type is neither 'volume' nor 'local'
  Execute the following command(REST API).
  curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X POST 
http://10.0.2.15:8774/v2.1/e7e043ffac8d4325b2872bd2b53cce2b/os-volumes_boot -H 
"User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: 
{SHA1}7add7a5e501cc287f6043d83144ea24a69134ae7" -d '{"server": {"name": 
"server1", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", 
"uuid": "4115a0d1-eee2-4c3e-847d-e50250a989a3", "volume_size": "1", 
"source_type": "image", "destination_type": "X", "delete_on_termination": 
false}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'

  The response is as follows:
  --
  HTTP/1.1 500 Internal Server Error
  X-Openstack-Nova-Api-Version: 2.6
  Vary: X-OpenStack-Nova-API-Version
  Content-Length: 194
  Content-Type: application/json; charset=UTF-8
  X-Compute-Request-Id: req-f3644722-ba2c-49bf-9db0-badfd7dffa30
  Date: Mon, 14 Dec 2015 07:30:02 GMT

  {"computeFault": {"message": "Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.\n", "code": 500}}
  --

  c) volume_size is ""(an empty string)
  Execute the following command(REST API).
  curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X POST 
http://10.0.2.15:8774/v2.1/e7e043ffac8d4325b2872bd2b53cce2b/os-volumes_boot -H 
"User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-Auth-Token: 
{SHA1}85cc81c3f710561ddd640ce26c41990703d925ce" -d '{"server": {"name": 
"server1", "imageRef": "", "block_device_mapping_v2": [{"boot_index": "0", 
"uuid": "4115a0d1-eee2-4c3e-847d-e50250a989a3", "volume_size": "", 
"source_type": "image", "destination_type": "volume", "delete_on_termination": 
false}], "flavorRef": "1", "max_count": 1, "min_count": 1}}'

  The response is as follows:
  --
  HTTP/1.1 500 Internal Server Error
  X-Openstack-Nova-Api-Version: 2.1
  Vary:

[Yahoo-eng-team] [Bug 1554231] Re: Clean up warnings about keystoneclient.adapter.Adapter

2016-05-03 Thread Markus Zoeller (markus_z)

These warnings get triggered by the python-cinderlient which uses
deprecated keystoneclient code. Nova cannot prevent that. The Cinder
folks should look into that.

Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/test_cinder.py", line 238, in 
test_volume_without_attachment
volume = self.api.get(self.context, '5678')
  File "nova/volume/cinder.py", line 232, in wrapper
res = method(self, ctx, *args, **kwargs)
  File "nova/volume/cinder.py", line 255, in wrapper
res = method(self, ctx, volume_id, *args, **kwargs)
  File "nova/volume/cinder.py", line 301, in get
item = cinderclient(context).volumes.get(volume_id)
  File "nova/volume/cinder.py", line 147, in cinderclient
**service_parameters)
  File 
"/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/cinderclient/client.py",
 line 634, in Client
return client_class(*args, **kwargs)
  File 
"/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/cinderclient/v2/client.py",
 line 117, in __init__
**kwargs)
  File 
"/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/cinderclient/client.py",
 line 551, in _construct_http_client
**kwargs)
  File 
"/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/positional/__init__.py",
 line 101, in inner
return wrapped(*args, **kwargs)
  File 
"/home/mzoeller/git/nova/.tox/py27/lib/python2.7/site-packages/keystoneclient/adapter.py",
 line 54, in __init__
raise Exception("mzoeller: baem!!")
Exception: mzoeller: baem!!

** Project changed: nova => python-cinderclient

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

Title:
  Clean up warnings about keystoneclient.adapter.Adapter

Status in python-cinderclient:
  Confirmed

Bug description:
  Nova test runs output a bunch of warnings about
  keystoneclient.adapter.Adapter:

  Captured stderr:
  
  
/home/jaypipes/repos/nova/.tox/py27/local/lib/python2.7/site-packages/keystoneclient/adapter.py:57:
 DeprecationWarning: keystoneclient.adapter.Adapter is deprecated as of the 
2.1.0 release in favor of keystoneauth1.adapter.Adapter. It will be removed in 
future releases.
'removed in future releases.', DeprecationWarning)

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-cinderclient/+bug/1554231/+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 1577861] [NEW] error when Populate the database Neutron on controller node

2016-05-03 Thread Adnan

Public bug reported:

I am following the Openstack documentation
http://docs.openstack.org/mitaka/install-guide-ubuntu/neutron-
controller-install.html for installing Openstack on Ubuntu server 14.04.
there is an instruction to finalize the installation of Neutron on the
controller node with the following command;

# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \
  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

However, I get the following error;

root@controller:/home/controller # su -s /bin/sh -c "neutron-db-manage 
--config-file /etc/neutron/neutron.conf \
  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
No handlers could be found for logger "oslo_config.cfg"
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
  Running upgrade for neutron ...
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
INFO  [alembic.runtime.migration] Running upgrade dce3ec7a25c9 -> c3a73f615e4, 
Add ip_version to AddressScope
Traceback (most recent call last):
  File "/usr/bin/neutron-db-manage", line 10, in 
sys.exit(main())
  File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
753, in main
return_val |= bool(CONF.command.func(config, CONF.command.name))
  File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
226, in do_upgrade
desc=branch, sql=CONF.command.sql)
  File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
128, in do_alembic_command
getattr(alembic_command, cmd)(config, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/alembic/command.py", line 174, in 
upgrade
script.run_env()
  File "/usr/lib/python2.7/dist-packages/alembic/script/base.py", line 397, in 
run_env
util.load_python_file(self.dir, 'env.py')
  File "/usr/lib/python2.7/dist-packages/alembic/util/pyfiles.py", line 81, in 
load_python_file
module = load_module_py(module_id, path)
  File "/usr/lib/python2.7/dist-packages/alembic/util/compat.py", line 79, in 
load_module_py
mod = imp.load_source(module_id, path, fp)
  File 
"/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py",
 line 126, in 
run_migrations_online()
  File 
"/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/env.py",
 line 120, in run_migrations_online
context.run_migrations()
  File "", line 8, in run_migrations
  File "/usr/lib/python2.7/dist-packages/alembic/runtime/environment.py", line 
797, in run_migrations
self.get_context().run_migrations(**kw)
  File "/usr/lib/python2.7/dist-packages/alembic/runtime/migration.py", line 
312, in run_migrations
step.migration_fn(**kw)
  File 
"/usr/lib/python2.7/dist-packages/neutron/db/migration/alembic_migrations/versions/mitaka/expand/c3a73f615e4_add_ip_version_to_address_scope.py",
 line 33, in upgrade
sa.Column('ip_version', sa.Integer(), nullable=False))
  File "", line 8, in add_column
  File "", line 3, in add_column
  File "/usr/lib/python2.7/dist-packages/alembic/operations/ops.py", line 1535, 
in add_column
return operations.invoke(op)
  File "/usr/lib/python2.7/dist-packages/alembic/operations/base.py", line 318, 
in invoke
return fn(self, operation)
  File "/usr/lib/python2.7/dist-packages/alembic/operations/toimpl.py", line 
123, in add_column
schema=schema
  File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 172, in 
add_column
self._exec(base.AddColumn(table_name, column, schema=schema))
  File "/usr/lib/python2.7/dist-packages/alembic/ddl/impl.py", line 118, in 
_exec
return conn.execute(construct, *multiparams, **params)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 914, 
in execute
return meth(self, multiparams, params)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/sql/ddl.py", line 68, in 
_execute_on_connection
return connection._execute_ddl(self, multiparams, params)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 968, 
in _execute_ddl
compiled
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1146, 
in _execute_context
context)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1337, 
in _handle_dbapi_exception
util.raise_from_cause(newraise, exc_info)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/util/compat.py", line 200, 
in raise_from_cause
reraise(type(exception), exception, tb=exc_tb)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1139, 
in _execute_context
context)
  File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 
450, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) Cannot add a NOT 
NULL column with default value NULL

[Yahoo-eng-team] [Bug 1577727] Re: nova flavor-create raises 500 error if long value passed to flavor properties

2016-05-03 Thread Pushkar Umaranikar

Can you please reply with why you are using long value? Attributes of nova 
flavor-create command including uuid, amount of ram, vcpus etc. should be 
positive integers. From the command in the bug description, it seems like you 
are passing long value for ram. It expects an integer value. Hence, above is an 
expected error. 
kindly refer, http://docs.openstack.org/admin-guide/cli_manage_flavors.html


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

** Tags added: api

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

Title:
  nova flavor-create raises 500 error if long value passed to flavor
  properties

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  If long value is provided for properties other than name and ID then
  500 error is raised.

  Command:
  nova flavor-create new_flavor 35 234276234512334234 200 2

  n-api LOG:

  2016-05-03 10:44:46.744 ERROR nova.api.openstack.extensions 
[req-cadc48da-abb0-4dfb-abb8-c18855e45d30 admin admin] Unexpected exception in 
API method
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions Traceback (most 
recent call last):
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
f(*args, **kwargs)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/compute/flavor_manage.py", line 81, in 
_create
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 
is_public=is_public)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/compute/flavors.py", line 152, in create
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions db.MAX_INT)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/utils.py", line 1030, in validate_integer
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 'max_value': 
max_value})
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions InvalidInput: 
Invalid input received: ram must be <= 2147483647
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1577727/+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 1226342] Re: nova delete when a baremetal node is not responding to power management leaves the node orphaned

2016-05-03 Thread Derek Higgins

tripleo has move to ironic
Closing this bug, please feel free to reopen it if you disagree.

** Changed in: tripleo
   Status: Triaged => 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/1226342

Title:
  nova delete when a baremetal node is not responding to power
  management leaves the node orphaned

Status in OpenStack Compute (nova):
  Won't Fix
Status in tripleo:
  Fix Released

Bug description:
  If you nova delete an instance on baremetal and the baremetal power
  manager fails for some reason, you end up with a stale instance_uuid
  in the bm_nodes table. This is unrecoverable via the API - db surgery
  is needed.

  To reproduce, configure a bad power manager, nova boot something on
  bm, then nova delete, and check the DB.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1226342/+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 1577820] [NEW] key import in "launch instance" dialog not useable

2016-05-03 Thread Hendrik Frese

Public bug reported:

If you import a key in the "launch instance" dialog it will be imported, but as 
long as the same dialog is open it will have a  name and  content.
Starting a instance with it in this dialog will fail.
Aborting the dialog and starting a new one will let you use it normally.

Steps to reproduce:
1. Click on "launch instance"
2. Fill out every needed tab
3. Go to tab "key pair" and click on "import key pair"
4. Fill out name and paste a public key
5. Start instance

Expected result:
A new public key has been deposited and the new instance is started with it

Observed result:
"Error: Unable to create server"

** Affects: horizon
 Importance: Undecided
 Status: New

** Description changed:

- If you import a key in the "launch instance" dialog it will be imported, but
- as long as the same dialog is open it will have a  name and  
content.
+ If you import a key in the "launch instance" dialog it will be imported, but 
as long as the same dialog is open it will have a  name and  
content.
  Starting a instance with it in this dialog will fail.
  Aborting the dialog and starting a new one will let you use it normally.
  
  Steps to reproduce:
  1. Click on "launch instance"
  2. Fill out every needed tab
  3. Go to tab "key pair" and click on "import key pair"
  4. Fill out name and paste a public key
  5. Start instance
  
  Expected result:
  A new public key has been deposited and the new instance is started with it
  
  Observed result:
  "Error: Unable to create server"

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

Title:
  key import in "launch instance" dialog not useable

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  If you import a key in the "launch instance" dialog it will be imported, but 
as long as the same dialog is open it will have a  name and  
content.
  Starting a instance with it in this dialog will fail.
  Aborting the dialog and starting a new one will let you use it normally.

  Steps to reproduce:
  1. Click on "launch instance"
  2. Fill out every needed tab
  3. Go to tab "key pair" and click on "import key pair"
  4. Fill out name and paste a public key
  5. Start instance

  Expected result:
  A new public key has been deposited and the new instance is started with it

  Observed result:
  "Error: Unable to create server"

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1577820/+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 1577821] [NEW] User cannot set arbitary IDs for images

2016-05-03 Thread Asad

Public bug reported:

The glance command line enables user to supply ID for the image
while creating it using the`glance image-create` command.

However, the backend imposes that the ID of an image be a UUID.

There is no meaning of letting user supply ID as parameter, if the ID
needs to be a UUID.
User should be able to set custom ID for images as per need.

Also, the regular expression for the image ID is hard coded in the
backend. It will be nice if it is configurable in `schema-image.json`

** Affects: glance
 Importance: Undecided
 Status: New

** Description changed:

- The glance command line enables user to supply ID to the image
- while creating the using the`glance image-create` command.
+ The glance command line enables user to supply ID for the image
+ while creating it using the`glance image-create` command.
  
  However, the backend imposes that the ID of an image be a UUID.
  
- There no meaning of letting user supply ID as parameter, if the ID
+ There is no meaning of letting user supply ID as parameter, if the ID
  needs to be a UUID.
  User should be able to set custom ID for images as per need.
  
  Also, the regular expression for the image ID is hard coded in the
  backend. It will be nice if it is configurable in `schema-image.json`

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

Title:
  User cannot set arbitary IDs for images

Status in Glance:
  New

Bug description:
  The glance command line enables user to supply ID for the image
  while creating it using the`glance image-create` command.

  However, the backend imposes that the ID of an image be a UUID.

  There is no meaning of letting user supply ID as parameter, if the ID
  needs to be a UUID.
  User should be able to set custom ID for images as per need.

  Also, the regular expression for the image ID is hard coded in the
  backend. It will be nice if it is configurable in `schema-image.json`

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1577821/+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 1577804] [NEW] /v3/users?name= bypasses user_filter for LDAP

2016-05-03 Thread Matthew Edmonds

Public bug reported:

using the LDAP driver with user_filter, a GET /v3/users?name=
returns users that do not match the filter.

e.g.:

user_filter = (|(uid=arc1_admin)(uid=arc1_stgmgr))

# openstack user list
++-+
| ID | Name|
++-+
| 91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e | arc1_admin  |
| 42 | |
| 8c1beab95fc4c2b009383827f1ea1ec2880fa6eb5bbe42aebd43aab21ad685 | arc1_stgmgr |
| b2 | |
++-+


# openstack user show arc1_dep
+---+--+
| Field | Value|
+---+--+
| domain_id | default  |
| id| 631bbab78e33e554bc6c7fd53071c6e046fd37680b1b154261bd6183b123e8b0 |
| name  | arc1_dep |
+---+--+

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  /v3/users?name= bypasses user_filter for LDAP

Status in OpenStack Identity (keystone):
  New

Bug description:
  using the LDAP driver with user_filter, a GET /v3/users?name=
  returns users that do not match the filter.

  e.g.:

  user_filter = (|(uid=arc1_admin)(uid=arc1_stgmgr))

  # openstack user list
  
++-+
  | ID | Name   
 |
  
++-+
  | 91476076d6686143dff68d08e87358a29daf0725c549008f9c0852d2c7ab8e | arc1_admin 
 |
  | 42 |
 |
  | 8c1beab95fc4c2b009383827f1ea1ec2880fa6eb5bbe42aebd43aab21ad685 | 
arc1_stgmgr |
  | b2 |
 |
  
++-+

  
  # openstack user show arc1_dep
  
+---+--+
  | Field | Value   
 |
  
+---+--+
  | domain_id | default 
 |
  | id| 
631bbab78e33e554bc6c7fd53071c6e046fd37680b1b154261bd6183b123e8b0 |
  | name  | arc1_dep
 |
  
+---+--+

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

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

[Yahoo-eng-team] [Bug 1553815] Re: host keys never restored following metadata api outage

2016-05-03 Thread Louis Bouchard

** Also affects: cloud-init (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Wily)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu Xenial)
   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/1553815

Title:
  host keys never restored following metadata api outage

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  New
Status in cloud-init source package in Trusty:
  New
Status in cloud-init source package in Wily:
  New
Status in cloud-init source package in Xenial:
  Fix Released

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

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

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

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

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553815/+subscriptions

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

[Yahoo-eng-team] [Bug 1553815] Re: host keys never restored following metadata api outage

2016-05-03 Thread Felipe Reyes

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => 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/1553815

Title:
  host keys never restored following metadata api outage

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  New
Status in cloud-init source package in Trusty:
  New
Status in cloud-init source package in Wily:
  New
Status in cloud-init source package in Xenial:
  Fix Released

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

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

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

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

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553815/+subscriptions

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

[Yahoo-eng-team] [Bug 1577630] Re: ERROR neutron_lbaas.agent.agent_manager - HaproxyNSDriver

2016-05-03 Thread Igor Meneguitte Ávila

Hi Brandon Logan,

I use Openstack with two nodes (controller and compute1).
http://docs.openstack.org/liberty/install-guide-ubuntu/overview.html

I executed the follows commands:
http://docs.openstack.org/liberty/networking-guide/adv-config-lbaas.html

$ neutron lbaas-loadbalancer-create --name test-lb public 
$ neutron lbaas-loadbalancer-list
+--+-+-+-+--+
| id   | name| vip_address | 
provisioning_status | provider |
+--+-+-+-+--+
| 24f50e79-53b6-4ee6-8da1-2a8f1233a857 | test-lb | 20.0.0.118  | ACTIVE 
 | haproxy  |
+--+-+-+-+--+

$ neutron lbaas-loadbalancer-show test-lb
+-+--+
| Field   | Value|
+-+--+
| admin_state_up  | True |
| description |  |
| id  | 24f50e79-53b6-4ee6-8da1-2a8f1233a857 |
| listeners   |  |
| name| test-lb  |
| operating_status| ONLINE   |
| provider| haproxy  |
| provisioning_status | ACTIVE   |
| tenant_id   | 60d7922e29e44dc1ac62df3fe7ba3841 |
| vip_address | 20.0.0.118   |
| vip_port_id | 2ef09104-397b-4f84-8977-3c3318e4d393 |
| vip_subnet_id   | ee4a850d-57f7-4389-936e-ea7cd2fc4cfb |
+-+--+
$ neutron port-update \
>   --security-group lbaas 2ef09104-397b-4f84-8977-3c3318e4d393
Updated port: 2ef09104-397b-4f84-8977-3c3318e4d393

ping -c 4 20.0.0.118
PING 20.0.0.118 (20.0.0.118) 56(84) bytes of data.
>From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
>From 10.0.0.1 icmp_seq=2 Destination Host Unreachable
>From 10.0.0.1 icmp_seq=3 Destination Host Unreachable
>From 10.0.0.1 icmp_seq=4 Destination Host Unreachable

neutron lbaas-listener-create --name test-lb-http --loadbalancer test-lb 
--protocol HTTP --protocol-port 80
Created a new listener:
+---++
| Field | Value  |
+---++
| admin_state_up| True   |
| connection_limit  | -1 |
| default_pool_id   ||
| default_tls_container_ref ||
| description   ||
| id| e4d4730a-cd97-4d42-9d0a-a3fc55bbf710   |
| loadbalancers | {"id": "24f50e79-53b6-4ee6-8da1-2a8f1233a857"} |
| name  | test-lb-http   |
| protocol  | HTTP   |
| protocol_port | 80 |
| sni_container_refs||
| tenant_id | 60d7922e29e44dc1ac62df3fe7ba3841   |
+---++

# tail -f /var/log/neutron/neutron-lbaasv2-agent.log
2016-05-02 09:25:47.745 18394 INFO neutron.common.config [-] Logging enabled!
2016-05-02 09:25:47.745 18394 INFO neutron.common.config [-] 
/usr/bin/neutron-lbaasv2-agent version 7.0.3
2016-05-02 09:25:47.812 18394 INFO oslo.messaging._drivers.impl_rabbit [-] 
Connecting to AMQP server on controller:5672
2016-05-02 09:25:47.827 18394 INFO oslo.messaging._drivers.impl_rabbit [-] 
Connecting to AMQP server on controller:5672
2016-05-02 09:25:47.843 18394 INFO oslo.messaging._drivers.impl_rabbit [-] 
Connected to AMQP server on controller:5672
2016-05-02 09:25:47.845 18394 INFO oslo.messaging._drivers.impl_rabbit [-] 
Connected to AMQP server on controller:5672
2016-05-02 09:25:47.900 18394 INFO oslo.messaging._drivers.impl_rabbit [-] 
Connecting to AMQP server on controller:5672
2016-05-02 09:25:47.920 18394 INFO oslo.messaging._drivers.impl_rabbit [-] 
Connected to AMQP server on controller:5672
2016-05-02 09:31:37.951 18394 WARNING 
neutron_lbaas.drivers.haproxy.namespace_driver [-] Stats socket not found for 
loadbalancer 24f50e79-53b6-4ee6-8da1-2a8f1233a857
2016-05-02 09:31:47.951 18394 WARNING 
neutron_lbaas.drivers.haproxy.namespace_driver [-] Stats socket not found for 
loadbalancer

[Yahoo-eng-team] [Bug 1553815] Re: host keys never restored following metadata api outage

2016-05-03 Thread Felipe Reyes

For the record, this was fixed in revno 1188 (upstream)[0], available
since cloud-init version 0.7.7~bzr1192-0ubuntu1[1]

[0] http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1188
[1] 
http://bazaar.launchpad.net/~smoser/ubuntu/xenial/cloud-init/pkg/revision/452

** Also affects: cloud-init (Ubuntu)
   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/1553815

Title:
  host keys never restored following metadata api outage

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  New
Status in cloud-init source package in Trusty:
  New
Status in cloud-init source package in Wily:
  New
Status in cloud-init source package in Xenial:
  Fix Released

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

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

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

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

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

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

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

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

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

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

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1553815/+subscriptions

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

[Yahoo-eng-team] [Bug 1572495] Re: Nova API fails to start if "ec2" is specified in enabled_apis

Reviewed:  https://review.openstack.org/308264
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=533bd8175968a1bc9ac068ae2b23a62d0e07ea99
Submitter: Jenkins
Branch:master

commit 533bd8175968a1bc9ac068ae2b23a62d0e07ea99
Author: Sean Dague 
Date:   Wed Apr 20 06:53:18 2016 -0400

Prevent nova-api from dying if enabled_apis is wrong

This prevents nova-api from dying if there are values in
``enabled_apis`` which don't actually exist.

Closes-Bug: #1572495

Change-Id: Id9a6f5e38b017f4687eb245fd238104379d437d6


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

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

Title:
  Nova API fails to start if "ec2" is specified in enabled_apis

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) mitaka series:
  Confirmed

Bug description:
  As reported by Kevin Foxx yesterday, if "ec2" is listed in
  enabled_apis in Mitaka and beyond Nova will refuse to start because we
  removed it.

  We assumed the change in defaults was good enough for people to move
  forward, but didn't realize that many of the install tools (packstack
  for sure) hardcoded this value into the config instead of sticking
  with the defaults.

  While we've added a new upgrade note on this, we could also actually
  catch the error and not crash people.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1572495/+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 1577791] [NEW] [RFE] Openflow pipeline modeling and API for OVS extensions

2016-05-03 Thread Miguel Angel Ajo

Public bug reported:

Problem statement


OpenFlow can be really powerful for programming the dataplane, but when
several features are hooked up into the same virtual switch they need
knowledge of each other implementation (entry table, next table, used
registers, conventions, etc).

Solution
~~~

Defining a model & extension api for features to describe their
"OpenFlow functions", and their entry point in the processing pipeline
(ingress prefiltering, ingress postfiltering, egress prefiltering,
egress postfiltering), as well as the ability to allocate registers.

On a high level, each extension (and the Openvwitch firewall
implementation) would expose a model of it's low level functions.

openvswitch_firewall would expose: ingress_filter & egress_filter.

tapas-a-service (as an example) could expose: taas_{ingress,
egress}_{prefilter, postfilter}

Every extension would declare a set of "OFFunctions" which would be
built of a number of "OFTables". Once all extensions are loaded, and
order resolved, every function would get it's "next hop", and it's table
numbers, dynamically.

We could have a predefine OFFunction priority table somewhere in neutron_lib, 
with spaces in between priorities for experimentation,
with the idea that extensions may request hook points into the pipeline,
and those hook points may be discussed upstream to allow interoperability.

If necessary, a configuration for admin defined ordering of OFFunctions
could be provided in a second step.

Diagram: http://paste.openstack.org/show/495967/

input tagging / output_stage / and ingress deflector would be shared
common logic.

** Affects: neutron
 Importance: Undecided
 Status: New

** Description changed:

  Problem statement
  
  
  OpenFlow can be really powerful for programming the dataplane, but when
  several features are hooked up into the same virtual switch they need
  knowledge of each other implementation (entry table, next table, used
  registers, conventions, etc).
  
  Solution
  ~~~
  
  Defining a model & extension api for features to describe their
  "OpenFlow functions", and their entry point in the processing pipeline
  (ingress prefiltering, ingress postfiltering, egress prefiltering,
  egress postfiltering), as well as the ability to allocate registers.
  
- 
- On a high level, each extension (and the Openvwitch firewall implementation) 
would expose a model of it's low level functions.
+ On a high level, each extension (and the Openvwitch firewall
+ implementation) would expose a model of it's low level functions.
  
  openvswitch_firewall would expose: ingress_filter & egress_filter.
  
  tapas-a-service (as an example) could expose: taas_{ingress,
  egress}_{prefilter, postfilter}
  
  Every extension would declare a set of "OFFunctions" which would be
- buillt of a number of "OFTables". Once all extensions are loaded, and
+ built of a number of "OFTables". Once all extensions are loaded, and
  order resolved, every function would get it's "next hop", and it's table
  numbers, dynamically.
  
+ Diagram: http://paste.openstack.org/show/495967/
+ 
  input tagging / output_stage / and ingress deflector would be shared
  common logic.
- 
- 
- +--+  +-+
- |br int|  |   br xxx|
- +-^+  +^+
-+---+  ||   +---+
-| TAP a <+ ||  +>TAP b  |
-+--++| ||  |+---+
-   | | ||  |
-  0+---v-+ 255+--+-++--+--+
-   | input tagging   |  +  output_stage   |
-   +---+-+  +^+
-   | |
-   +---v-+  +++
-   | |  | |
-   +---+-+  +^+
-   | |
-   +---v-+  +++
-   | egress filter   |  |  ingress filter |
-   +---+-+  +^+
-   | |
-   +---v-+  +++
-   | |  ^ |
-   +---+-+ /+^+
-   |  /  |
- 127---v-+ 0+++
-   |ingress deflector|  |  input tagging  |
-   +--+--+  +^^---+
-  |  ||
-  255+v--+   ||
-   +  output_stage   +--+ |
-   +---+-+   |  | |
-   | |  | |
-  +v++ +v-+-+
-  | br int  |  |br xxx  |
-  +-+  ++

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

Title:
  [RFE] Openflow pipeline modeling and API for OVS extensions

Status in neutron:
  New

Bug description:

[Yahoo-eng-team] [Bug 1352193] Re: The nova API service can't hand image metadata properly when metadata key contains uppercase letter

The glance v1 API which the Nova images proxy is based on put metadata
via headers. That means they are case insensitive. Nova will continue to
do this regardless of backend, which means when talking to a v2 server,
your metadata might be wrong.

The Nova image proxy should not be used, and Glance should be interacted
with directly.

** Changed in: nova
   Status: Confirmed => Won't Fix

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

Title:
  The nova API service can't hand image metadata properly when metadata
  key contains uppercase letter

Status in Glance:
  In Progress
Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  OS: centos 6.5 64bit
  openstack release: icehouse

  Steps to reproduce:
  1. Call the image metadata API of nova using the following command:
   curl -X 'POST' -v http://IP:PORT/v2/${tenant_id}/images/${image_id}/metadata 
-H "X-Auth-Token: $token" -H 'Content-type: application/json' -d 
'{"metadata":{"Key1":"Value1"}}' | python -mjson.tool
  2. Execute the above command again:
curl -X 'POST' -v 
http://IP:PORT/v2/${tenant_id}/images/${image_id}/metadata -H "X-Auth-Token: 
$token" -H 'Content-type: application/json' -d '{"metadata":{"Key1":"Value1"}}' 
| python -mjson.tool

  Expected result:
  In step1, the json response should be:
{"metadata":{"Key1":"Value1"}}
  In setp2, the json response should be:
   {"metadata":{"Key1":"Value1"}}

  Observed result: 
  In step1, the json response is:
{"metadata":{"key1":"Value1"}}
  In setp2, the json response is:
   {"metadata":{"key1":"Value1,Value1"}}

  Besides, we can observer that each image metadata key in table
  image_properties of glance DB is converted to lowercase even if the
  key user inputted contains uppercase letter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1352193/+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 1577311] Re: OperationalError: (pymysql.err.OperationalError)

You have only specified the api_database, not the main database. Both
are needed.

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

** Tags added: cells

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

Title:
  OperationalError: (pymysql.err.OperationalError)

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  This error happens in Mitaka on ubuntu 14.04
  I have configured nova on separate nodes
  1) 192.168.1.177 (Glance)
  2)192.168.1.176(Keystone, and  mysql  for both glance, keystone, nova).
  3)192.168.1.181(nova controller and nova compute).

  Am using a python script nova to connect and everything works fine, I can 
list flavors, i can list images, but when i try to create
  a server with nova.servers.create(name="TestServer", 
image=images_returned[0], flavors=flavors_avail[0])

  It looks like the api does not connect to the database server, rather
  than connect to the database server "192.168.1.176" it connects to
  itself that is 192.168.1.181, I  have not configured the mysql to run
  on the nova controler rather the mysql database server is running on
  a different node as described on the onset.

  Worse yet it that it connects to the real database when I list images and 
other flavors, but when i try to create the server it brings these areas 
   ERROR nova.api.openstack.extensions OperationalError: 
(pymysql.err.OperationalError) (1045, u"Access denied for user 
'nova'@'192.168.1.181' (using password: YES)")

  And that is not the database i configured it to use i configured it to
  use a different database 192.168.1.176

  Here are my configs.

  
  [DEFAULT]
  dhcpbridge_flagfile=/etc/nova/nova.conf
  dhcpbridge=/usr/bin/nova-dhcpbridge
  log-dir=/var/log/nova
  state_path=/var/lib/nova
  lock_path=/var/lock/nova
  force_dhcp_release=True
  libvirt_use_virtio_for_bridges=True
  verbose=True
  ec2_private_dns_show_ip=True
  api_paste_config=/etc/nova/api-paste.ini
  enabled_apis=ec2,osapi_compute,metadata

  # Libvirt and Virtualization
  connection_type=libvirt
  libvirt_type=qemu

  
  # Database
  #connection = mysql://nova:nova/@192.168.1.176/nova

  # Messaging
  rabbit_host=192.168.1.181

  # EC2 API Flags
  ec2_host=192.168.1.181
  ec2_dmz_host=192.168.1.181
  ec2_private_dns_show_ip=True

  
  # Networking
  public_interface=eth0
  auto_assign_floating_ip=True

  # Image
  image_service=nova.image.Glance.GlanceIageService
  glance_api_servers=192.168.1.177:9292

  # Scheduler
  scheduler_default_filters=AllHostsFilter

  # Object storage
  iscsi_helper=tgtadm

  # Auth
  keystone_ec2_url=http://192.168.1.176:6000/v3/ec2tokens
  auth_stragety=keystone

  
  [glance]
  api_servers=192.168.1.177:9292
  host=192.168.1.177
  port=9292
  protocol=http

  [libvirt]
  virt_type=qemu

  
  [api_database]

  #
  # From nova
  #
  # The SQLAlchemy connection string to use to connect to the Nova API database.
  # (string value)
  connection = mysql://nova:nova/@192.168.1.176/nova

  # If True, SQLite uses synchronous mode. (boolean value)
  #sqlite_synchronous = true

  # The SQLAlchemy connection string to use to connect to the slave database.
  # (string value)
  #slave_connection = 

  # The SQL mode to be used for MySQL sessions. This option, including the
  # default, overrides any server-set SQL mode. To use whatever SQL mode is set
  # by the server configuration, set this to no value. Example: mysql_sql_mode=
  # (string value)
  mysql_sql_mode = TRADITIONAL

  # Timeout before idle SQL connections are reaped. (integer value)
  #idle_timeout = 3600

  # Maximum number of SQL connections to keep open in a pool. (integer value)
  #max_pool_size = 

  # Maximum number of database connection retries during startup. Set to -1 to
  # specify an infinite retry count. (integer value)
  #max_retries = 10

  # Interval between retries of opening a SQL connection. (integer value)
  #retry_interval = 10

  # If set, use this value for max_overflow with SQLAlchemy. (integer
  value)

  # Verbosity of SQL debugging information: 0=None, 100=Everything. (integer
  # value)
  connection_debug = 100

  # Add Python stack traces to SQL as comment strings. (boolean value)
  connection_trace = true

  # If set, use this value for pool_timeout with SQLAlchemy. (integer value)
  #pool_timeout = 

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1577311/+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 1288230] Re: A project shouldn't be deleted when there are instances running

Removing Nova from this bug. As has been expressed this is true of
anything in OpenStack.

It's fine for Horizon to warn/block project deletion on these cases. At
some level keystone is going to let you do the delete. The theory from
Tokyo was that OSC should have a cleanup project plugin

** Changed in: nova
   Status: Confirmed => Won't Fix

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

Title:
  A project shouldn't be deleted when there are instances running

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  Description of problem:
  currently, a project that has an instance (or instances) can be deleted 
without even a warning message in the Horizon by a user with an administrative 
permissions. An active project (meaning a project that has instances running) 
should have the protection from deletion. If the administrator would like to 
delete it he should delete the instances first. 

  Version-Release number of selected component (if applicable):
  openstack-nova-cert-2013.2.2-2.el6ost.noarch
  python-novaclient-2.15.0-2.el6ost.noarch
  openstack-nova-common-2013.2.2-2.el6ost.noarch
  openstack-nova-api-2013.2.2-2.el6ost.noarch
  openstack-nova-compute-2013.2.2-2.el6ost.noarch
  openstack-nova-conductor-2013.2.2-2.el6ost.noarch
  openstack-nova-novncproxy-2013.2.2-2.el6ost.noarch
  openstack-nova-scheduler-2013.2.2-2.el6ost.noarch
  python-nova-2013.2.2-2.el6ost.noarch
  openstack-nova-console-2013.2.2-2.el6ost.noarch
  openstack-nova-network-2013.2.2-2.el6ost.noarch

  How reproducible:
  100%

  Steps to Reproduce:
  1. Create an new project.
  2. Launch one (or more) instances. 
  3. Try to delete the project with the admin.

  Actual results:
  The instances are still running, but they are accessible only through the 
admin -> intances tab.

  Expected results:
  The administrator shouldn't be able to delete the project as long as there 
are instances running.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1288230/+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 1491949] Re: gate-tempest-dsvm-large-ops fails to deallocate instance network due to rpc timeout

This job has been deleted

** Changed in: nova
   Status: Confirmed => Won't Fix

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

Title:
  gate-tempest-dsvm-large-ops fails to deallocate instance network due
  to rpc timeout

Status in devstack:
  Fix Released
Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  http://logs.openstack.org/96/219696/4/check/gate-tempest-dsvm-large-
  ops/158f061/logs/screen-n-cpu-1.txt.gz?level=TRACE

  2015-09-03 15:11:10.090 ERROR nova.compute.manager 
[req-ae96c425-a199-472f-a0db-e1b48147bb4c 
tempest-TestLargeOpsScenario-1690771764 
tempest-TestLargeOpsScenario-1474206998] [instance: 
195361d7-95c3-4740-825b-1acab707969e] Failed to deallocate network for instance.
  2015-09-03 15:11:11.051 ERROR nova.compute.manager 
[req-ae96c425-a199-472f-a0db-e1b48147bb4c 
tempest-TestLargeOpsScenario-1690771764 
tempest-TestLargeOpsScenario-1474206998] [instance: 
195361d7-95c3-4740-825b-1acab707969e] Setting instance vm_state to ERROR
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] Traceback (most recent call last):
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 2396, in 
do_terminate_instance
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] self._delete_instance(context, 
instance, bdms, quotas)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/hooks.py", line 149, in inner
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] rv = f(*args, **kwargs)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 2375, in _delete_instance
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] quotas.rollback()
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 195, in 
__exit__
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] six.reraise(self.type_, self.value, 
self.tb)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 2338, in _delete_instance
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] self._shutdown_instance(context, 
instance, bdms)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 2265, in _shutdown_instance
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] self._try_deallocate_network(context, 
instance, requested_networks)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 2194, in 
_try_deallocate_network
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] 
self._set_instance_obj_error_state(context, instance)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 195, in 
__exit__
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] six.reraise(self.type_, self.value, 
self.tb)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 2189, in 
_try_deallocate_network
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] self._deallocate_network(context, 
instance, requested_networks)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 1812, in _deallocate_network
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e] context, instance, 
requested_networks=requested_networks)
  2015-09-03 15:11:11.051 22635 ERROR nova.compute.manager [instance: 
195361d7-95c3-4740-825b-1acab707969e]   File

[Yahoo-eng-team] [Bug 1577758] [NEW] fix wrong key name in test code

2016-05-03 Thread Peng Li

Public bug reported:

nova/tests/unit/virt/libvirt/test_driver.py, Line 12611
root_bdm = {'source_type': 'image',
'detination_type': 'volume',
'image_id': 'fake_id'}
'detination_type' should be 'destination_type', it will run fail when testing.

** Affects: nova
 Importance: Undecided
 Assignee: Peng Li (flyd1005)
 Status: New


** Tags: compute low-hanging-fruit

** Changed in: nova
 Assignee: (unassigned) => Peng Li (flyd1005)

** Tags added: compute low-hanging-fruit

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

Title:
  fix wrong key name in test code

Status in OpenStack Compute (nova):
  New

Bug description:
  nova/tests/unit/virt/libvirt/test_driver.py, Line 12611
root_bdm = {'source_type': 'image',
  'detination_type': 'volume',
  'image_id': 'fake_id'}
  'detination_type' should be 'destination_type', it will run fail when testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1577758/+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 1577753] [NEW] Cloud-init fails of stage init

2016-05-03 Thread krath

Public bug reported:

Cloud-init 0.77 on Ubuntu 16.04 
seems not to be able to connect to the OpenStack Metadata service and fails, 
although the Metadata service is available itself, see log here:

root@ubuntu:/etc/network# cloud-init  --debug init
2016-05-03 12:25:04,855 - handlers.py[DEBUG]: start: init-network: searching 
for network datasources
2016-05-03 12:25:04,855 - util.py[DEBUG]: Reading from /proc/uptime 
(quiet=False)
2016-05-03 12:25:04,855 - util.py[DEBUG]: Read 16 bytes from /proc/uptime
2016-05-03 12:25:04,856 - util.py[DEBUG]: Reading from 
/var/lib/cloud/data/status.json (quiet=False)
2016-05-03 12:25:04,856 - util.py[DEBUG]: Read 548 bytes from 
/var/lib/cloud/data/status.json
2016-05-03 12:25:04,857 - util.py[DEBUG]: Creating symbolic link from 
'/run/cloud-init/status.json' => '../../var/lib/cloud/data/status.json'
2016-05-03 12:25:04,858 - util.py[DEBUG]: Attempting to remove 
/run/cloud-init/status.json
2016-05-03 12:25:04,858 - util.py[DEBUG]: Running command 
['systemd-detect-virt', '--quiet', '--container'] with allowed return codes [0] 
(shell=False, capture=True)
2016-05-03 12:25:04,861 - util.py[DEBUG]: Running command 
['running-in-container'] with allowed return codes [0] (shell=False, 
capture=True)
2016-05-03 12:25:04,862 - util.py[DEBUG]: Running command ['lxc-is-container'] 
with allowed return codes [0] (shell=False, capture=True)
2016-05-03 12:25:04,864 - util.py[DEBUG]: Reading from /proc/1/environ 
(quiet=False)
2016-05-03 12:25:04,864 - util.py[DEBUG]: Read 110 bytes from /proc/1/environ
2016-05-03 12:25:04,864 - util.py[DEBUG]: Reading from /proc/self/status 
(quiet=False)
2016-05-03 12:25:04,865 - util.py[DEBUG]: Read 896 bytes from /proc/self/status
2016-05-03 12:25:04,865 - util.py[DEBUG]: Reading from /proc/cmdline 
(quiet=False)
2016-05-03 12:25:04,865 - util.py[DEBUG]: Read 64 bytes from /proc/cmdline
2016-05-03 12:25:04,866 - util.py[DEBUG]: Reading from /proc/uptime 
(quiet=False)
2016-05-03 12:25:04,866 - util.py[DEBUG]: Read 16 bytes from /proc/uptime
2016-05-03 12:25:04,866 - templater.py[WARNING]: Cheetah not available as the 
default renderer for unknown template, reverting to the basic renderer.
2016-05-03 12:25:04,867 - util.py[DEBUG]: Reading from /etc/cloud/cloud.cfg 
(quiet=False)
2016-05-03 12:25:04,867 - util.py[DEBUG]: Read 3011 bytes from 
/etc/cloud/cloud.cfg
2016-05-03 12:25:04,867 - util.py[DEBUG]: Attempting to load yaml from string 
of length 3011 with allowed root types (,)
2016-05-03 12:25:04,887 - util.py[DEBUG]: Reading from 
/etc/cloud/cloud.cfg.d/90_dpkg.cfg (quiet=False)
2016-05-03 12:25:04,887 - util.py[DEBUG]: Read 197 bytes from 
/etc/cloud/cloud.cfg.d/90_dpkg.cfg
2016-05-03 12:25:04,887 - util.py[DEBUG]: Attempting to load yaml from string 
of length 197 with allowed root types (,)
2016-05-03 12:25:04,889 - util.py[DEBUG]: Reading from 
/etc/cloud/cloud.cfg.d/05_logging.cfg (quiet=False)
2016-05-03 12:25:04,890 - util.py[DEBUG]: Read 1910 bytes from 
/etc/cloud/cloud.cfg.d/05_logging.cfg
2016-05-03 12:25:04,890 - util.py[DEBUG]: Attempting to load yaml from string 
of length 1910 with allowed root types (,)
2016-05-03 12:25:04,897 - cloud-init[DEBUG]: Closing stdin
2016-05-03 12:25:04,898 - util.py[DEBUG]: Redirecting <_io.TextIOWrapper 
name='' mode='w' encoding='UTF-8'> to | tee -a 
/var/log/cloud-init-output.log
2016-05-03 12:25:04,899 - util.py[DEBUG]: Redirecting <_io.TextIOWrapper 
name='' mode='w' encoding='UTF-8'> to | tee -a 
/var/log/cloud-init-output.log
2016-05-03 12:25:04,900 - cloud-init[DEBUG]: Logging being reset, this logger 
may no longer be active shortly
Cloud-init v. 0.7.7 running 'init' at Tue, 03 May 2016 12:25:04 +. Up 
4339.24 seconds.
ci-info: ++Net device 
info+++
ci-info: 
++--+--+---+---+---+
ci-info: | Device |  Up  |   Address|  Mask | Scope 
| Hw-Address|
ci-info: 
++--+--+---+---+---+
ci-info: |   lo   | True |  127.0.0.1   |   255.0.0.0   |   .   
| . |
ci-info: |   lo   | True |   ::1/128|   .   |  host 
| . |
ci-info: | ens32  | True | 192.168.0.15 | 255.255.255.0 |   .   
| fa:16:3e:40:92:3f |
ci-info: | ens32  | True | fe80::f816:3eff:fe40:923f/64 |   .   |  link 
| fa:16:3e:40:92:3f |
ci-info: 
++--+--+---+---+---+
ci-info: +Route IPv4 
info+
ci-info: 
+---+-+-+---+---+---+
ci-info: | Route | Destination |   Gateway   |Genmask| Interface | 
Flags |
ci-info: 
+---+-+-+---+---+---+
ci-info: |   0   |

[Yahoo-eng-team] [Bug 1577370] Re: Duplicate lines in /etc/nova/policy.json

2016-05-03 Thread Matt Kassawara

Bug belongs to the nova project.

** Project changed: openstack-manuals => nova

** Changed in: nova
 Assignee: monika (monikaparkar25) => (unassigned)

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

Title:
  Duplicate lines in /etc/nova/policy.json

Status in OpenStack Compute (nova):
  Incomplete

Bug description:
  The default /etc/nova/policy.json released with Liberty contains two times 
the declaration for:
  "compute:delete": "",
  "compute:soft_delete": "",
  "compute:force_delete": "",

  I don't known it can impact the policy, but it may be better to raise
  an error when a rule is declared more than one time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1577370/+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 1569081] Re: Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi

2016-05-03 Thread Martin Pavlásek

** Project changed: openstack-community => horizon

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

Title:
  Truncated or oversized response headers received from daemon process
  'horizon': /usr/share/openstack-
  dashboard/openstack_dashboard/wsgi/django.wsgi

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  trying to install openstack mikata  openstack-dashboard newly
  installed ubuntu 16.04  kernel 4.4.0-18 keep getiing this error

  
   apache log

  Truncated or oversized response headers received from daemon process
  'horizon': /usr/share/openstack-
  dashboard/openstack_dashboard/wsgi/django.wsgi

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1569081/+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 1577747] [NEW] Cloud- init doesn't configure network interfaces in Ubuntu 16.04

2016-05-03 Thread krath

Public bug reported:

I'm running vmbuilder 0.12.4 on an Ubuntu 16.04 server to create an Ubuntu 
16.04 cloud image.
cloud-init 0.77 is being added to run the cloud image in OpenStack.

Upon starting the VM in OpenStack,
cloud-init fails because the network interface can't be established.
That seems to be related to discrepancy between 
/etc/network/interfaces 
and 
/etc/network/interfaces.d/50-cloud-init.cfg

--> in /etc/network/interfaces, the primary network interface is eth0,
whereby in cloud-init it is ens32

auto eth0
iface eth0 inet dhcp

--> changing eth0 to ens32  correctly establishes the network interface

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

Title:
  Cloud- init doesn't configure network interfaces in Ubuntu 16.04

Status in cloud-init:
  New

Bug description:
  I'm running vmbuilder 0.12.4 on an Ubuntu 16.04 server to create an Ubuntu 
16.04 cloud image.
  cloud-init 0.77 is being added to run the cloud image in OpenStack.

  Upon starting the VM in OpenStack,
  cloud-init fails because the network interface can't be established.
  That seems to be related to discrepancy between 
  /etc/network/interfaces 
  and 
  /etc/network/interfaces.d/50-cloud-init.cfg

  --> in /etc/network/interfaces, the primary network interface is eth0,
  whereby in cloud-init it is ens32

  auto eth0
  iface eth0 inet dhcp

  --> changing eth0 to ens32  correctly establishes the network
  interface

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1577747/+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 1517704] Re: Test still passes even with tests failure

Reviewed:  https://review.openstack.org/301862
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=037d1c0927b64848ea0934990ba6538d9d7a8133
Submitter: Jenkins
Branch:master

commit 037d1c0927b64848ea0934990ba6538d9d7a8133
Author: David Lyle 
Date:   Wed Mar 16 10:25:26 2016 -0600

removing httplib2 test dependency

Once upon a time, the python-*client libraries were primarily built to
use httplib2. They have subsequently shift to using requests and thus
urllib3. The horizon test helpers code was maintaining a reference to
httplib2 as it intercepted errant library calls that were not mocked.

httplib2 is not actively maintained and OpenStack is moving to remove it
as a dependency. See
http://lists.openstack.org/pipermail/openstack-dev/2016-March/089225.html
for more details.

This patch removed the httplib2 dependency. Upon removing the
dependency it exposed a missed update from httplib2 to urllib3. A
function that was intended to catch unmocked calls was only listening
for httplib2 connections. This patch updates that failsafe to work with
urllib3. Upon doing so, it pointed out many, many missing mocks and in
turn, many broken tests that appeared to work because of API call
failures. This patch adds the missing mocks and fixes the broken tests.

The new failsafe prints the stack trace when an outside connection is
attempted. Additionally, to fix the fact that a missed mock used to
allow tests to potentially pass, as documented by bug 1517704, a test
failure is now forced on tests where a missing mock is detected.

Closes-Bug: #1517704
Implements blueprint: remove-httplib2-dep
Change-Id: Iaabdf03966c14c82e0c58a3b1ab1a6755c05adcb


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

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

Title:
  Test still passes even with tests failure

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Tests seems still to pass even with test failures.

  There are two tests failure on the code, and test run still report it
  passes:

  https://bugs.launchpad.net/horizon/+bug/1517670
  https://bugs.launchpad.net/horizon/+bug/1517653

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1517704/+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 1569081] [NEW] Truncated or oversized response headers received from daemon process 'horizon': /usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi

You have been subscribed to a public bug:

trying to install openstack mikata  openstack-dashboard newly installed
ubuntu 16.04  kernel 4.4.0-18 keep getiing this error


 apache log

Truncated or oversized response headers received from daemon process
'horizon': /usr/share/openstack-
dashboard/openstack_dashboard/wsgi/django.wsgi

** Affects: horizon
 Importance: Undecided
 Status: Invalid


** Tags: horizon mikata
-- 
Truncated or oversized response headers received from daemon process 'horizon': 
/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi
https://bugs.launchpad.net/bugs/1569081
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).

-- 
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 1577370] [NEW] Duplicate lines in /etc/nova/policy.json

You have been subscribed to a public bug:

The default /etc/nova/policy.json released with Liberty contains two times the 
declaration for:
"compute:delete": "",
"compute:soft_delete": "",
"compute:force_delete": "",

I don't known it can impact the policy, but it may be better to raise an
error when a rule is declared more than one time.

** Affects: nova
 Importance: Undecided
 Assignee: monika (monikaparkar25)
 Status: Incomplete

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

-- 
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 1511982] Re: Unable to upgrade the DB from kilo to liberty with VPNaaS

2016-05-03 Thread Henry Gessau

*** This bug is a duplicate of bug 1550434 ***
https://bugs.launchpad.net/bugs/1550434

** This bug has been marked a duplicate of bug 1550434
   vpnaas alembic migration fails for upgrade liberty

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

Title:
  Unable to upgrade the DB from kilo to liberty with VPNaaS

Status in neutron:
  Expired

Bug description:
  i'm trying to upgrade neutron from Kilo to Liberty with VPNaaS enabled.
  While 

  neutron-db-manage --config-file /etc/neutron/neutron.conf  --config-
  file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade liberty

  I get this error.

  Traceback (most recent call last):
File "/usr/bin/neutron-db-manage", line 10, in 
  sys.exit(main())
File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
554, in main
  CONF.command.func(config, CONF.command.name)
File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
188, in do_upgrade
  run_sanity_checks(config, revision)
File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
541, in run_sanity_checks
  script_dir.run_env()
File "/usr/lib/python2.7/dist-packages/alembic/script/base.py", line 397, 
in run_env
  util.load_python_file(self.dir, 'env.py')
File "/usr/lib/python2.7/dist-packages/alembic/util/pyfiles.py", line 81, 
in load_python_file
  module = load_module_py(module_id, path)
File "/usr/lib/python2.7/dist-packages/alembic/util/compat.py", line 79, in 
load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/usr/lib/python2.7/dist-packages/neutron_vpnaas/db/migration/alembic_migrations/env.py",
 line 87, in 
  run_migrations_online()
File 
"/usr/lib/python2.7/dist-packages/neutron_vpnaas/db/migration/alembic_migrations/env.py",
 line 78, in run_migrations_online
  context.run_migrations()
File "", line 8, in run_migrations
File "/usr/lib/python2.7/dist-packages/alembic/runtime/environment.py", 
line 797, in run_migrations
  self.get_context().run_migrations(**kw)
File "/usr/lib/python2.7/dist-packages/alembic/runtime/migration.py", line 
303, in run_migrations
  for step in self._migrations_fn(heads, self):
File "/usr/lib/python2.7/dist-packages/neutron/db/migration/cli.py", line 
532, in check_sanity
  revision, rev, implicit_base=True):
File "/usr/lib/python2.7/dist-packages/alembic/script/revision.py", line 
664, in _iterate_revisions
  raise RangeNotAncestorError(lower, upper)
  alembic.script.revision.RangeNotAncestorError: Revision (u'2c82e782d734',) is 
not an ancestor of revision 24f28869838b

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1511982/+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 1577727] [NEW] nova flavor-create raises 500 error if long value passed to flavor properties

2016-05-03 Thread Dinesh Bhor

Public bug reported:

If long value is provided for properties other than name and ID then 500
error is raised.

Command:
nova flavor-create new_flavor 35 234276234512334234 200 2

n-api LOG:

2016-05-03 10:44:46.744 ERROR nova.api.openstack.extensions 
[req-cadc48da-abb0-4dfb-abb8-c18855e45d30 admin admin] Unexpected exception in 
API method
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions Traceback (most 
recent call last):
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return f(*args, 
**kwargs)
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/compute/flavor_manage.py", line 81, in 
_create
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 
is_public=is_public)
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/compute/flavors.py", line 152, in create
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions db.MAX_INT)
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/utils.py", line 1030, in validate_integer
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 'max_value': 
max_value})
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions InvalidInput: 
Invalid input received: ram must be <= 2147483647
2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions

** Affects: nova
 Importance: Undecided
 Assignee: Dinesh Bhor (dinesh-bhor)
 Status: New

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

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

Title:
  nova flavor-create raises 500 error if long value passed to flavor
  properties

Status in OpenStack Compute (nova):
  New

Bug description:
  If long value is provided for properties other than name and ID then
  500 error is raised.

  Command:
  nova flavor-create new_flavor 35 234276234512334234 200 2

  n-api LOG:

  2016-05-03 10:44:46.744 ERROR nova.api.openstack.extensions 
[req-cadc48da-abb0-4dfb-abb8-c18855e45d30 admin admin] Unexpected exception in 
API method
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions Traceback (most 
recent call last):
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/extensions.py", line 478, in wrapped
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
f(*args, **kwargs)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/compute/flavor_manage.py", line 81, in 
_create
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 
is_public=is_public)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/compute/flavors.py", line 152, in create
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions db.MAX_INT)
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/utils.py", line 1030, in validate_integer
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions 'max_value': 
max_value})
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions InvalidInput: 
Invalid input received: ram must be <= 2147483647
  2016-05-03 10:44:46.744 TRACE nova.api.openstack.extensions

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1577727/+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 1577725] [NEW] Expired token passed to neutron return 500 instead of 401

2016-05-03 Thread sahid

Public bug reported:

If we pass to Nova an about-to-expire token, then Nova pass this token
to neutronclient to manipulate networks. neutronclient can raise an
unauthorized exception. This exception is not understand by Nova and so
converted to a 500 which does not let any chance for novaclient to try a
new attempt of this request with a re-generated token.

We should to convert the unauthorized exception from Neutron to a 401
returned to nova clients.

https://github.com/openstack/python-
novaclient/blob/master/novaclient/client.py#L438

** Affects: nova
 Importance: Undecided
 Assignee: sahid (sahid-ferdjaoui)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => sahid (sahid-ferdjaoui)

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

Title:
  Expired token passed to neutron return 500 instead of 401

Status in OpenStack Compute (nova):
  New

Bug description:
  If we pass to Nova an about-to-expire token, then Nova pass this token
  to neutronclient to manipulate networks. neutronclient can raise an
  unauthorized exception. This exception is not understand by Nova and
  so converted to a 500 which does not let any chance for novaclient to
  try a new attempt of this request with a re-generated token.

  We should to convert the unauthorized exception from Neutron to a 401
  returned to nova clients.

  https://github.com/openstack/python-
  novaclient/blob/master/novaclient/client.py#L438

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1577725/+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 1576245] Re: block live-migration fails if source/dest have different instance dir

2016-05-03 Thread Markus Zoeller (markus_z)

According to ML post [1] this bug report is invalid.

[1] http://lists.openstack.org/pipermail/openstack-
dev/2016-May/093744.html

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

** Changed in: nova
 Assignee: Eli Qiao (taget-9) => (unassigned)

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

Title:
  block live-migration fails if source/dest have different instance dir

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  block live migration fails if using libvirt python inter face
  migrationTOURI3 if source/dest have different instance dir.

  migrationTOURI3 requires a xml on the dest host, but we don't update
  instance dir.

  error logs:

File "/usr/local/lib/python2.7/dist-packages/libvirt.py", line 1833, in 
migrateToURI3
  if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed', 
dom=self)
  libvirtError: Unable to pre-create chardev file 
'/opt/stack/data/nova/instances/e73cc732-8b75-4743-8583-64da9bd7fee0/console.log':
 No such file or directory

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1576245/+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 1577666] Re: Error: No such file or directory: '/etc/keystone/sso_callback_template.html'

2016-05-03 Thread Sohan Sangwan

** Project changed: fuel-plugin-contrail => keystone

** Description changed:

  The following error occurs when a user tries to login using Horizon
  Single Sign-On feature after the Idp authenticates the user and sends
  SAML assertion successfully  :
  
  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request: [Errno 2] No such file or directory:
  '/etc/keystone/sso_callback_template.html' (Disable debug mode to
  suppress these details.)", "code": 500, "title": "Internal Server
  Error"}}
  
  I reproduced the above error while trying to configure Keystone for
  Federation taking TestShib.org as Idp and Keystone as SP.
  
  I am using Security Assertion Markup Language(SAML) for configuring
  Keystone for federation.
  
  The above error got fixed when I copied the sso_callback_template.html
  file to /etc/keystone directory.
  
  cp /opt/stack/keystone/etc/sso_callback_template.html /etc/keystone/
  
- I would recommend to add one more point(7)  as follows:
+ I would recommend to add one more point(5) under Keystone changes  as
+ follows:
  
- 
- 7. Copy the sso_callback_template.html file to /etc/keystone/ directory:
+ 5. Copy the sso_callback_template.html file to /etc/keystone/ directory:
  cp /opt/stack/keystone/etc/sso_callback_template.html /etc/keystone/
  
  in the following documentation(Setup Web Single Sign-On (SSO):
  
  http://docs.openstack.org/developer/keystone/federation/websso.html

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

Title:
  Error: No such file or directory:
  '/etc/keystone/sso_callback_template.html'

Status in OpenStack Identity (keystone):
  New

Bug description:
  The following error occurs when a user tries to login using Horizon
  Single Sign-On feature after the Idp authenticates the user and sends
  SAML assertion successfully  :

  {"error": {"message": "An unexpected error prevented the server from
  fulfilling your request: [Errno 2] No such file or directory:
  '/etc/keystone/sso_callback_template.html' (Disable debug mode to
  suppress these details.)", "code": 500, "title": "Internal Server
  Error"}}

  I reproduced the above error while trying to configure Keystone for
  Federation taking TestShib.org as Idp and Keystone as SP.

  I am using Security Assertion Markup Language(SAML) for configuring
  Keystone for federation.

  The above error got fixed when I copied the sso_callback_template.html
  file to /etc/keystone directory.

  cp /opt/stack/keystone/etc/sso_callback_template.html /etc/keystone/

  I would recommend to add one more point(5) under Keystone changes  as
  follows:

  5. Copy the sso_callback_template.html file to /etc/keystone/ directory:
  cp /opt/stack/keystone/etc/sso_callback_template.html /etc/keystone/

  in the following documentation(Setup Web Single Sign-On (SSO):

  http://docs.openstack.org/developer/keystone/federation/websso.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1577666/+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 1577666] [NEW] Error: No such file or directory: '/etc/keystone/sso_callback_template.html'