[Yahoo-eng-team] [Bug 1483853] Re: Cannot set the VXLAN UDP destination port to 4789 using Linux Bridge

[Tore Anderson]

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

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

Title:
  Cannot set the VXLAN UDP destination port to 4789 using Linux Bridge

Status in neutron:
  Confirmed

Bug description:
  I'm running stable/Juno with VXLAN and Linux Bridge.

  Linux default VxLAN UDP port is 8472.

  IANA assigned port is 4789.

  I tried to add the following in /etc/neutron/plugins/ml2/ml2_conf.ini
  file, but it still use port 8472 afterwards.

  [agent]
  vxlan_udp_port=4789

  ##

  Comments from Kevin Benton:

  Looking at the code, it doesn't look like vxlan_udp_port applies to
  Linux Bridge. Please file a bug and we should be able to get a fix
  pretty quickly.

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

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

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

[Jamie Lennox]

requirements bump: https://review.openstack.org/#/c/330884/

then we can start work on keystonemiddleware, then oslo.context, then
oslo.policy. fun.

** Changed in: keystoneauth
   Importance: Undecided => Medium

** Changed in: keystonemiddleware
   Importance: Undecided => Medium

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

** Also affects: oslo.policy
   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/1577996

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

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

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

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

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

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

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

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

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

[Yahoo-eng-team] [Bug 1542486] Re: nova-compute stack traces with BadRequest: Specifying 'tenant_id' other than authenticated tenant in request requires admin privileges

[Jamie Lennox]

** Changed in: keystonemiddleware
   Status: Incomplete => 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/1542486

Title:
  nova-compute stack traces with BadRequest: Specifying 'tenant_id'
  other than authenticated tenant in request requires admin privileges

Status in OpenStack Identity (keystone):
  Invalid
Status in keystonemiddleware:
  Invalid
Status in OpenStack Compute (nova):
  Invalid
Status in puppet-nova:
  Fix Released

Bug description:
  The puppet-openstack-integration tests (rebased on
  https://review.openstack.org/#/c/276773/ ) currently fail on the
  latest version of RDO Mitaka (delorean current) due to what seems to
  be a problem with the neutron configuration.

  Everything installs fine but tempest fails:
  
http://logs.openstack.org/92/276492/6/check/gate-puppet-openstack-integration-scenario001-tempest-dsvm-centos7/78b9c32/console.html#_2016-02-05_20_26_35_569

  And there are stack traces in nova-compute.log:
  
http://logs.openstack.org/92/276492/6/check/gate-puppet-openstack-integration-scenario001-tempest-dsvm-centos7/78b9c32/logs/nova/nova-compute.txt.gz#_2016-02-05_20_22_16_151

  I talked with #openstack-nova and they pointed out a difference between what 
devstack yields as a [neutron] configuration versus what puppet-nova configures:
  
  # puppet-nova via puppet-openstack-integration
  
  [neutron]
  service_metadata_proxy=True
  metadata_proxy_shared_secret =a_big_secret
  url=http://127.0.0.1:9696
  region_name=RegionOne
  ovs_bridge=br-int
  extension_sync_interval=600
  auth_url=http://127.0.0.1:35357
  password=a_big_secret
  tenant_name=services
  timeout=30
  username=neutron
  auth_plugin=password
  default_tenant_id=default

  
  # Well, it worked in devstack™
  
  [neutron]
  service_metadata_proxy = True
  url = http://127.0.0.1:9696
  region_name = RegionOne
  auth_url = http://127.0.0.1:35357/v3
  password = secretservice
  auth_strategy = keystone
  project_domain_name = Default
  project_name = service
  user_domain_name = Default
  username = neutron
  auth_plugin = v3password

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1542486/+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 1483853] Re: Cannot set the VXLAN UDP destination port to 4789 using Linux Bridge

[Launchpad Bug Tracker]

[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/1483853

Title:
  Cannot set the VXLAN UDP destination port to 4789 using Linux Bridge

Status in neutron:
  Expired

Bug description:
  I'm running stable/Juno with VXLAN and Linux Bridge.

  Linux default VxLAN UDP port is 8472.

  IANA assigned port is 4789.

  I tried to add the following in /etc/neutron/plugins/ml2/ml2_conf.ini
  file, but it still use port 8472 afterwards.

  [agent]
  vxlan_udp_port=4789

  ##

  Comments from Kevin Benton:

  Looking at the code, it doesn't look like vxlan_udp_port applies to
  Linux Bridge. Please file a bug and we should be able to get a fix
  pretty quickly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1483853/+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 1593542] [NEW] Keystone-manage bootstrap can't bootstrap domains other than default

[Shawn Berger]

Public bug reported:

When using keystone-manage bootstrap, you can't define the domain that
you want to bootstrap.  It will always work with default.  The problem
is this doesn't help with a multi-domain environment.  An admin user
defined in the default domain doesn't have any permissions in other
domains.  Once a new domain is created a different admin user specific
to that domain would need to be created in order to be able to act
within it.

If the keystone-manage bootstrap utility could allow bootstrapping of
non-default domains then it could facilitate the administration of
larger, multi-domain cloud environments without the security concern
that arises from the older admin_token method.

** Affects: keystone
 Importance: Undecided
 Assignee: Shawn Berger (slberger)
 Status: New

** Changed in: keystone
 Assignee: (unassigned) => Shawn Berger (slberger)

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

Title:
  Keystone-manage bootstrap can't bootstrap domains other than default

Status in OpenStack Identity (keystone):
  New

Bug description:
  When using keystone-manage bootstrap, you can't define the domain that
  you want to bootstrap.  It will always work with default.  The problem
  is this doesn't help with a multi-domain environment.  An admin user
  defined in the default domain doesn't have any permissions in other
  domains.  Once a new domain is created a different admin user specific
  to that domain would need to be created in order to be able to act
  within it.

  If the keystone-manage bootstrap utility could allow bootstrapping of
  non-default domains then it could facilitate the administration of
  larger, multi-domain cloud environments without the security concern
  that arises from the older admin_token method.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1593542/+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 1593537] [NEW] Unable to run a subset of tests using tox

[Taylor Peoples]

Public bug reported:

If I try to run a subset of tests using tox, such as:

tox -v -e py27 -- openstack_dashboard.test.api_tests.network_tests

I get an error from the manage.py command complaining about unrecognized
arguments:

usage: manage.py test [-h] [--version] [-v {0,1,2,3}] [--settings SETTINGS]
  [--pythonpath PYTHONPATH] [--traceback] [--no-color]
  [--noinput] [--failfast] [--testrunner TESTRUNNER]
  [--liveserver LIVESERVER] [-t TOP_LEVEL]
  [--pattern PATTERN] [-k] [-r] [--debug-sql] [-p] [-q]
  [-c FILES] [-w WHERE] [--py3where PY3WHERE] [-m REGEX]
  [--tests NAMES] [-l DEBUG] [--debug-log FILE]
  [--logging-config FILE] [-I REGEX] [-e REGEX] [-i REGEX]
  [-x] [-P] [--exe] [--noexe] [--traverse-namespace]
  [--first-package-wins] [--no-byte-compile]
  [--with-fixture-bundling] [--with-html-output]
  [--html-out-file FILE] [--with-openstack]
  [--openstack-red OPENSTACK_RED]
  [--openstack-yellow OPENSTACK_YELLOW]
  [--openstack-show-elapsed] [--openstack-color]
  [--openstack-nocolor]
  [--openstack-num-slow OPENSTACK_NUM_SLOW]
  [--openstack-stdout] [--with-noseexclude]
  [--exclude-dir EXCLUDE_DIRS]
  [--exclude-dir-file EXCLUDE_DIR_FILE]
  [--exclude-test EXCLUDE_TESTS]
  [--exclude-test-file EXCLUDE_TEST_FILE]
  [--with-xcoverage] [--xcoverage-file FILE]
  [--xcoverage-to-stdout XCOVERAGE_TO_STDOUT] [-a ATTR]
  [-A EXPR] [-s] [--nologcapture]
  [--logging-format FORMAT] [--logging-datefmt FORMAT]
  [--logging-filter FILTER] [--logging-clear-handlers]
  [--logging-level LOGCAPTURE_LEVEL] [--with-coverage]
  [--cover-package PACKAGE] [--cover-erase]
  [--cover-tests]
  [--cover-min-percentage COVER_MIN_PERCENTAGE]
  [--cover-inclusive] [--cover-html]
  [--cover-html-dir DIR] [--cover-branches] [--cover-xml]
  [--cover-xml-file FILE] [--pdb] [--pdb-failures]
  [--pdb-errors] [--no-deprecated] [--with-doctest]
  [--doctest-tests] [--doctest-extension EXT]
  [--doctest-result-variable VAR]
  [--doctest-fixtures SUFFIX] [--doctest-options OPTIONS]
  [--with-isolation] [-d] [--with-profile]
  [--profile-sort SORT] [--profile-stats-file FILE]
  [--profile-restrict RESTRICT] [--no-skip] [--with-id]
  [--id-file FILE] [--failed] [--processes NUM]
  [--process-timeout SECONDS] [--process-restartworker]
  [--with-xunit] [--xunit-file FILE]
  [--xunit-testsuite-name PACKAGE] [--all-modules]
  [--collect-only]
  [test_label [test_label ...]]
manage.py test: error: unrecognized arguments: 
openstack_dashboard.test.api_tests.network_tests

** Affects: horizon
 Importance: Undecided
 Assignee: Richard Jones (r1chardj0n3s)
 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/1593537

Title:
  Unable to run a subset of tests using tox

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  If I try to run a subset of tests using tox, such as:

  tox -v -e py27 -- openstack_dashboard.test.api_tests.network_tests

  I get an error from the manage.py command complaining about
  unrecognized arguments:

  usage: manage.py test [-h] [--version] [-v {0,1,2,3}] [--settings SETTINGS]
[--pythonpath PYTHONPATH] [--traceback] [--no-color]
[--noinput] [--failfast] [--testrunner TESTRUNNER]
[--liveserver LIVESERVER] [-t TOP_LEVEL]
[--pattern PATTERN] [-k] [-r] [--debug-sql] [-p] [-q]
[-c FILES] [-w WHERE] [--py3where PY3WHERE] [-m REGEX]
[--tests NAMES] [-l DEBUG] [--debug-log FILE]
[--logging-config FILE] [-I REGEX] [-e REGEX] [-i REGEX]
[-x] [-P] [--exe] [--noexe] [--traverse-namespace]
[--first-package-wins] [--no-byte-compile]
[--with-fixture-bundling] [--with-html-output]
[--html-out-file FILE] [--with-openstack]
[--openstack-red OPENSTACK_RED]
 

[Yahoo-eng-team] [Bug 1593533] [NEW] fwaas tempest plugin is using tempest internal api

[YAMAMOTO Takashi]

Public bug reported:

it should use public api as far as possible.

** Affects: neutron
 Importance: Medium
 Status: Confirmed

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

Title:
  fwaas tempest plugin is using tempest internal api

Status in neutron:
  Confirmed

Bug description:
  it should use public api as far as possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593533/+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 1589521] Re: AttributeError: type object 'BaseNetworkTest' has no attribute '_try_delete_resource'

[OpenStack Infra]

Reviewed:  https://review.openstack.org/326231
Committed: 
https://git.openstack.org/cgit/openstack/tap-as-a-service/commit/?id=38f1ab3bd26e7188144367363a385ee913d7d8e0
Submitter: Jenkins
Branch:master

commit 38f1ab3bd26e7188144367363a385ee913d7d8e0
Author: YAMAMOTO Takashi 
Date:   Tue Jun 7 14:29:47 2016 +0900

Use call_and_ignore_notfound_exc directly

This patch makes service client use call_and_ignore_notfound_exc
directly because the client only uses it.

Co-Authored-By: Ken'ichi Ohmichi 
Closes-Bug: #1589521
Change-Id: I8ee81502a090aa0581e0b46b96bfa6144b456cc4


** Changed in: tap-as-a-service
   Status: In Progress => Fix Released

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

Title:
  AttributeError: type object 'BaseNetworkTest' has no attribute
  '_try_delete_resource'

Status in neutron:
  Fix Released
Status in tap-as-a-service:
  Fix Released

Bug description:
  Neutron API job broken by a change in tempest:
  https://review.openstack.org/#/c/277907/

  ...and fwaas tempest plugin using internal symbols from tempest.

  Logs: http://logs.openstack.org/41/325141/3/gate/gate-neutron-dsvm-
  api/281611d/console.html#_2016-06-06_12_27_35_286

  2016-06-06 12:27:35.198 | Failed to import test module: 
neutron_fwaas.tests.tempest_plugin.tests.api.test_fwaas_extensions
  2016-06-06 12:27:35.237 | Traceback (most recent call last):
  2016-06-06 12:27:35.242 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 456, 
iNon-zero exit code (2) from test listing.
  2016-06-06 12:27:35.242 | nerror: testr failed (3)
  2016-06-06 12:27:35.243 |  _find_test_path
  2016-06-06 12:27:35.245 | module = self._get_module_from_name(name)
  2016-06-06 12:27:35.280 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
  2016-06-06 12:27:35.281 | __import__(name)
  2016-06-06 12:27:35.285 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/test_fwaas_extensions.py",
 line 23, in 
  2016-06-06 12:27:35.286 | from 
neutron_fwaas.tests.tempest_plugin.tests.api import base
  2016-06-06 12:27:35.286 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/base.py",
 line 21, in 
  2016-06-06 12:27:35.286 | class 
BaseFWaaSTest(fwaas_client.FWaaSClientMixin, base.BaseNetworkTest):
  2016-06-06 12:27:35.286 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/api/base.py",
 line 22, in BaseFWaaSTest
  2016-06-06 12:27:35.286 | _delete_wrapper = 
base.BaseNetworkTest._try_delete_resource
  2016-06-06 12:27:35.286 | AttributeError: type object 'BaseNetworkTest' has 
no attribute '_try_delete_resource'
  2016-06-06 12:27:35.286 | 
  2016-06-06 12:27:35.286 | Failed to import test module: 
neutron_fwaas.tests.tempest_plugin.tests.scenario.test_fwaas
  2016-06-06 12:27:35.286 | Traceback (most recent call last):
  2016-06-06 12:27:35.287 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
  2016-06-06 12:27:35.287 | module = self._get_module_from_name(name)
  2016-06-06 12:27:35.287 |   File 
"/usr/local/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
  2016-06-06 12:27:35.287 | __import__(name)
  2016-06-06 12:27:35.287 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 21, in 
  2016-06-06 12:27:35.287 | from 
neutron_fwaas.tests.tempest_plugin.tests.scenario import base
  2016-06-06 12:27:35.287 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/base.py",
 line 27, in 
  2016-06-06 12:27:35.287 | manager.NetworkScenarioTest):
  2016-06-06 12:27:35.287 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/base.py",
 line 28, in FWaaSScenarioTest
  2016-06-06 12:27:35.287 | _delete_wrapper = 
manager.NetworkScenarioTest.delete_wrapper
  2016-06-06 12:27:35.287 | AttributeError: type object 'NetworkScenarioTest' 
has no attribute 'delete_wrapper'
  2016-06-06 12:27:35.287 | The test run didn't actually run any tests

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1589521/+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 1564742] Re: [Rules for default security group] miss "security_group_default_rules" parameter

[Augustina Ragwitz]

The parameters for os-security-groups have already been validated as
part of the api-ref effort. If you have information that parameters are
missing, please reopen this bug and provide more detail like where you
see these parameters in code or some output that shows them.

https://review.openstack.org/#/c/315126

** Changed in: nova
 Assignee: Sharat Sharma (sharat-sharma) => (unassigned)

** Changed in: nova
   Status: In Progress => 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/1564742

Title:
  [Rules for default security group] miss "security_group_default_rules"
  parameter

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Request/Response parameters in List default security group rules [1],
  Create default security group rule [2], Show default security group
  rule details [3] miss "security_group_default_rule" parameter.

  [1] 
http://developer.openstack.org/api-ref-compute-v2.1.html#listSecGroupDefaultRules
  [2] 
http://developer.openstack.org/api-ref-compute-v2.1.html#createSecGroupDefaultRule
  [3] 
http://developer.openstack.org/api-ref-compute-v2.1.html#showSecGroupDefaultRule

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1564742/+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 1585985] Re: Add CLI command about region

[Jamie Lennox]

For keystone commands like this are implemented via openstackclient.

These functions have been implemented for the identity v3 api there
already.

Thanks

** Changed in: keystone
   Status: Incomplete => Invalid

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

Title:
  Add CLI command about region

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Now we have no commands that are related to region the current
  version. I think we needs to create a set of commands for
  administrator. - "region-create/delete/list/get/update".

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1585985/+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 1593528] [NEW] Many FWaaS tempest jobs fail with AttributeError

[Kengo Hobo]

Public bug reported:

Tempest jobs fail with following error
because return value of type is changed to dictionary from object.

2016-06-16 18:01:05.207 | Captured traceback:
2016-06-16 18:01:05.207 | ~~~
2016-06-16 18:01:05.207 | Traceback (most recent call last):
2016-06-16 18:01:05.207 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 373, in test_firewall_all_disabled_rules
2016-06-16 18:01:05.207 | 
self._test_firewall_basic(block=self._all_disabled_rules)
2016-06-16 18:01:05.207 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 304, in _test_firewall_basic
2016-06-16 18:01:05.208 | self._create_topology()
2016-06-16 18:01:05.208 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 270, in _create_topology
2016-06-16 18:01:05.208 | floating_ip = 
server_floating_ip.floating_ip_address
2016-06-16 18:01:05.208 | AttributeError: 'dict' object has no attribute 
'floating_ip_address'

I assume that following commit in tempest affects.
https://github.com/openstack/tempest/commit/777a307b3c9f4284facf081e6b951b5755333adf

To know details, please refer top following log.
http://logs.openstack.org/13/326413/3/check/gate-tempest-dsvm-networking-midonet-v2/0ab80e7/console.html

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

** Tags added: fwaas

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

Title:
  Many FWaaS tempest jobs fail with AttributeError

Status in neutron:
  New

Bug description:
  Tempest jobs fail with following error
  because return value of type is changed to dictionary from object.

  2016-06-16 18:01:05.207 | Captured traceback:
  2016-06-16 18:01:05.207 | ~~~
  2016-06-16 18:01:05.207 | Traceback (most recent call last):
  2016-06-16 18:01:05.207 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 373, in test_firewall_all_disabled_rules
  2016-06-16 18:01:05.207 | 
self._test_firewall_basic(block=self._all_disabled_rules)
  2016-06-16 18:01:05.207 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 304, in _test_firewall_basic
  2016-06-16 18:01:05.208 | self._create_topology()
  2016-06-16 18:01:05.208 |   File 
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
 line 270, in _create_topology
  2016-06-16 18:01:05.208 | floating_ip = 
server_floating_ip.floating_ip_address
  2016-06-16 18:01:05.208 | AttributeError: 'dict' object has no attribute 
'floating_ip_address'

  I assume that following commit in tempest affects.
  
https://github.com/openstack/tempest/commit/777a307b3c9f4284facf081e6b951b5755333adf

  To know details, please refer top following log.
  
http://logs.openstack.org/13/326413/3/check/gate-tempest-dsvm-networking-midonet-v2/0ab80e7/console.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593528/+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 1588691] Re: 'keystone_authtoken.user_domain_id' is not in config

[Jamie Lennox]

So these are all options that are configured by a deployer for their
environment. What are you looking to do from murano?

Also you don't need to specify all those options, just use the names and
it will work.

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

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

** Changed in: keystonemiddleware
   Status: New => Incomplete

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

Title:
  'keystone_authtoken.user_domain_id' is not in config

Status in OpenStack Identity (keystone):
  Invalid
Status in keystonemiddleware:
  Incomplete

Bug description:
  During migrating to keystone v3 murano-team faced a problem with getting 
domain variables such as project_domain_name, project_domain_id, 
user_domain_name and user_domain_id. Looks like it never have been placed in 
the right place.
  According the description it should be in config:
  
https://github.com/openstack/keystonemiddleware/blob/f55b0334b919f89fee0b2cfe0a9994fd08c9966c/keystonemiddleware/auth_token/__init__.py#L189

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1588691/+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 1593526] [NEW] compute host reports wrong cpu topology

[Eli Qiao]

Public bug reported:

This is my host's cpu:
ubuntu@jfz1r04h06:~$ lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):72
On-line CPU(s) list:   0-71
Thread(s) per core:2
Core(s) per socket:18
Socket(s): 2
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 63
Model name:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
Stepping:  2
CPU MHz:   1209.386
CPU max MHz:   3600.
CPU min MHz:   1200.
BogoMIPS:  4590.93
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  46080K
NUMA node0 CPU(s): 0-71
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi 
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm 
xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts

Seen from nova-scheduler.

Update host state from compute node:
ComputeNode(cpu_allocation_ratio=16.0,cpu_info='{"vendor": "Intel",
"model": "Haswell-noTSX", "arch": "x86_64", "features": ["pge", "avx",
"xsaveopt", "clflush", "sep", "syscall", "tsc_adjust", "vme", "dtes64",
"invpcid", "msr", "sse", "xsave", "vmx", "erms", "xtpr", "cmov", "smep",
"nx", "est", "pat", "monitor", "smx", "pbe", "lm", "tsc", "fpu", "fxsr",
"tm", "sse4.1", "pae", "sse4.2", "pclmuldq", "pcid", "fma", "tsc-
deadline", "mmx", "osxsave", "cx8", "mce", "de", "tm2", "ht", "dca",
"pni", "abm", "popcnt", "mca", "pdpe1gb", "apic", "fsgsbase", "f16c",
"pse", "ds", "invtsc", "lahf_lm", "aes", "avx2", "sse2", "ss", "ds_cpl",
"arat", "bmi1", "bmi2", "acpi", "ssse3", "rdtscp", "cx16", "pse36",
"mtrr", "movbe", "pdcm", "rdrand", "x2apic"], "topology": {"cores": 18,
"cells": 1, "threads": 2, "sockets": 1}}'

Expected result
===

"topology": {"cores": 18, "cells": 1, "threads": 2, "sockets": 2}}'
<<--

Actual result
=

"topology": {"cores": 18, "cells": 1, "threads": 2, "sockets": 1}}'

This is most likely libvirt bug, reported here :
https://bugzilla.redhat.com/show_bug.cgi?id=1347458

** Affects: nova
 Importance: High
 Assignee: Eli Qiao (taget-9)
 Status: New


** Tags: libvirt

** Tags added: libvirt

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

** Changed in: nova
   Importance: Undecided => High

** Description changed:

  This is my host's cpu:
  ubuntu@jfz1r04h06:~$ lscpu
  Architecture:  x86_64
  CPU op-mode(s):32-bit, 64-bit
  Byte Order:Little Endian
  CPU(s):72
  On-line CPU(s) list:   0-71
  Thread(s) per core:2
  Core(s) per socket:18
  Socket(s): 2
  NUMA node(s):  1
  Vendor ID: GenuineIntel
  CPU family:6
  Model: 63
  Model name:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
  Stepping:  2
  CPU MHz:   1209.386
  CPU max MHz:   3600.
  CPU min MHz:   1200.
  BogoMIPS:  4590.93
  Virtualization:VT-x
  L1d cache: 32K
  L1i cache: 32K
  L2 cache:  256K
  L3 cache:  46080K
  NUMA node0 CPU(s): 0-71
  Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi 
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm 
xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts
  
- 
- Seem from nova.
+ Seen from nova-scheduler.
  
  Update host state from compute node:
  ComputeNode(cpu_allocation_ratio=16.0,cpu_info='{"vendor": "Intel",
  "model": "Haswell-noTSX", "arch": "x86_64", "features": ["pge", "avx",
  "xsaveopt", "clflush", "sep", "syscall", "tsc_adjust", "vme", "dtes64",
  "invpcid", "msr", "sse", "xsave", "vmx", "erms", "xtpr", "cmov", "smep",
  "nx", "est", "pat", "monitor", "smx", "pbe", "lm", "tsc", "fpu", "fxsr",
  "tm", "sse4.1", "pae", "sse4.2", "pclmuldq", "pcid", "fma", "tsc-
  deadline", "mmx", "osxsave", "cx8", "mce", "de", "tm2", "ht", "dca",
  "pni", "abm", "popcnt", "mca", "pdpe1gb", "apic", 

[Yahoo-eng-team] [Bug 1567809] Re: Global requirements update drops extras from oslo.db

[Jamie Lennox]

Fixed in requirements: https://review.openstack.org/#/c/303271/

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

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

Title:
  Global requirements update drops extras from oslo.db

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  As seen https://review.openstack.org/#/c/300626/11/test-
  requirements.txt keystone relies on oslo.db[fixtures,mysql,postgresql]
  but when the requirements update comes through to update its version
  it drops the extras string.

  The requirements process should be smart enough to maintain this
  through update.

  Filing against keystone as I don't think there is a requirements
  project to file bugs against.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1567809/+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 1548433] Re: neutron returns objects other than oslo_config.cfg.Opt instances from list_opts

[Jamie Lennox]

** Changed in: keystoneauth
   Status: Incomplete => Invalid

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

Title:
  neutron returns objects other than oslo_config.cfg.Opt instances from
  list_opts

Status in keystoneauth:
  Invalid
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The neutron function for listing options for use with the
  configuration generator returns things that are not compliant with the
  oslo_config.cfg.Opt class API. At the very least this includes the
  options from keystoneauth1, but I haven't looked to find if there are
  others.

  We'll work around this for now in the configuration generator code,
  but in the future we will more strictly enforce the API compliance by
  refusing to generate a configuration file or by leaving options out of
  the output.

  The change blocked by this issue is:
  https://review.openstack.org/#/c/282435/5

  One failure log showing the issue is:
  http://logs.openstack.org/35/282435/5/check/gate-tempest-dsvm-neutron-
  src-oslo.config/77044c6/logs/devstacklog.txt.gz

  The neutron code triggering the issue is in:
  http://git.openstack.org/cgit/openstack/neutron/tree/neutron/opts.py#n279

  The best solution would be to fix keystoneauth to support option
  discovery natively using proper oslo.config Opts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystoneauth/+bug/1548433/+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 1576093] Re: [SRU] block migration fail with libvirt since version 1.2.17

[Corey Bryant]

This has been uploaded to yakkety and the xenial review queue, awaiting
sru team review.

** Summary changed:

- block migration fail with libvirt since version  1.2.17
+ [SRU] block migration fail with libvirt since version  1.2.17

** Description changed:

+ [Impact]
+ 
  Try to do block migration but fail and libvirt reports that
  
  "Selecting disks to migrate is not implemented for tunneled migration"
  
  Nova:  a4e15e329f9adbcfe72fbcd6acb94f0743ad02f8
  
  libvirt: 1.3.1
  
+ [Test Case]
+ 
  reproduce:
  
  default devstack setting and do block migration (no shared instance_dir
  and shared instance storage used)
+ 
+ [Regression Potential]
+ 
+ Patch was cherry picked from upstream gerrit review, which was cherry
+ picked with little change from master branch.

** Also affects: nova (Ubuntu Yakkety)
   Importance: Undecided
   Status: Confirmed

** Changed in: nova (Ubuntu Yakkety)
   Status: Confirmed => Fix Released

** Changed in: nova (Ubuntu Yakkety)
   Importance: Undecided => High

** Changed in: nova (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: nova (Ubuntu Yakkety)
 Assignee: (unassigned) => Corey Bryant (corey.bryant)

** Changed in: nova (Ubuntu Xenial)
 Assignee: (unassigned) => Corey Bryant (corey.bryant)

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

Title:
  [SRU] block migration fail with libvirt since version  1.2.17

Status in Ubuntu Cloud Archive:
  New
Status in Ubuntu Cloud Archive mitaka series:
  New
Status in OpenStack Compute (nova):
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  Confirmed
Status in nova source package in Yakkety:
  Fix Released

Bug description:
  [Impact]

  Try to do block migration but fail and libvirt reports that

  "Selecting disks to migrate is not implemented for tunneled migration"

  Nova:  a4e15e329f9adbcfe72fbcd6acb94f0743ad02f8

  libvirt: 1.3.1

  [Test Case]

  reproduce:

  default devstack setting and do block migration (no shared
  instance_dir and shared instance storage used)

  [Regression Potential]

  Patch was cherry picked from upstream gerrit review, which was cherry
  picked with little change from master branch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1576093/+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 1593436] Re: Fix designate dns driver for SSL based endpoints

[Darek Smigiel]

** Also affects: openstack-manuals
   Importance: Undecided
   Status: New

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

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

Title:
  Fix designate dns driver for SSL based endpoints

Status in neutron:
  Invalid
Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/326958
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 9cd95366a035b29001ce75515d291cf72d07d0c3
  Author: imran malik 
  Date:   Wed Jun 8 02:45:32 2016 -0700

  Fix designate dns driver for SSL based endpoints
  
  Allow setting options in designate section to specify if want
  to skip SSL cert check. This makes it possible to work with HTTPS
  based endpoints, the default behavior of keystoneclient is to always
  set verify=True however in current code, one cannot either provide
  a valid CA cert or skip the verification.
  
  DocImpact: Introduce two additional options for `[designate]` section
  in neutron.conf
  CONF.designate.insecure to allow insecure connections over SSL.
  CONF.designate.ca_cert for a valid cert when connecting over SSL
  
  Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e
  Closes-Bug: #1588067

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593436/+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 1520094] Re: Retire gettext.install which installs _() as builtin namespace

[OpenStack Infra]

Reviewed:  https://review.openstack.org/320772
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=19c5ec76464568252f8ca0eae28849b2797111c3
Submitter: Jenkins
Branch:master

commit 19c5ec76464568252f8ca0eae28849b2797111c3
Author: Akihiro Motoki 
Date:   Wed May 25 13:12:12 2016 +0900

Drop neutron/i18n.py in favor of neutron/_i18n.py

The hacking rule already ensures everyone uses neutron._i18n.
Now we can drop neutron.i18n.

Closes-Bug: #1520094
Change-Id: I1a415c23fd1db103742e8f3a92a3dd26c7252233


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

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

Title:
  Retire gettext.install which installs _() as builtin namespace

Status in neutron:
  Fix Released

Bug description:
  As oslo.i18n document [1] suggests, we need to replace _() in the
  python builtin namespaces with _ defined in _i18n.py in each module.
  Sharing _() in the builtin namespaces prevents us from looking up per-
  module translation catalogs because it forces all subprojects to use
  "neutron" domain.

  It is required to support per-project message catalog.

  Required actions:

  - Introduce _i18.py with a project specific domain as suggested by oslo.i18n.
  - Change all related project consumes _() from their own _i18n.py
  - Remove gettext.install from neutron/__init__.py.

  I will move forward this bug, but anyone can help me.
  There are many projects under neutron stadium.

  [1] http://docs.openstack.org/developer/oslo.i18n/usage.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1520094/+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 1588067] Re: Designate DNS driver for neutron fails for SSL based endpoints.

[OpenStack Infra]

Reviewed:  https://review.openstack.org/326958
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=9cd95366a035b29001ce75515d291cf72d07d0c3
Submitter: Jenkins
Branch:master

commit 9cd95366a035b29001ce75515d291cf72d07d0c3
Author: imran malik 
Date:   Wed Jun 8 02:45:32 2016 -0700

Fix designate dns driver for SSL based endpoints

Allow setting options in designate section to specify if want
to skip SSL cert check. This makes it possible to work with HTTPS
based endpoints, the default behavior of keystoneclient is to always
set verify=True however in current code, one cannot either provide
a valid CA cert or skip the verification.

DocImpact: Introduce two additional options for `[designate]` section
in neutron.conf
CONF.designate.insecure to allow insecure connections over SSL.
CONF.designate.ca_cert for a valid cert when connecting over SSL

Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e
Closes-Bug: #1588067


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

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

Title:
  Designate DNS driver for neutron fails for SSL based endpoints.

Status in neutron:
  Fix Released

Bug description:
  Summary: 
  I have mitaka based deployment of neutron and designate and while trying to 
test the native integration of neutron with designate using this guide 
http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.html I found 
out my DNS records are not getting created like on port-update or any floating 
ip operations as expected.
  This is because the the endpoints in deployments are SSL based (https) and 
the neutron code of mitaka that gets the keystoneclient session before 
initiating designate client, has no option to allow us to set verify=True/False 
from neutron.conf or in code itself 
https://github.com/openstack/neutron/blob/stable/mitaka/neutron/services/externaldns/drivers/designate/driver.py#L85
 

  this makes it impossible to use neutron integration with designate
  over https based endpoints until the code is changed to:

  """

  _SESSION = session.Session(verify=False)
  """

  Description:

  Neutron has option to use external DNS driver in mitaka, such as designate. 
For that , we need to set the designate options in [designate] section of 
neutron.conf . For example:
  """
  [designate]
  url = http://55.114.111.93:9001/v2
  admin_auth_url = http://55.114.111.93:35357/v2.0
  admin_username = neutron
  admin_password = x5G90074
  admin_tenant_name = service
  allow_reverse_dns_lookup = True
  ipv4_ptr_zone_prefix_size = 24
  ipv6_ptr_zone_prefix_size = 116
  """

  the above example works fine when your url and admin_auth_url are http
  based endpoints. The neutron code uses options of designate section to
  get a session from keystone and uses that session to initiate
  designate admin client session as seen in the neutron code here
  
https://github.com/openstack/neutron/blob/stable/mitaka/neutron/services/externaldns/drivers/designate/driver.py#L89

  In the case, when a deployment has https(SSL terminated) based endpoints, 
meaning both url and admin_auth_url has https, the keystone session is made in 
neutron code using 
  _SESSION = session.Session()

  the default behavior of keystoneclient is that if a url has https, then 
always set verify=True and use the ca file for verification.  
  but neither the option to provide a ca file or set verify=True/False is done 
neutron code for designate driver, this makes it impossible to use the 
integration over SSL based endpoints. 

  As an example of running the same code of mitaka from neutron ::
  """
  >>> admin_auth = 
password.Password(auth_url="https://10.240.128.120:6100/v2.0",username="admin",password="admin",tenant_name="service;)
  >>> _SESSION = session.Session()
  >>> admin_client = d_client.Client(session=_SESSION, auth=admin_auth)
  >>> admin_client.zones.list()
  keystoneauth1.exceptions.connection.SSLError: SSL exception connecting to 
https://10.240.128.120:6100/v2.0/tokens: [Errno 1] _ssl.c:523: 
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed
  """

  after altering the session initiation to set verify=False

  """
  _SESSION = session.Session(verify=False)
  >>> admin_client = d_client.Client(session=_SESSION, auth=admin_auth)
  >>> admin_client.zones.list()
  []
  """

  Proposed fix:

  have an oslo opt for [designate] to let users specify insecure
  operations or set a ca file and use that info from neutron.conf to
  initiate keystone session before getting a designateclient

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

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

[Yahoo-eng-team] [Bug 1593436] [NEW] Fix designate dns driver for SSL based endpoints

[OpenStack Infra]

Public bug reported:

https://review.openstack.org/326958
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

commit 9cd95366a035b29001ce75515d291cf72d07d0c3
Author: imran malik 
Date:   Wed Jun 8 02:45:32 2016 -0700

Fix designate dns driver for SSL based endpoints

Allow setting options in designate section to specify if want
to skip SSL cert check. This makes it possible to work with HTTPS
based endpoints, the default behavior of keystoneclient is to always
set verify=True however in current code, one cannot either provide
a valid CA cert or skip the verification.

DocImpact: Introduce two additional options for `[designate]` section
in neutron.conf
CONF.designate.insecure to allow insecure connections over SSL.
CONF.designate.ca_cert for a valid cert when connecting over SSL

Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e
Closes-Bug: #1588067

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc neutron

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

Title:
  Fix designate dns driver for SSL based endpoints

Status in neutron:
  New

Bug description:
  https://review.openstack.org/326958
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit 9cd95366a035b29001ce75515d291cf72d07d0c3
  Author: imran malik 
  Date:   Wed Jun 8 02:45:32 2016 -0700

  Fix designate dns driver for SSL based endpoints
  
  Allow setting options in designate section to specify if want
  to skip SSL cert check. This makes it possible to work with HTTPS
  based endpoints, the default behavior of keystoneclient is to always
  set verify=True however in current code, one cannot either provide
  a valid CA cert or skip the verification.
  
  DocImpact: Introduce two additional options for `[designate]` section
  in neutron.conf
  CONF.designate.insecure to allow insecure connections over SSL.
  CONF.designate.ca_cert for a valid cert when connecting over SSL
  
  Change-Id: Ic371cc11d783618c38ee40a18206b0c2a197bb3e
  Closes-Bug: #1588067

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593436/+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 1593430] [NEW] password eye icon doesn't toggle

[Cindy Lu]

Public bug reported:

I am not sure if this is a regression or a new feature, but previously,
clicking on the "eye" icon toggled the password field so you could see
it in plain-text.

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

Title:
  password eye icon doesn't toggle

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  I am not sure if this is a regression or a new feature, but
  previously, clicking on the "eye" icon toggled the password field so
  you could see it in plain-text.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1593430/+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 1593418] [NEW] Segmennt create operation doesn't validate network_type

[Miguel Lavalle]

Public bug reported:

POST /segments operations don't validate the network_type attribute in
the request. As a consequence, user can specify any arbitrary value in
this attribute as long as maximum length (64) is not exceeded.

To reproduce send a POST /segments request with a body similar to this:

{
"segment": {
"network_id": "e396da0c-1f1a-42a7-a999-9e74dc624f47",
"physical_network": "physnet2",
"network_type": "hola",
"segmentation_id": 2016
}
}

Neutron server will merrily create the segment:

Status Code: 201 Created

{
  "segment": {
"network_id": "e396da0c-1f1a-42a7-a999-9e74dc624f47",
"segmentation_id": 2016,
"physical_network": "physnet2",
"id": "9c8c49c9-0a99-4f59-abe2-a45c5bb0d7d5",
"network_type": "hola"
  }
}

Showing up in the network: http://paste.openstack.org/show/516726/

** Affects: neutron
 Importance: Medium
 Assignee: Miguel Lavalle (minsel)
 Status: New

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

** Changed in: neutron
 Assignee: (unassigned) => Miguel Lavalle (minsel)

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

Title:
  Segmennt create operation doesn't validate network_type

Status in neutron:
  New

Bug description:
  POST /segments operations don't validate the network_type attribute in
  the request. As a consequence, user can specify any arbitrary value in
  this attribute as long as maximum length (64) is not exceeded.

  To reproduce send a POST /segments request with a body similar to
  this:

  {
  "segment": {
  "network_id": "e396da0c-1f1a-42a7-a999-9e74dc624f47",
  "physical_network": "physnet2",
  "network_type": "hola",
  "segmentation_id": 2016
  }
  }

  Neutron server will merrily create the segment:

  Status Code: 201 Created

  {
"segment": {
  "network_id": "e396da0c-1f1a-42a7-a999-9e74dc624f47",
  "segmentation_id": 2016,
  "physical_network": "physnet2",
  "id": "9c8c49c9-0a99-4f59-abe2-a45c5bb0d7d5",
  "network_type": "hola"
}
  }

  Showing up in the network: http://paste.openstack.org/show/516726/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593418/+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 1593402] [NEW] Neutron returns 500 when creating a segment with non-existent network id

[Miguel Lavalle]

Public bug reported:

When creating a segment with the id of a network that doesn't exist,
Neutron server returns 500 instead of failing gracefully and returning
400.

To reproduce, send a POST /segments request with a body similar to this:

{
"segment": {
"network_id": "c11b9c66-d2d7-4986-877e-042e62684bfb",
"physical_network": "physnet2",
"network_type": "vlan",
"segmentation_id": 2016
}
}

The network_id should not exist. Instead of returning a 400, the server
returns:

500 Internal Server Error

{
  "NeutronError": {
"message": "Request Failed: internal server error while processing your 
request.",
"type": "HTTPInternalServerError",
"detail": ""
  }
}

And the following traceback goes to the Neutron server log:
http://paste.openstack.org/show/516722/. Note the foreign key violation
at the end of the traceback.

** Affects: neutron
 Importance: Medium
 Assignee: Miguel Lavalle (minsel)
 Status: New


** Tags: l3-ipam-dhcp

** Changed in: neutron
 Assignee: (unassigned) => Miguel Lavalle (minsel)

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

** Tags added: l3-ipam-dhcp

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

Title:
  Neutron returns 500 when creating a segment with non-existent network
  id

Status in neutron:
  New

Bug description:
  When creating a segment with the id of a network that doesn't exist,
  Neutron server returns 500 instead of failing gracefully and returning
  400.

  To reproduce, send a POST /segments request with a body similar to
  this:

  {
  "segment": {
  "network_id": "c11b9c66-d2d7-4986-877e-042e62684bfb",
  "physical_network": "physnet2",
  "network_type": "vlan",
  "segmentation_id": 2016
  }
  }

  The network_id should not exist. Instead of returning a 400, the
  server returns:

  500 Internal Server Error

  {
"NeutronError": {
  "message": "Request Failed: internal server error while processing your 
request.",
  "type": "HTTPInternalServerError",
  "detail": ""
}
  }

  And the following traceback goes to the Neutron server log:
  http://paste.openstack.org/show/516722/. Note the foreign key
  violation at the end of the traceback.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593402/+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 1461406] Re: libvirt: missing iotune parse for LibvirtConfigGuestDisk

[Augustina Ragwitz]

Related change was abandoned and it's not clear that this is really a
bug, more like a feature request. Marking as invalid. Please follow the
specless blueprint process if you still want this feature.

** Changed in: nova
 Assignee: ChangBo Guo(gcb) (glongwave) => (unassigned)

** Changed in: nova
   Status: In Progress => 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/1461406

Title:
  libvirt: missing  iotune parse for  LibvirtConfigGuestDisk

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  We support  instance disk IO control with  iotune like :


  102400


  we set iotune in class LibvirtConfigGuestDisk  in libvirt/config.py . The 
method parse_dom doesn't parse iotue options now.
  Need fix that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1461406/+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 1382438] Re: metadata should provides username of the user who created the instances

[Augustina Ragwitz]

This is not a bug, it is a feature request and will be tracked as a
blueprint. Marking as invalid.

** Changed in: nova
   Status: In Progress => 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/1382438

Title:
  metadata should provides username of the user who created the
  instances

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  The metadata provided to instances should contain the username of the
  user who created the instance. At the moment this could only be
  submitted via user_data but we think it should be useful to place that
  in the corresponding json.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1382438/+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 1587239] Re: cover job is failing too frequently

[Steve Martinelli]

Brant, this bug was fixed by a new oslo.messaging release

** Changed in: keystone
   Status: New => Fix Released

** Changed in: keystone
Milestone: None => newton-1

** Changed in: keystone
 Assignee: (unassigned) => Steve Martinelli (stevemar)

** Changed in: keystone
Milestone: newton-1 => newton-2

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

Title:
  cover job is failing too frequently

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  this appears a lot in the cover job logs:

  2016-05-31 03:10:56.236 | pkg_resources.ContextualVersionConflict:
  (amqp 2.0.0 (/home/jenkins/workspace/keystone-coverage-
  db/.tox/cover/lib/python2.7/site-packages),
  Requirement.parse('amqp<2.0,>=1.4.9'), set(['kombu']))

  Looking at the logs, this was installed:

  2016-05-31 03:10:47.259 | cover installed:
  amqp==2.0.0,...kombu==3.0.35

  Which goes against global-requirements:

  amqp>=1.4.0,<2.0 # LGPL

  And upper-requirements:

  amqp===1.4.9

  The tox target does not honor the upper constraints, but has a comment
  indicating it's not possible? I'm not sure.

  [testenv:cover]
  # Also do not run test_coverage_ext tests while gathering coverage as those
  # tests conflict with coverage.
  # NOTE(sdague): this target does not use constraints because
  # upstream infra does not yet support it. Once that's fixed, we can
  # drop the install_command.
  install_command = pip install -U --force-reinstall {opts} {packages}
  commands =
    find keystone -type f -name "*.pyc" -delete
    python setup.py testr --coverage --testr-args='{posargs}'

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1587239/+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 1593386] [NEW] simplifiable if statement

[Tony Xu]

Public bug reported:

Fix pyline simplifiable-if-statement warning

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  simplifiable if statement

Status in neutron:
  New

Bug description:
  Fix pyline simplifiable-if-statement warning

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593386/+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 1529836] Re: Fix deprecated library function (os.popen()).

[OpenStack Infra]

Reviewed:  https://review.openstack.org/315507
Committed: 
https://git.openstack.org/cgit/openstack/group-based-policy-specs/commit/?id=6a5174476104615b858e0b5aa0f50ba56c8a93b5
Submitter: Jenkins
Branch:master

commit 6a5174476104615b858e0b5aa0f50ba56c8a93b5
Author: sharat.sharma 
Date:   Thu May 12 17:38:10 2016 +0530

Fixing the deprecated library function.

os.popen() is deprecated since version 2.6. Resolved with use of
subprocess module.

Change-Id: Ia3c23ad1d02590928a59928ab32cd2f95c09b0da
Closes-Bug: #1529836


** Changed in: group-based-policy-specs
   Status: In Progress => Fix Released

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

Title:
  Fix deprecated library function (os.popen()).

Status in bilean:
  In Progress
Status in Blazar:
  In Progress
Status in Ceilometer:
  Fix Released
Status in ceilometer-powervm:
  Fix Released
Status in Cinder:
  Fix Released
Status in congress:
  In Progress
Status in devstack:
  In Progress
Status in Glance:
  In Progress
Status in glance_store:
  Fix Released
Status in group-based-policy-specs:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in horizon-cisco-ui:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Released
Status in Kwapi:
  In Progress
Status in Manila:
  Fix Released
Status in Murano:
  Fix Released
Status in networking-powervm:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in nova-powervm:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in Python client library for Zaqar:
  In Progress
Status in Sahara:
  Fix Released
Status in senlin:
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress
Status in tempest:
  Fix Released
Status in Zaqar-ui:
  Fix Released

Bug description:
  Deprecated library function os.popen is still in use at some places.
  Need to replace it using subprocess module.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bilean/+bug/1529836/+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 1593362] [NEW] Single Sign on Users must have an identity in keystone

[Sachin]

Public bug reported:

Single sign on (SSO) users from an external identity provider (IDP) are mapped 
to keystone group/user with a mapping rule. The identity of such a user is lost 
in context of OpenStack. Once the operation makes it to OpenStack services, 
only group is available in the context. This poses multiple problems
1. The owners of various objects like VMs, Volumes, Networks are not 
identifiable as that specific SSO user.
2. The user-quota api for various projects like nova, cinder and neutron does 
not work.

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

Title:
  Single Sign on Users must have an identity in keystone

Status in OpenStack Identity (keystone):
  New

Bug description:
  Single sign on (SSO) users from an external identity provider (IDP) are 
mapped to keystone group/user with a mapping rule. The identity of such a user 
is lost in context of OpenStack. Once the operation makes it to OpenStack 
services, only group is available in the context. This poses multiple problems
  1. The owners of various objects like VMs, Volumes, Networks are not 
identifiable as that specific SSO user.
  2. The user-quota api for various projects like nova, cinder and neutron does 
not work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1593362/+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 1593354] [NEW] SNAT HA failed because of missing nat rule in snat namespace iptable

[Hao Chen]

Public bug reported:

I have a mitaka openstack deployment with neutron DVR enabled. When I
try to test the snat HA failover I found that even though the snat
namespace was created on the other backup node, it doesn't has any nat
rule in snat namespace iptable. And run "ip a" in the sant namespace you
will find the sg port is missing.

Here is what I found on the second neutron network node

sandy-pistachio:/opt/openstack # ip netns
qrouter-e25b81f9-8810-4654-9be0-ebac09c700fb
qdhcp-abe36e89-f7a5-4cbd-a7e4-852d80ed92d6
snat-e25b81f9-8810-4654-9be0-ebac09c700fb

sandy-pistachio:/opt/openstack # ip netns exec 
snat-e25b81f9-8810-4654-9be0-ebac09c700fb ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
70: qg-cc3b2f8c-b7:  mtu 1500 qdisc noqueue 
state UNKNOWN group default 
link/ether fa:16:3e:cb:27:cd brd ff:ff:ff:ff:ff:ff
inet 10.240.117.98/28 brd 10.240.117.111 scope global qg-cc3b2f8c-b7
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fecb:27cd/64 scope link 
   valid_lft forever preferred_lft forever

sandy-pistachio:/opt/openstack # ip netns exec 
snat-e25b81f9-8810-4654-9be0-ebac09c700fb iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 


Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 


Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 


Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

sandy-pistachio:/opt/openstack #

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  SNAT HA failed because of missing nat rule in snat namespace iptable

Status in neutron:
  New

Bug description:
  I have a mitaka openstack deployment with neutron DVR enabled. When I
  try to test the snat HA failover I found that even though the snat
  namespace was created on the other backup node, it doesn't has any nat
  rule in snat namespace iptable. And run "ip a" in the sant namespace
  you will find the sg port is missing.

  Here is what I found on the second neutron network node

  sandy-pistachio:/opt/openstack # ip netns
  qrouter-e25b81f9-8810-4654-9be0-ebac09c700fb
  qdhcp-abe36e89-f7a5-4cbd-a7e4-852d80ed92d6
  snat-e25b81f9-8810-4654-9be0-ebac09c700fb

  sandy-pistachio:/opt/openstack # ip netns exec 
snat-e25b81f9-8810-4654-9be0-ebac09c700fb ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  70: qg-cc3b2f8c-b7:  mtu 1500 qdisc noqueue 
state UNKNOWN group default 
  link/ether fa:16:3e:cb:27:cd brd ff:ff:ff:ff:ff:ff
  inet 10.240.117.98/28 brd 10.240.117.111 scope global qg-cc3b2f8c-b7
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:fecb:27cd/64 scope link 
 valid_lft forever preferred_lft forever

  sandy-pistachio:/opt/openstack # ip netns exec 
snat-e25b81f9-8810-4654-9be0-ebac09c700fb iptables -L -n -v -t nat
  Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source   
destination 

  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source   
destination 

  Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source   
destination 

  Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
   pkts bytes target prot opt in out source   
destination 
  sandy-pistachio:/opt/openstack #

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593354/+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 1593342] [NEW] metadata agent does not cache results if cache is configured using oslo.cache options

[Ihar Hrachyshka]

Public bug reported:

When the new configuration options from oslo.cache ([cache]enabled,
[cache]backend, [cache]expiration_time, etc.) are used to configure the
cache instead of the legacy cache_url option, the metadata cache is
never hit.

** Affects: neutron
 Importance: Medium
 Assignee: Ihar Hrachyshka (ihar-hrachyshka)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Ihar Hrachyshka (ihar-hrachyshka)

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

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

Title:
  metadata agent does not cache results if cache is configured using
  oslo.cache options

Status in neutron:
  In Progress

Bug description:
  When the new configuration options from oslo.cache ([cache]enabled,
  [cache]backend, [cache]expiration_time, etc.) are used to configure
  the cache instead of the legacy cache_url option, the metadata cache
  is never hit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593342/+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 1339974] Re: return full version console log

[Augustina Ragwitz]

Marking this as invalid - please resubmit as a blueprint/spec.

** Changed in: nova
   Status: In Progress => 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/1339974

Title:
  return full version console log

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Currently , there is no way to get the entire console log via API.

  It would be great to have an offset parameter which users can  specify
  where to read from the top of file and the API response should contain
  the current reading byte position. This will give users the ability to read
  the entire console log chunk by chunk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1339974/+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 1539698] Re: Kernel and ramdisk ids cannot have 'None' value in Glance

[Augustina Ragwitz]

The patch was abandoned because it was determined these values should be
validated/filtered in the GlanceImageServiceV2 class. Also this issue is
no longer blocking Glance v2 compatibility per
https://review.openstack.org/#/c/321551/

Marking this as invalid, please reopen if I'm mistaken.

** Changed in: nova
   Status: In Progress => 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/1539698

Title:
  Kernel and ramdisk ids cannot have 'None' value in Glance

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Currently if user wants to create an instance using a Glance snapshot that 
has no value for ramdisk_id or kernel_id, then Nova copies the image metadata 
into instance system metadata and prefixes the keys with 'image_'. 
  Due to [1] the None value of ramdisk_id and kernel_id get written as the 
string 'None' in system metadata.

  Unfortunately these values are not accepted by glance image schema in
  v2 api [2].  They can be None, but a not string 'None'.

  This issue doesn't allow us to fully adopt glance v2 api in Nova.

  Paste from  ~smatzek http://paste.openstack.org/show/485397/

  [1] https://github.com/openstack/nova/blob/master/nova/utils.py#L1245
  [2] https://github.com/openstack/glance/blob/master/etc/schema-image.json

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1539698/+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 1591840] Re: tempest test of test_aggregates.py is broken for XenServer

[Bob Ball]

Bug in Tempest, not Nova.  Fixed in
https://review.openstack.org/#/c/328836/

** Project changed: nova => tempest

** Changed in: tempest
   Status: New => Fix Committed

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

Title:
  tempest test of test_aggregates.py is broken for XenServer

Status in tempest:
  Fix Committed

Bug description:
  Citrix XenServer CI has been in failure status due the following
  failed tests:

  2016-06-12 14:19:08.708 | {1} 
tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_host_create_server_with_az
 [0.316267s] ... FAILED
  2016-06-12 14:19:08.715 | {1} 
tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_host_get_details
 [0.239005s] ... FAILED
  2016-06-12 14:19:08.722 | {1} 
tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_host_list
 [0.246983s] ... FAILED
  2016-06-12 14:19:08.729 | {1} 
tempest.api.compute.admin.test_aggregates.AggregatesAdminTestJSON.test_aggregate_add_remove_host
 [0.268097s] ... FAILED

  By some investigation, I believe that's broken by this change:
  
https://review.openstack.org/#/c/316672/9/tempest/api/compute/admin/test_aggregates.py

  We can see the "Citrix XenServer CI" voted -1 on this patch set:
  
http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/72/316672/9/17788/index.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/tempest/+bug/1591840/+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 1524038] Re: Determining glance version fails with https

[Augustina Ragwitz]

Based on the comment in the abandoned change, it looks like this bug is
invalid. Please reopen if I'm mistaken.

** Changed in: nova
   Status: In Progress => 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/1524038

Title:
  Determining glance version fails with https

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  The nova.image.glance.py method _determine_curr_major_version fails
  when using https with certificate validation to communicate with the
  glance server.  The stack looks like this:

  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance Traceback (most recent 
call last):
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance   File 
"/usr/lib/python2.7/dist-packages/nova/image/glance.py", line 170, in 
_determine_curr_major_version
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance response, content = 
http_client.get('/versions')
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance   File 
"/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line 280, in get
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance return 
self._request('GET', url, **kwargs)
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance   File 
"/usr/lib/python2.7/dist-packages/glanceclient/common/http.py", line 261, in 
_request
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance raise 
exc.CommunicationError(message=message)
  2015-12-08 12:26:57.336 31751 ERROR nova.image.glance CommunicationError: 
Error finding address for https://my.glance.server:9292/versions: [SSL: 
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

  The root cause is that this method creates an HttpClient to fetch the
  versions URI  and it does not pass in the cert validation information.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1524038/+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 1520022] Re: boot from wrong volume

[Augustina Ragwitz]

Requested information was not provided and bug was marked for
expiration, so marking as invalid. If this is still an issue for you,
please provide the requested information and reopen it.

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

Title:
  boot from wrong volume

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  In Kilo (and possibly others) there are times when an instance with an
  attached volume is rebooted (or stopped/started) it will boot from vdb
  (the attached volume) instead of vda (the ephemeral boot volume.)

  It doesn't appear to matter whether cinder has the attached volume
  marked bootable or not. Moreover, it doesn't matter if the partition
  is marked bootable or not.

  Details:
  KiloNove, Kilo Cinder, CEPH based ephemeral, Ceph based Cinder.

  Repro:
  1. Create an instance.
  2. Create a volume from an existing instance (snapshot and then volume 
create).
  3. Attach that volume. It will attach as vdb by default (and that remains 
consistent, the volume order doesnt' change).
  4. Reboot the instance
  SOMETIMES or more accurately SOME INSTANCES now boot from vdb1 as /. It seems 
consistent once it happens. The only way I've been able to force booting back 
to vda is to detach the volume (which I can safely re-attach once the instance 
is booted.)

  I've found no other work around.

  Real details:
  nova-compute  1:2015.1.0-0ubuntu1.1~c all 
OpenStack Compute - compute node base
  cinder-common 1:2015.1.0-0ubuntu1~clo all 
Cinder storage service - common files
  python-cinder 1:2015.1.0-0ubuntu1~clo all 
Cinder Python libraries
  python-cinderclient   1:1.1.1-0ubuntu1~cloud0 all 
python bindings to the OpenStack Volume API
  qemu  1:2.2+dfsg-5expubuntu9. amd64   
fast processor emulator
  qemu-system   1:2.2+dfsg-5expubuntu9. amd64   
QEMU full system emulation binaries
  libvirt-bin   1.2.12-0ubuntu13~cloud0 amd64   
programs for the libvirt library
  libvirt-dev   1.2.12-0ubuntu13~cloud0 amd64   
development files for the libvirt library
  libvirt0  1.2.12-0ubuntu13~cloud0 amd64   
library for interfacing with different virtualization systems

  Have not tried to repro in DevStack or with Kilo.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1520022/+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 1592763] Re: No valid host was found. There are not enough hosts available.

[Matt Riedemann]

This is not a bug, this is a support request. Better channels for
requesting support on something like this is the #openstack channel in
freenode IRC, the openstack general mailing list:

https://wiki.openstack.org/wiki/Mailing_Lists#General_List

Or the forum at ask.openstack.org.

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

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

Title:
  No valid host was found. There are not enough hosts available.

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Hi,
  I am getting following error , when launching VM in openstack.
  I am using devstack for compiling openstck.

  following error is shown , when I try to launch VM.
  "No valid host was found. There are not enough hosts available."

  I am using ubuntu cloud image..
  one VM instantiate successfully, but second image not able to launch, give 
above message.

  first I thought, it can be issue of my system RAM. but System RAM
  (DELL server) is 64 GB.

  how to resolve this issue?

  cirros images working fine (i tried launching 3 images, it works).

  My nova settings:-

   created_at: 2016-06-14 15:24:36
updated_at: 2016-06-15 10:18:05
deleted_at: NULL
id: 1
service_id: NULL
 vcpus: 48
 memory_mb: 64152
  local_gb: 49
vcpus_used: 1
memory_mb_used: 2560
 local_gb_used: 20
   hypervisor_type: QEMU
hypervisor_version: 200
  cpu_info: {"vendor": "Intel", "model": "Haswell-noTSX", "arch": 
"x86_64", "features": ["pge", "avx", "clflush", "sep", "syscall", "vme", 
"dtes64", "invpcid", "tsc", "fsgsbase", "xsave", "vmx", "erms", "xtpr", "cmov", 
"smep", "ssse3", "est", "pat", "monitor", "smx", "pbe", "lm", "msr", "nx", 
"fxsr", "tm", "sse4.1", "pae", "sse4.2", "pclmuldq", "acpi", "fma", 
"tsc-deadline", "mmx", "osxsave", "cx8", "mce", "de", "tm2", "ht", "dca", 
"lahf_lm", "abm", "popcnt", "mca", "pdpe1gb", "apic", "sse", "f16c", "pse", 
"ds", "invtsc", "pni", "rdtscp", "avx2", "aes", "sse2", "ss", "ds_cpl", "bmi1", 
"bmi2", "pcid", "fpu", "cx16", "pse36", "mtrr", "movbe", "pdcm", "rdrand", 
"x2apic"], "topology": {"cores": 12, "cells": 2, "threads": 2, "sockets": 1}}
  disk_available_least: 5
   free_ram_mb: 61592
  free_disk_gb: 29

  
  Thanks
  Rohit

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1592763/+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 1592808] Re: Snapshot failed during inconsistencies in glance v2 image schema

[OpenStack Infra]

Reviewed:  https://review.openstack.org/329981
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=3f8076acdc7756b8a5f0f16d4885a47cb001483e
Submitter: Jenkins
Branch:master

commit 3f8076acdc7756b8a5f0f16d4885a47cb001483e
Author: Mike Fedosin 
Date:   Wed Jun 15 17:35:07 2016 +0300

Fix image meta which is sent to glance v2

This commit fixes recently found issues with converting
images in nova format to glance v2.

1. If property string is unicode we shouldn't convert it
to str.

2. kernel_id and ramdisk_id are custom properties and for
this reason they have to be processed on 'properties' layer
and not with regular attributes.

3. In glance v1 it was possible to set empty string to
kernel_id and ramdisk_id properties. In glance v2 it's
forbidden and that's why we have to convert them to
None values.

Change-Id: I950777c5d0292b4a54d14913611038a18ef41d57
Closes-bug: #1592808


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

Title:
  Snapshot failed during inconsistencies in glance v2 image schema

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When trying to create a snapshot with Glance v2 with nodepool the bug
  appears: http://paste.openstack.org/show/516238/

  It happens because in glance v1 it was possible to set empty string to
  kernel_id or ramdisk_id. In v2 it's forbidden.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1592808/+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 1592963] Re: Showing server details on a deleted instance fails for >=v2.26

[OpenStack Infra]

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

commit ffe2487cf60e91659b6cb8a09b10de5455d9a3ed
Author: Matt Riedemann 
Date:   Wed Jun 15 17:21:23 2016 -0400

Pre-load tags when showing server details

When microversion>=2.26 is requested to show server details
we should pre-load 'tags' when getting the instance from the
database. Listing server details already does this, but show
didn't.

Failing to do this can also result in a 500 response from the
server. The scenario is you delete a server and then poll for
it to be gone using 'nova show'. In between the time that the
server is retrieved from the database and the view builder
creates the response, the instance is deleted and since
instance.tags is not set it will attempt to lazy-load the tags
which will fail with an InstanceNotFound.

We need to also fix the lazy-load issue in the instance object
but that will come in a follow-on change.

Change-Id: Iae6551028179e31699c06d06284ca4c1660be240
Closes-Bug: #1592963


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

Title:
  Showing server details on a deleted instance fails for >=v2.26

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  This failed in a python-novaclient functional CI run for newton
  (current master):

  http://logs.openstack.org/11/328211/5/gate/gate-novaclient-dsvm-
  functional/cd6a3d2/logs/screen-n-api.txt.gz?level=TRACE

  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
[req-7b05c7c9-153d-4571-9d56-5a421159af1a admin admin] Unexpected exception in 
API method
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/extensions.py", line 453, in wrapped
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/compute/servers.py", line 543, in show
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions return 
self._view_builder.show(req, instance)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/compute/views/servers.py", line 317, in 
show
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
server["server"]["tags"] = [t.tag for t in instance.tags]
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 
67, in getter
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
self.obj_load_attr(name)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/objects/instance.py", line 985, in obj_load_attr
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
self._load_generic(attrname)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/objects/instance.py", line 765, in _load_generic
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
expected_attrs=[attrname])
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 
181, in wrapper
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions result 
= fn(cls, context, *args, **kwargs)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/objects/instance.py", line 416, in get_by_uuid
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
use_slave=use_slave)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/db/sqlalchemy/api.py", line 225, in wrapper
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/objects/instance.py", line 408, in 
_db_instance_get_by_uuid
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions 
columns_to_join=columns_to_join)
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/db/api.py", line 692, in instance_get_by_uuid
  2016-06-15 19:42:01.313 12360 ERROR nova.api.openstack.extensions return 
IMPL.instance_get_by_uuid(context, uuid, 

[Yahoo-eng-team] [Bug 1593245] [NEW] state_path is registered as cli option whenever common config is imported

[Jakub Libosvar]

Public bug reported:

There is no reason to register cli opt for all parts using common
config. Also registering cli opt doesn't play nice with tempest - see
bug https://bugs.launchpad.net/tempest/+bug/1592345

** Affects: neutron
 Importance: Undecided
 Assignee: Jakub Libosvar (libosvar)
 Status: In Progress

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

Title:
  state_path is registered as cli option whenever common config is
  imported

Status in neutron:
  In Progress

Bug description:
  There is no reason to register cli opt for all parts using common
  config. Also registering cli opt doesn't play nice with tempest - see
  bug https://bugs.launchpad.net/tempest/+bug/1592345

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593245/+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 1593055] Re: Retype an in-use volume failed in mitaka

[Eric Harney]

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

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

Title:
  Retype an in-use volume failed in mitaka

Status in Cinder:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  reproduce:
  1 create an vm 
  2 create a volume in lvm
  3 attach volume to vm
  4 retype volume to another backend

  Look at the log like qemu version problem.My qemu version is like this:
  [root@localhost logs]# rpm -qa | grep qemu
  qemu-img-1.5.3-105.el7_2.4.x86_64
  libvirt-daemon-driver-qemu-1.2.17-13.el7_2.4.x86_64
  ipxe-roms-qemu-20130517-8.gitc4bce43.el7_2.1.noarch
  qemu-kvm-1.5.3-105.el7_2.4.x86_64
  qemu-kvm-common-1.5.3-105.el7_2.4.x86_64

  
  error logs:

  2016-06-16 19:03:46.892 ERROR oslo_messaging.rpc.server 
[req-8c37204e-3484-448a-8aed-35f38403178d admin admin] Exception during 
handling message
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server Traceback (most 
recent call last):
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 133, in 
_process_incoming
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server res = 
self.dispatcher.dispatch(message)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 153, 
in dispatch
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server return 
self._do_dispatch(endpoint, method, ctxt, args)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 122, 
in _do_dispatch
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server result = 
func(ctxt, **new_args)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/exception.py", line 110, in wrapped
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server payload)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 221, in __exit__
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
self.force_reraise()
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 197, in 
force_reraise
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
six.reraise(self.type_, self.value, self.tb)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/exception.py", line 89, in wrapped
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server return f(self, 
context, *args, **kw)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/compute/manager.py", line 359, in decorated_function
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server LOG.warning(msg, 
e, instance=instance)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 221, in __exit__
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
self.force_reraise()
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 197, in 
force_reraise
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
six.reraise(self.type_, self.value, self.tb)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/compute/manager.py", line 328, in decorated_function
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server return 
function(self, context, *args, **kwargs)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/compute/manager.py", line 387, in decorated_function
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
kwargs['instance'], e, sys.exc_info())
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 221, in __exit__
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
self.force_reraise()
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 197, in 
force_reraise
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server 
six.reraise(self.type_, self.value, self.tb)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/compute/manager.py", line 375, in decorated_function
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server return 
function(self, context, *args, **kwargs)
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server   File 
"/opt/stack/nova/nova/compute/manager.py", line 4991, in swap_volume
  2016-06-16 19:03:46.892 TRACE oslo_messaging.rpc.server resize_to)

[Yahoo-eng-team] [Bug 1588906] Re: DHCP port status not active until agent restart

[OpenStack Infra]

Reviewed:  https://review.openstack.org/327062
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=5b0ea0320236d05bc3af0cb338e03f3c3cde040a
Submitter: Jenkins
Branch:master

commit 5b0ea0320236d05bc3af0cb338e03f3c3cde040a
Author: Hong Hui Xiao 
Date:   Wed Jun 8 12:18:53 2016 +

Mark port as ready after enabling dhcp at agent

When subnet is created and network is scheduled to dhcp agent, the
dhcp agent will request neutron server to create dhcp port.

Neutron server will create and mark port as BUILD and wait for the
ready signal from dhcp agent.

dhcp agent will create 'real' dhcp port after getting response from
neutron server. But after that, dhcp agent will not tell neutron server
that the dhcp port is ready. So, the reported bug can be observed.

If ports are created before dhcp is enabled for network, dhcp agent will
not mark ports as 'ready' as there is no network cache. This patch also
marks all ports in network as ready, in case that happens.

Change-Id: I363d8727f7ef6e6e08be4b0022c6464d51692b85
Closes-bug: #1588906


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

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

Title:
  DHCP port status not active until agent restart

Status in neutron:
  Fix Released

Bug description:
  Recreate Step:
  1) Deploy DevStack cloud environment with neutron ML2 OVS.
  2) Create a network and subnet with DHCP enabled.
  3) Check the DHCP port status which will be DOWN or BUILD.
  4) Restart the DHCP agent.
  5) Check the DHCP port status which will now be ACTIVE.

  I've been able to recreate this problem with ML2 OVN as well.  It
  doesn't impact OVN core plugin.  It appears that the DHCP provisioning
  block is not being completed like it once was.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1588906/+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 1591234] Re: should yield the thread when verifying image's signature

[OpenStack Infra]

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

commit a40f4be03f5e964448bf791d9a12ca073338912b
Author: ChangBo Guo(gcb) 
Date:   Wed Jun 1 14:11:00 2016 +0800

Yield the thread when verifying image's signature

We should give other threads chance to run when verifying image's
signature. For more details, please refer to:
http://docs.openstack.org/developer/nova/threading.html# \
yielding-the-thread-in-long-running-tasks

Closes-Bug: #1591234
Change-Id: Id5974b925dbfab7b66b6432abbc92990dea39112


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

Title:
  should yield the thread when verifying image's signature

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
   We should give other threads chance to run when verifying image's
  signature.

   For more details, please refer to:
  http://docs.openstack.org/developer/nova/threading.html#yielding-the-
  thread-in-long-running-tasks

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1591234/+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 1579997] Re: some misspell words in nova

[OpenStack Infra]

Reviewed:  https://review.openstack.org/314406
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=84f09c6ea2f4e3f7067048340a49a0b48329cb48
Submitter: Jenkins
Branch:master

commit 84f09c6ea2f4e3f7067048340a49a0b48329cb48
Author: zhufl 
Date:   Tue May 10 11:43:26 2016 +0800

Correct some misspell words in nova

There are some misspell words in nova,
availabilty (availability)
Synchronise (Synchronize)
evacaute (evacuate)
leagacy (legacy)
doen't (doesn't)
Assocate (Associate)

Change-Id: I9a5e85278c94ba830d94ac15e0b7b8e3efc8e4d8
Closes-Bug: #1579997


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

Title:
  some misspell words in nova

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  There are some misspell words in nova,
  nova/api/openstack/compute/legacy_v2/servers.py  extesions (extensions)
  nova/api/openstack/compute/servers.py  availabilty (availability)
  nova/compute/manager.py  Synchronise (Synchronize)
  nova/compute/manager.py  evacaute (evacuate)
  nova/conductor/rpcapi.py  leagacy (legacy)
  nova/db/sqlalchemy/api.py  doen't (doesn't)
  nova/db/sqlalchemy/models.py  Assocate (Associate)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1579997/+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 1593186] [NEW] Nova instance stuck in powering-off when rebooting all nodes in cluster

[Eyal Posener]

Public bug reported:

After rebooting all nodes in the cluster, all the instances that were running 
on the cluster are stuck in Status ACTIVE, Task state: powering-off, Power 
state: Crashed.
>From the log it looks that during in nova-compute service start, messages sent 
>form init_host method vanished, because the start of RPC server is invoked 
>only afterwards.

The menager.init_host methods, see an instance with vm_state == 
vm_states.ACTIVE and vm_power_state in (power_state.SHUTDOWN, 
power_state.CRASHED). I get the log message "Instance shutdown by itself. 
Calling the stop API. Current vm_state: active, current task_state: None, 
original DB power_state: 1, current VM power_state: 6".
Then it calls the api.stop method, which invokes the api.force_stop method, and 
I see the following log message "Going to try to stop instance force_stop". 
This method invokes through RPC a stop_instance method. But the RPC message 
never reach the RPC server, which is started only after the init_host is called 
in service.start method.
Since I am using rabbitmq, the message queues after rebooting the cluster of 
nodes are not initiated, and the call never gets to the destination.

After wards, the _sync_instance_power_state see the powering-off task
state, and never cleans the instance state. I get the log messages:
"During sync_power_state the instance has a pending task (powering-off).
Skip."

Nova version is 12.0.0.

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  Nova instance stuck in powering-off when rebooting all nodes in
  cluster

Status in OpenStack Compute (nova):
  New

Bug description:
  After rebooting all nodes in the cluster, all the instances that were running 
on the cluster are stuck in Status ACTIVE, Task state: powering-off, Power 
state: Crashed.
  From the log it looks that during in nova-compute service start, messages 
sent form init_host method vanished, because the start of RPC server is invoked 
only afterwards.

  The menager.init_host methods, see an instance with vm_state == 
vm_states.ACTIVE and vm_power_state in (power_state.SHUTDOWN, 
power_state.CRASHED). I get the log message "Instance shutdown by itself. 
Calling the stop API. Current vm_state: active, current task_state: None, 
original DB power_state: 1, current VM power_state: 6".
  Then it calls the api.stop method, which invokes the api.force_stop method, 
and I see the following log message "Going to try to stop instance force_stop". 
This method invokes through RPC a stop_instance method. But the RPC message 
never reach the RPC server, which is started only after the init_host is called 
in service.start method.
  Since I am using rabbitmq, the message queues after rebooting the cluster of 
nodes are not initiated, and the call never gets to the destination.

  After wards, the _sync_instance_power_state see the powering-off task
  state, and never cleans the instance state. I get the log messages:
  "During sync_power_state the instance has a pending task (powering-
  off). Skip."

  Nova version is 12.0.0.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1593186/+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 1593177] [NEW] The default policy should be admin

[Niall Bunting]

Public bug reported:

From: https://review.openstack.org/#/c/309346/

"
I investigated the behaviour of the policy file when various policies are 
removed.

A completely empty policy file will return a 403 Forbidden. As the user
will not match with any of the policies.

However, because glance has the policy ``default: ""``. It means that any 
policy that is not explicitly stated in the the policy.json, is by default 
usable by any member. I think that the ``default`` option is a potentially bad 
thing to have in the policy.json file, due to the ability to give permissions 
without explicitly stating it.
"
Therefore we should change ``"default": "",`` to ``"default": "role:admin",``. 
To make sure that members don't inherit policies that they shouldn't in the 
future. From a operators perspective it should be more secure to have an opt-in 
rather than opt-out.

** Affects: glance
 Importance: Undecided
 Assignee: Niall Bunting (niall-bunting)
 Status: In Progress

** Changed in: glance
 Assignee: (unassigned) => Niall Bunting (niall-bunting)

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

Title:
  The default policy should be admin

Status in Glance:
  In Progress

Bug description:
  From: https://review.openstack.org/#/c/309346/

  "
  I investigated the behaviour of the policy file when various policies are 
removed.

  A completely empty policy file will return a 403 Forbidden. As the
  user will not match with any of the policies.

  However, because glance has the policy ``default: ""``. It means that any 
policy that is not explicitly stated in the the policy.json, is by default 
usable by any member. I think that the ``default`` option is a potentially bad 
thing to have in the policy.json file, due to the ability to give permissions 
without explicitly stating it.
  "
  Therefore we should change ``"default": "",`` to ``"default": 
"role:admin",``. To make sure that members don't inherit policies that they 
shouldn't in the future. From a operators perspective it should be more secure 
to have an opt-in rather than opt-out.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1593177/+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 1522338] Re: root-password command moves instance to error state

[OpenStack Infra]

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

commit c6ffec00037fd0def2f072dcdc3619aa9437b32b
Author: Timofey Durakov 
Date:   Thu Dec 3 12:48:23 2015 +0300

Handle SetAdminPasswdNotSupported raised by libvirt driver

When admin-password operation is not supported by libvirt qemu/kvm
SetAdminPasswdNotSupported exception is raised, compute manager doesn't
handle it, which cause instance state to be set to error.

Closes-bug: #1522338

Change-Id: Ic63e8f723ff19dfa63199e77ea76680bff5a123b


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

Title:
  root-password command moves instance to error state

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When libvirt version is prior to 1.2.16 nova prohibits to set admin password 
for instance. 
  In this case instance is moved to error state, as exception raised by 
_can_set_admin_password method is not handled properly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1522338/+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 1593155] [NEW] over_committed_disk_size is wrong for sparse flat files

[Matthew Booth]

Public bug reported:

The libvirt driver creates flat disks as sparse by default. However, it
always returns over_committed_disk_size=0 for flat disks in
_get_instance_disk_info(). This incorrect data ends up being reported to
the scheduler in the libvirt driver's get_available_resource() via
_get_disk_over_committed_size_total().

_get_instance_disk_info() should use allocated blocks, not file size,
when calculating over_commited_disk_size for flat disks.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: libvirt 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/1593155

Title:
  over_committed_disk_size is wrong for sparse flat files

Status in OpenStack Compute (nova):
  New

Bug description:
  The libvirt driver creates flat disks as sparse by default. However,
  it always returns over_committed_disk_size=0 for flat disks in
  _get_instance_disk_info(). This incorrect data ends up being reported
  to the scheduler in the libvirt driver's get_available_resource() via
  _get_disk_over_committed_size_total().

  _get_instance_disk_info() should use allocated blocks, not file size,
  when calculating over_commited_disk_size for flat disks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1593155/+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 1593126] Re: Remove mox from testing infrastructure in neutronclient for Newton

[Zhigang Li]

** Changed in: neutron
 Assignee: (unassigned) => Zhigang Li (li-zhigang3)

** Project changed: neutron => python-neutronclient

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

Title:
  Remove mox from testing infrastructure in neutronclient for Newton

Status in python-neutronclient:
  New

Bug description:
  This is to pick up on the work from mitaka for blueprint remove-mox:

  https://blueprints.launchpad.net/nova/+spec/remove-mox

  We need to do the work in neutronclient for Newton.

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-neutronclient/+bug/1593126/+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 1593130] [NEW] There is no description how IP_VERSION values in 'address-scope-create' help msg, adding it makes help msg more clearly

[xiewj]

Public bug reported:

There is no description how IP_VERSION values in 'address-scope-create'
help msg.According to the help information 'Specify the address family
of the address scope.',the users may not be clear what does 'the address
family' mean.

Therefore, help information points out how 'the address family' values
seems to be more appropriate.

[root@localhost devstack]# neutron help address-scope-create
usage: neutron address-scope-create [-h] [-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width ]
[--noindent] [--prefix PREFIX]
[--request-format {json}]
[--tenant-id TENANT_ID] [--shared]
NAME IP_VERSION

Create an address scope for a given tenant.

positional arguments:
  NAME  Specify the name of the address scope.
  IP_VERSIONSpecify the address family of the address scope.

'IP_VERSION Specify the address family of the address scope (choose from
4, 6).' instead of 'IP_VERSION Specify the address family of the address
scope.'

** Affects: neutron
 Importance: Undecided
 Status: New

** Summary changed:

- There is no description of the IP_VERSION values in 'address-scope-create' 
help msg,adding it makes help msg more clearly
+ There is no description how IP_VERSION values in 'address-scope-create' help 
msg,adding it makes help msg more clearly

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

Title:
  There is no description how IP_VERSION values in 'address-scope-
  create' help msg,adding it makes help msg more clearly

Status in neutron:
  New

Bug description:
  There is no description how IP_VERSION values in 'address-scope-
  create' help msg.According to the help information 'Specify the
  address family of the address scope.',the users may not be clear what
  does 'the address family' mean.

  Therefore, help information points out how 'the address family' values
  seems to be more appropriate.

  [root@localhost devstack]# neutron help address-scope-create
  usage: neutron address-scope-create [-h] [-f {json,shell,table,value,yaml}]
  [-c COLUMN] [--max-width ]
  [--noindent] [--prefix PREFIX]
  [--request-format {json}]
  [--tenant-id TENANT_ID] [--shared]
  NAME IP_VERSION

  Create an address scope for a given tenant.

  positional arguments:
    NAME  Specify the name of the address scope.
    IP_VERSIONSpecify the address family of the address scope.

  'IP_VERSION Specify the address family of the address scope (choose
  from 4, 6).' instead of 'IP_VERSION Specify the address family of the
  address scope.'

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593130/+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 1593127] [NEW] VIP delete event payload does not have sufficent information

[Kumar Acharya]

Public bug reported:

Existing context for vip.delete.start only contains loadbalancer id as the 
payload.
This will not help if we want to automate few things from designate perspective 
like deleting records associated with the loadbalancer.

Since this is delete process, we don't have any other way also to get
the required info as when the vip is deleted all related information is
also deleted.

The current payload:
"payload":{
  "loadbalancer_id":"8c5c5886-2d5c-4826-8632-1678e1217a72"
   }

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

Title:
  VIP delete event  payload does not have sufficent information

Status in neutron:
  New

Bug description:
  Existing context for vip.delete.start only contains loadbalancer id as the 
payload.
  This will not help if we want to automate few things from designate 
perspective like deleting records associated with the loadbalancer.

  Since this is delete process, we don't have any other way also to get
  the required info as when the vip is deleted all related information
  is also deleted.

  The current payload:
  "payload":{
"loadbalancer_id":"8c5c5886-2d5c-4826-8632-1678e1217a72"
 }

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593127/+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 1593126] [NEW] Remove mox from testing infrastructure in neutronclient for Newton

[Zhigang Li]

Public bug reported:

This is to pick up on the work from mitaka for blueprint remove-mox:

https://blueprints.launchpad.net/nova/+spec/remove-mox

We need to do the work in neutronclient for Newton.

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  Remove mox from testing infrastructure in neutronclient for Newton

Status in neutron:
  New

Bug description:
  This is to pick up on the work from mitaka for blueprint remove-mox:

  https://blueprints.launchpad.net/nova/+spec/remove-mox

  We need to do the work in neutronclient for Newton.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1593126/+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 1593119] [NEW] The _wrn_threshold should be removed

[zhaolihui]

Public bug reported:

The data member _wrn_threshold of
oslo_messaging._driver.amqpdriver.ReplyWaiters should be removed.

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

** Project changed: nova => oslo.messaging

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

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

Title:
  The _wrn_threshold should be removed

Status in oslo.messaging:
  New

Bug description:
  The data member _wrn_threshold of
  oslo_messaging._driver.amqpdriver.ReplyWaiters should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo.messaging/+bug/1593119/+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 1593120] [NEW] Unable to get OAuth request token

[keerthivasan selvaraj]

Public bug reported:

I am using keystone(Liberty), trying to use OAuth functionality inside
keystone.

References:

https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
api-v3-os-oauth1-ext.html

I am following the above link for reference to use OAuth

Able to create consumer, while creating request_token i am getting
invalid signature error.(unauthorized)

 == > /usr/lib/python2.7/site-
packages/keystoneclient/v3/contrib/oauth1/request_tokens.py

After the Oauth sign, i got the header,endpoint as below,

headers:

{u'Authorization': u'OAuth oauth_nonce="16761963350708363801466058910",
oauth_timestamp="1466058910", oauth_version="1.0",
oauth_signature_method="HMAC-SHA1",
oauth_consumer_key="7fc8945e648248e9a5694bee3a141ac0",
oauth_callback="oob",
oauth_signature="i4UDLi75qcTKu%2FClW7KNtIl1SI4%3D"', u'requested-
project-id': u'7908bbde268348a9991ecdfa76fda577'}

endpoint:

'/OS-OAUTH1/request_token'


Error:

keystoneclient.exceptions.Unauthorized: Invalid signature (Disable debug
mode to suppress these details.) (HTTP 401)

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: federation keystone oauth

** Attachment added: "python for getting request_token"
   https://bugs.launchpad.net/bugs/1593120/+attachment/4684752/+files/oauth-1.py

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

Title:
  Unable to get OAuth request token

Status in OpenStack Identity (keystone):
  New

Bug description:
  I am using keystone(Liberty), trying to use OAuth functionality inside
  keystone.

  References:

  https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-
  api-v3-os-oauth1-ext.html

  I am following the above link for reference to use OAuth

  Able to create consumer, while creating request_token i am getting
  invalid signature error.(unauthorized)

   == > /usr/lib/python2.7/site-
  packages/keystoneclient/v3/contrib/oauth1/request_tokens.py

  After the Oauth sign, i got the header,endpoint as below,

  headers:

  {u'Authorization': u'OAuth
  oauth_nonce="16761963350708363801466058910",
  oauth_timestamp="1466058910", oauth_version="1.0",
  oauth_signature_method="HMAC-SHA1",
  oauth_consumer_key="7fc8945e648248e9a5694bee3a141ac0",
  oauth_callback="oob",
  oauth_signature="i4UDLi75qcTKu%2FClW7KNtIl1SI4%3D"', u'requested-
  project-id': u'7908bbde268348a9991ecdfa76fda577'}

  endpoint:

  '/OS-OAUTH1/request_token'

  
  Error:

  keystoneclient.exceptions.Unauthorized: Invalid signature (Disable
  debug mode to suppress these details.) (HTTP 401)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1593120/+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 1593116] [NEW] Not able to delete the keystone deafult endpoint in mitaka

[Ranjith Kumar]

Public bug reported:

I tried to manually delete default endpoint like cinder, nova etc.
which is by default there in keystone catalogue service( Mitaka).   But
I am getting the error: Unable to delete endpoint. But I created new
endpoint and able to delete the same. When I tried to show the same
endpoint , I am able to see the endpoint details using "openstack
endpoint show "!.

I have tried to delete endpoint in both clients like "Keystone endpoint-delete" 
 and "openstack endpoint delete"
Here are the details:

Keystone endpoint-list:
+--+---+---+---+---+--+
|id|   region  |   publicurl
   |  internalurl  |
adminurl   |service_id|
+--+---+---+---+---+--+
| 5421c0400964427b88253705cfc362f3 | RegionOne |  
http://10.247.142.242:8776/v1/$(tenant_id)s  |  
http://10.247.142.242:8776/v1/$(tenant_id)s  |  
http://10.247.142.242:8776/v1/$(tenant_id)s  | c921017f3db842948726c505889d67fd 
|
| 6be3ce2561ab4828878b821ae621878e | RegionOne |   
http://10.247.142.242:9292  |   http://10.247.142.242:9292  
|   http://10.247.142.242:9292  | 
f7ab568662cd4cd6881d0269b7a5bbf9 |
| 7d71b37916cc433aa70821e496e0ade0 | RegionOne |
http://10.247.142.242:5000/v2.0|http://10.247.142.242:5000/v2.0 
   |http://10.247.142.242:35357/v2.0   | 
6062610ff8394d588b5bf1c54e5eef06 |
| 956a68a0bf8f40b0a63681f855152a17 | RegionOne | 
http://10.247.142.242:8774/v2.1/$(tenant_id)s | 
http://10.247.142.242:8774/v2.1/$(tenant_id)s | 
http://10.247.142.242:8774/v2.1/$(tenant_id)s | 
5f5cfe23d54a4a4a9b7d78fa7f476490 |
| d58f88977f334801ab25ce2a92a6d354 | RegionOne |  
http://10.247.142.242:8774/v2/$(tenant_id)s  |  
http://10.247.142.242:8774/v2/$(tenant_id)s  |  
http://10.247.142.242:8774/v2/$(tenant_id)s  | 55cfa6d5a00a4f95904e07f64a8b812b 
|
| f61da8bdd3224b3c9ecadca1b5de359a | RegionOne |  
http://10.247.142.242:8776/v2/$(tenant_id)s  |  
http://10.247.142.242:8776/v2/$(tenant_id)s  |  
http://10.247.142.242:8776/v2/$(tenant_id)s  | 383a734f6da3472a8da65e6d13762567 
|

+--+---+---+

keystone  endpoint-delete 5421c0400964427b88253705cfc362f3
==
/usr/local/lib/python2.7/dist-packages/keystoneclient/shell.py:64: 
DeprecationWarning: The keystone CLI is deprecated in favor of 
python-openstackclient. For a Python library, continue using 
python-keystoneclient.
  'python-keystoneclient.', DeprecationWarning)
/usr/local/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py:145: 
DeprecationWarning: Constructing an instance of the 
keystoneclient.v2_0.client.Client class without a session is deprecated as of 
the 1.7.0 release and may be removed in the 2.0.0 release.
  'the 2.0.0 release.', DeprecationWarning)
/usr/local/lib/python2.7/dist-packages/keystoneclient/v2_0/client.py:147: 
DeprecationWarning: Using the 'tenant_name' argument is deprecated in version 
'1.7.0' and will be removed in version '2.0.0', please use the 'project_name' 
argument instead
  super(Client, self).__init__(**kwargs)
/usr/local/lib/python2.7/dist-packages/debtcollector/renames.py:45: 
DeprecationWarning: Using the 'tenant_id' argument is deprecated in version 
'1.7.0' and will be removed in version '2.0.0', please use the 'project_id' 
argument instead
  return f(*args, **kwargs)
/usr/local/lib/python2.7/dist-packages/keystoneclient/httpclient.py:371: 
DeprecationWarning: Constructing an HTTPClient instance without using a session 
is deprecated as of the 1.7.0 release and may be removed in the 2.0.0 release.
  'the 2.0.0 release.', DeprecationWarning)
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:140: 
DeprecationWarning: keystoneclient.session.Session is deprecated as of the 
2.1.0 release in favor of keystoneauth1.session.Session. It will be removed in 
future releases.
  DeprecationWarning)
/usr/local/lib/python2.7/dist-packages/keystoneclient/auth/identity/base.py:56: 
DeprecationWarning: keystoneclient auth plugins are deprecated as of the 2.1.0 
release in favor of keystoneauth1 plugins. They will be removed in future 
releases.
  'in future releases.', DeprecationWarning)
Unable to delete endpoint.

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!

[Yahoo-eng-team] [Bug 1592988] Re: create_project is not properly looking up the domain_id

[Jamie Lennox]

So yea, I've seen this before at least on bugzilla and we never had a
great way to deal with it.

Steve's correct, if you use domain name then OSC must try to resolve
that domain name into a domain_id to perform the operation and the way
it does that is by doing a list operation. Listing domains is a very
privileged operation for obvious reasons.

I think this is really a policy problem we should fix. Because domain
names are also unique you  should be able to find your domain by name in
this way without exposing other domains. I would need to think about
what priviledges you would need to be able to view a domain's details
like this but i assumes it's the same as GET /domains/

** Also 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/1592988

Title:
  create_project is not properly looking up the domain_id

Status in OpenStack Identity (keystone):
  New
Status in python-keystoneclient:
  Invalid
Status in python-openstackclient:
  Confirmed

Bug description:
  Reported by Eduard Barrera in
  https://bugzilla.redhat.com/show_bug.cgi?id=1346886

  Keystone is not properly looking up the domain_id, please check the
  highlighted log lines

  
  # openstack project create --domain my_domain my_domain_project1
   
  2016-06-15 04:52:06.795 9535 DEBUG keystone.middleware.core [-] Auth token 
not in the request header. Will not build auth context. process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:223
  2016-06-15 04:52:06.798 9535 INFO keystone.common.wsgi [-] POST 
http://192.168.101.196:5000/v3/auth/tokens
   
  2016-06-15 04:52:06.897 9535 DEBUG keystone.middleware.core [-] Auth token 
not in the request header. Will not build auth context. process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:223
  2016-06-15 04:52:06.899 9535 INFO keystone.common.wsgi [-] POST 
http://192.168.101.196:5000/v3/auth/tokens
  2016-06-15 04:52:06.978 14354 INFO keystone.common.wsgi [-] GET 
http://192.168.101.196:35357/
  2016-06-15 04:52:06.986 14354 DEBUG keystone.middleware.core [-] RBAC: 
auth_context: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'access_token_id': None, 'domain_id': 
u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
  2016-06-15 04:52:06.988 14354 INFO keystone.common.wsgi [-] GET 
http://192.168.101.196:35357/v3/domains/my_domain
  2016-06-15 04:52:06.988 14354 DEBUG keystone.common.controller [-] RBAC: 
Authorizing identity:get_domain(domain_id=my_domain) 
_build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:61

  <===

  2016-06-15 04:52:06.989 14354 DEBUG keystone.common.controller [-] RBAC: 
using auth context from the request environment _build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:66
  2016-06-15 04:52:06.992 14354 WARNING keystone.common.wsgi [-] Could not find 
domain: my_domain
  2016-06-15 04:52:07.000 14354 DEBUG keystone.middleware.core [-] RBAC: 
auth_context: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'access_token_id': None, 'domain_id': 
u'2e25369784564c508fdb51903ce98368', 'trust_id': None} process_request 
/usr/lib/python2.7/site-packages/keystone/middleware/core.py:233
  2016-06-15 04:52:07.002 14354 INFO keystone.common.wsgi [-] GET 
http://192.168.101.196:35357/v3/domains?name=my_domain
  2016-06-15 04:52:07.002 14354 DEBUG keystone.common.controller [-] RBAC: 
Authorizing identity:list_domains() _build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:61
  2016-06-15 04:52:07.002 14354 DEBUG keystone.common.controller [-] RBAC: 
using auth context from the request environment _build_policy_check_credentials 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:66
  2016-06-15 04:52:07.003 14354 DEBUG keystone.common.controller [-] RBAC: 
Adding query filter params (name=my_domain) wrapper 
/usr/lib/python2.7/site-packages/keystone/common/controller.py:193
  2016-06-15 04:52:07.003 14354 DEBUG keystone.policy.backends.rules [-] 
enforce identity:list_domains: {'is_delegated_auth': False, 'user_id': 
u'7f603b47d9a14ed2aa4f10d0182c2e3e', 'roles': [u'admin'], 'trustee_id': None, 
'trustor_id': None, 'consumer_id': None, 'token': , 'access_token_id': None, 'domain_id': 
u'2e25369784564c508fdb51903ce98368', 'trust_id': None} enforce 
/usr/lib/python2.7/site-packages/keystone/policy/backends/rules.py:76
  2016-06-15 04:52:07.005 14354 WARNING