[Yahoo-eng-team] [Bug 1618666] Re: deprecated warning for SafeConfigParser

[John L. Villalovos]

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

** Changed in: ironic
   Importance: Undecided => Low

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

Title:
  deprecated warning for SafeConfigParser

Status in Glance:
  In Progress
Status in glance_store:
  In Progress
Status in Ironic:
  New
Status in OpenStack Identity (keystone):
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in PBR:
  Fix Released
Status in python-swiftclient:
  In Progress
Status in OpenStack Object Storage (swift):
  In Progress
Status in tempest:
  In Progress
Status in OpenStack DBaaS (Trove):
  In Progress

Bug description:
  tox -e py34 is reporting a deprecation warning for SafeConfigParser

  /octavia/.tox/py34/lib/python3.4/site-packages/pbr/util.py:207: 
DeprecationWarning: The SafeConfigParser class has been renamed to ConfigParser 
in Python 3.2. This alias will be removed in future versions. Use ConfigParser 
directly instead.
parser = configparser.SafeConfigParser()

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1618666/+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 1621782] Re: Production code must not import from neutron.tests.*

[OpenStack Infra]

Reviewed:  https://review.openstack.org/367340
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=31e1aeb66b2d8abb0d8424e9550693fad6f37c1c
Submitter: Jenkins
Branch:master

commit 31e1aeb66b2d8abb0d8424e9550693fad6f37c1c
Author: Ihar Hrachyshka 
Date:   Tue Aug 30 10:42:41 2016 +

Forbid importing neutron.tests.* from outside tests subtree

neutron-sanity-check tool was importing neutron.tests.base module, which
may be not present on some systems (f.e. RDO splits neutron/tests/
subtree in a separate python-neutron-tests package). It made the tool
not usable in some setups.

https://bugzilla.redhat.com/show_bug.cgi?id=1374282

This is not the first time when we by mistake import from
neutron.tests.* and break distributions. It's time to stop it by
proactively forbidding that pattern via a new hacking check.

Some functions were moved from neutron.tests.base to
neutron.common.utils to fulfill the need requirement. They were moved
using debtcollector, no current consumers should be affected.

Closes-Bug: #1621782
Change-Id: I790777ddcbd1b02218b3db54ae3d5c931d72d4fa


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

** Bug watch added: Red Hat Bugzilla #1374282
   https://bugzilla.redhat.com/show_bug.cgi?id=1374282

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

Title:
  Production code must not import from neutron.tests.*

Status in neutron:
  Fix Released

Bug description:
  sanity-check tool for one imports some util functions from
  neutron.tests.base. This makes distributions that split out tests
  subtree in a separate package somewhat broken.

  It's my belief we should really enforce the requirement via hacking
  check, otherwise we will hit similar issues in the future.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1621782/+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 1625136] Re: linuxbridge trunk plugin doesn't handle subport changes without trunk update

[OpenStack Infra]

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

commit 19f3e9a50edcd4027a325aaf60c6e5fbedd7baac
Author: Kevin Benton 
Date:   Mon Sep 19 04:21:27 2016 -0700

Fix linuxbridge trunk subport RPC event handler

The part of the linuxbridge trunk driver that actually triggered
the dataplane wiring for subport changes was incorrectly trying to
fetch the trunk using the trunk ID with a method expecting the port
ID. This would always result in it thinking the trunk wasn't on the
host and returning without wiring.

This fixes it by adding another method to fetch trunks by trunk ID.
All of the other operations in this function already expect trunk IDs.

This was discovered and the fix verified with the scenario test in
the dependent patch.

Change-Id: I25324bc1445cc083799ff54f8508a9505517ce84
Closes-Bug: #1625136


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

Title:
  linuxbridge trunk plugin doesn't handle subport changes without trunk
  update

Status in neutron:
  Fix Released

Bug description:
  The subport event handler is not correctly triggering wiring changes
  when the subports for a trunk already present on the agent are
  changed. This leaves a trunk dataplane frozen in time once its first
  wired up on the linux bridge agent unless it receives another trunk
  event.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625136/+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 1624700] Re: admin image table failed to load image list

[OpenStack Infra]

Reviewed:  https://review.openstack.org/372400
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=66094201154dbdb09782e78f15840c8aeade4fc6
Submitter: Jenkins
Branch:master

commit 66094201154dbdb09782e78f15840c8aeade4fc6
Author: Timur Sufiev 
Date:   Mon Sep 19 13:56:18 2016 +0300

Fix getting the images list in Admin->Images

Do this by converting 'None' / 'True' / 'False' to their Python
counterparts.

Change-Id: Ifd17f4587759e7a67218278d28ee77fc9b80530a
Closes-Bug: #1624700


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

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

Title:
  admin image table failed to load image list

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Admin Image panel fails to load image list with the following error message.
  Due to the error, the admin image table has no content.

  2016-09-17 15:21:46.000420 error invoking apiclient
  2016-09-17 15:21:46.000461 Traceback (most recent call last):
  2016-09-17 15:21:46.000466   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/rest/utils.py",
 line 126, in _wrapped
  2016-09-17 15:21:46.000470 data = function(self, request, *args, **kw)
  2016-09-17 15:21:46.000474   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/rest/glance.py",
 line 163, in get
  2016-09-17 15:21:46.000477 request, filters=filters, **kwargs)
  2016-09-17 15:21:46.000480   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
 line 281, in image_list_detailed
  2016-09-17 15:21:46.000484 _normalize_list_input(filters, **kwargs)
  2016-09-17 15:21:46.000487   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
 line 176, in _normalize_list_input
  2016-09-17 15:21:46.000491 _normalize_is_public_filter(filters)
  2016-09-17 15:21:46.000495   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
 line 165, in _normalize_is_public_filter
  2016-09-17 15:21:46.000498 visibility = 
PUBLIC_TO_VISIBILITY_MAP[filters['is_public']]
  2016-09-17 15:21:46.000502 KeyError: u'None'
  2016-09-17 15:21:46.020015 error invoking apiclient
  2016-09-17 15:21:46.020089 Traceback (most recent call last):
  2016-09-17 15:21:46.020121   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/rest/utils.py",
 line 126, in _wrapped
  2016-09-17 15:21:46.020147 data = function(self, request, *args, **kw)
  2016-09-17 15:21:46.020172   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/rest/glance.py",
 line 163, in get
  2016-09-17 15:21:46.020196 request, filters=filters, **kwargs)
  2016-09-17 15:21:46.020219   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
 line 281, in image_list_detailed
  2016-09-17 15:21:46.020265 _normalize_list_input(filters, **kwargs)
  2016-09-17 15:21:46.020293   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
 line 176, in _normalize_list_input
  2016-09-17 15:21:46.020321 _normalize_is_public_filter(filters)
  2016-09-17 15:21:46.020366   File 
"/opt/stack/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/api/glance.py",
 line 165, in _normalize_is_public_filter
  2016-09-17 15:21:46.020396 visibility = 
PUBLIC_TO_VISIBILITY_MAP[filters['is_public']]
  2016-09-17 15:21:46.020420 KeyError: u'None'

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1624700/+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 1615055] Re: remove invalid magic-search link from jasmine.html

[OpenStack Infra]

Reviewed:  https://review.openstack.org/349629
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=89efd7f6f6bc91fb3f0f92abbfdd8a3c00b6d6ba
Submitter: Jenkins
Branch:master

commit 89efd7f6f6bc91fb3f0f92abbfdd8a3c00b6d6ba
Author: Cindy Lu 
Date:   Fri Jul 29 14:46:05 2016 -0700

Fix jasmine test failures due to missing ngRoute, schema-form dep

Resource Browser panel 2 jasmine test failure.
Fix 2 tests with no expectation for http.spec.js.
Remove undefined magic_search.js path in jasmine.html.
Fix missing expectations in create.action.service.spec.js.
Fix some formatting.

Open up console for localhost:/jasmine/ before and
after this patch to see the errors.

Change-Id: I0ebd25dc50c2310e23ce8fed8f2a1adebc64ad15
Closes-Bug: #1615055


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

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

Title:
  remove invalid magic-search link from jasmine.html

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  If you open up the console when doing localhost:/jasmine you
  will see an error for

  GET
  http://localhost:8001/static/horizon/lib/magic_search/magic_search.js

  This file is invalid. Remove this call.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1615055/+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 1339855] Re: Raise NotImplementedError instead of NotImplemented

[OpenStack Infra]

Reviewed:  https://review.openstack.org/367735
Committed: 
https://git.openstack.org/cgit/openstack/heat/commit/?id=2a662465361e31dbf230d597182f9f7fd8b61183
Submitter: Jenkins
Branch:master

commit 2a662465361e31dbf230d597182f9f7fd8b61183
Author: Ji-Wei 
Date:   Fri Sep 9 13:06:26 2016 +0800

Raise NotImplementedError instead of NotImplemented

NotImplementedError is the name of the exception
(https://docs.python.org/2/library/exceptions.html).
NotImplemented is the name of a constant
(https://docs.python.org/2/library/constants.html).
>>> raise NotImplemented()
Traceback (most recent call last):
  File "", line 1, in 
raise NotImplemented()
TypeError: 'NotImplementedType' object is not callable
>>> raise NotImplementedError()
Traceback (most recent call last):
  File "", line 1, in 
raise NotImplementedError()
NotImplementedError
This patch fix it.

Change-Id: I939eaa4b4b7c574f7a6447725e3a6ad5b128f1b7
Closes-Bug: #1339855


** Changed in: heat
   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/1339855

Title:
  Raise NotImplementedError instead of NotImplemented

Status in CloudCafe:
  Fix Committed
Status in Fuel for OpenStack:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystonemiddleware:
  In Progress
Status in neutron:
  Fix Released
Status in Solar:
  In Progress
Status in Warm:
  Invalid

Bug description:
  NotImplementedError is the name of the exception
  (https://docs.python.org/2/library/exceptions.html).

  NotImplemented is the name of a constant
  (https://docs.python.org/2/library/constants.html).

  It makes no sense to raise a constant. The exception should be raised
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloudcafe/+bug/1339855/+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 1619535] Re: DHCP: release exception log has no information information

[OpenStack Infra]

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

commit d9cc6deac61a519dc91221aa3a0e417dade86bf0
Author: Gary Kotton 
Date:   Thu Sep 1 01:05:04 2016 -0700

DHCP: enhance DHCP release log

Commit 2aa23de58f55f7b1001508326c5ac2627ba3a429 added in a warning
in the event that a release failed. This would have no information
that can help anyone deal with it.

Also updated the release note to include a recommendation to use
a version of dnsmasq including dhcp_release6 on an upgrade, so
that the warning we are logging here will not happen.

Closes-bug: #1619535
Change-Id: Ia73dcf5170aaf3f874a6abe83fefb8e85b6e67e3


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

Title:
  DHCP: release exception log has no information information

Status in neutron:
  Fix Released

Bug description:
  Commit 2aa23de58f55f7b1001508326c5ac2627ba3a429 added in a warning in
  the event that a release failed. This would have no information that
  can help anyone deal with it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1619535/+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 1624976] Re: neutron fails to start with vpnaas devstack plugin

[Armando Migliaccio]

** Changed in: neutron
Milestone: None => newton-rc2

** Tags added: newton-rc-potential

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

** Changed in: heat
   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/1624976

Title:
  neutron fails to start with vpnaas devstack plugin

Status in heat:
  Invalid
Status in neutron:
  Fix Released

Bug description:
  I can see the below error in the neutron logs.

  2016-09-18 23:45:48.183 4787 DEBUG neutron.db.servicetype_db [-] Adding 
provider configuration for service VPN add_provider_configuration 
/opt/stack/new/neutron/neutron/db/servicetype_db.py:52
  2016-09-18 23:45:48.183 4787 ERROR neutron.services.service_base [-] No 
providers specified for 'VPN' service, exiting

  http://logs.openstack.org/27/369827/4/check/gate-heat-dsvm-functional-
  orig-mysql-
  lbaasv2/7bdf656/logs/screen-q-svc.txt.gz#_2016-09-18_23_45_48_183

  Not sure what neutron/vpnaas change has resulted in this failure.

  As we're now using the vpnaas devstack plugin for jobs, we could
  probably stop setting the default service_provider in
  pre_test_hook.sh.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1624976/+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 1625305] Re: neutron-openvswitch-agent is crashing due to KeyError in _restore_local_vlan_map()

[Brian Haley]

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

Looks like a duplicate of
https://bugs.launchpad.net/neutron/+bug/1526974 - please see that bug
for reference and fixed sent to all the releases.

** This bug has been marked a duplicate of bug 1526974
   KeyError prevents openvswitch agent from starting

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

Title:
  neutron-openvswitch-agent is crashing due to KeyError in
  _restore_local_vlan_map()

Status in neutron:
  New

Bug description:
  Neutron openvswitch agent is unable to restart because vms with
  untagged/flat networks (tagged 3999) cause issue with
  _restore_local_vlan_map

  Loaded agent extensions: []
  2016-09-06 07:57:39.682 70085 CRITICAL neutron 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] KeyError: 3999
  2016-09-06 07:57:39.682 70085 ERROR neutron Traceback (most recent call last):
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/bin/neutron-openvswitch-agent", line 28, in 
  2016-09-06 07:57:39.682 70085 ERROR neutron sys.exit(main())
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 235, in __init__
  2016-09-06 07:57:39.682 70085 ERROR neutron self._restore_local_vlan_map()
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 356, in _restore_local_vlan_map
  2016-09-06 07:57:39.682 70085 ERROR neutron 
self.available_local_vlans.remove(local_vlan)
  2016-09-06 07:57:39.682 70085 ERROR neutron KeyError: 3999
  2016-09-06 07:57:39.682 70085 ERROR neutron
  2016-09-06 07:57:39.684 70085 INFO oslo_rootwrap.client 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] Stopping rootwrap daemon 
process with pid=70197

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625305/+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 1600394] Re: memcache raising "too many values to unpack"

[Steve Martinelli]

Marking this as fix-released, the related change went into Mitaka-3

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

** Changed in: keystone
 Assignee: (unassigned) => Brant Knudson (blk-u)

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

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

Title:
  memcache raising "too many values to unpack"

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Found the following error in the keystone logs of our Mitaka
  deployment.

  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi 
[req-b256411d-ba72-4076-b644-ef08a5400ab2 66725b90caea4963b1b4f91f90ab1dee 
ab149973d5b84459bd3ece44074ec2aa - default default] too many values to unpack
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi Traceback (most 
recent call last):
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 249, in 
__call__
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi result = 
method(context, **params)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line 156, in 
inner
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi 
context['subject_token_id']))
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/common/manager.py", line 124, in 
wrapped
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi __ret_val = 
__f(*args, **kwargs)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 208, in 
validate_token
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi token = 
self._validate_token(unique_id)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1053, in 
decorate
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi should_cache_fn)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 657, in 
get_or_create
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi async_creator) 
as value:
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 158, in 
__enter__
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi return 
self._enter()
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 98, in _enter
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi generated = 
self._enter_create(createdtime)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/core/dogpile.py", line 149, in 
_enter_create
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi created = 
self.creator()
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 625, in 
gen_value
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi created_value = 
creator()
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/dogpile/cache/region.py", line 1049, in 
creator
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi return fn(*arg, 
**kw)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/token/provider.py", line 298, in 
_validate_token
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi return 
self.driver.validate_non_persistent_token(token_id)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 
772, in validate_non_persistent_token
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi 
audit_info=audit_ids)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 
526, in get_token_data
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi project_id, 
trust)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/token/providers/common.py", line 
469, in _populate_service_catalog
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi user_id, 
project_id)
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi   File 
"/usr/lib/python2.7/dist-packages/keystone/common/manager.py", line 124, in 
wrapped
  2016-07-06 05:14:30.311 18314 ERROR keystone.common.wsgi __ret_val = 
__f(*args, **kwargs)
  2016-07-06 

[Yahoo-eng-team] [Bug 1625334] [NEW] Update port with subnet_id in fixed_ips allocates a new IP when existing one could be used.

[Carl Baldwin]

Public bug reported:

This issue has been seen twice causing this related bug [1]. What
happens is the DHCP agent updates the port using the subnet_id but not
the actual ip_address that the port already has. So, the server
allocates a new IP address and throws out the old one.

What it should do is recognize that there is already an IP address on
the port that satisfies the request and avoid the churn.

A previous attempt was made [1] to address this bug but was reverted
because it had a side effect [3].  Need a fix that addresses this issue
without the side-effect.

[1] https://bugs.launchpad.net/neutron/+bug/1622616/
[2] https://review.openstack.org/#/c/369051/
[3] https://bugs.launchpad.net/neutron/+bug/1623800

** Affects: neutron
 Importance: High
 Assignee: Carl Baldwin (carl-baldwin)
 Status: Confirmed


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

Title:
  Update port with subnet_id in fixed_ips allocates a new IP when
  existing one could be used.

Status in neutron:
  Confirmed

Bug description:
  This issue has been seen twice causing this related bug [1]. What
  happens is the DHCP agent updates the port using the subnet_id but not
  the actual ip_address that the port already has. So, the server
  allocates a new IP address and throws out the old one.

  What it should do is recognize that there is already an IP address on
  the port that satisfies the request and avoid the churn.

  A previous attempt was made [1] to address this bug but was reverted
  because it had a side effect [3].  Need a fix that addresses this
  issue without the side-effect.

  [1] https://bugs.launchpad.net/neutron/+bug/1622616/
  [2] https://review.openstack.org/#/c/369051/
  [3] https://bugs.launchpad.net/neutron/+bug/1623800

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625334/+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 1625333] [NEW] Booting VM with a Floating IP and pinging it via that takes a long time with errors in L3-Agent logs when using DVR

[Sindhur]

Public bug reported:

A Rally test to launch a VM, attach a floating IP and ping the VM via
the floating IP 40 times in case of legacy routers vs DVR routers was
done for comparison. Time taken to create network,subnet, launch VM,
attach floating IP etc. are similar in legacy and DVR cases but for the
VM to be pingable via the floating ip(after it has been booted with
floating ip) it takes a lot more time in some iterations with DVR. The
VM is ping ready(after booting and being given a floating ip) in less
than a second not counting time to boot or attach floating ip in case of
Legacy. However in case of DVR sometimes we see the VM being ping ready
in less than 1 second  whereas in some cases it takes around 250
seconds. Digging into the L3-agent logs on the computes we see this for
the instances that were taking the most time to be pingable via the
floating ip

https://paste.fedoraproject.org/431117/74312098/

Specifically we keep seeing errors like this:

2016-09-19 18:58:52.675 23696 DEBUG neutron.agent.linux.utils [-] Running 
command (rootwrap daemon): ['ip', 'netns', 'exec', 
'fip-790354c7-f286-4fd1-a4a1-ec9749c61fbf', 'arping', '-A', '-I', 
'fg-6b5906d0-d9', '-c', '3', '-w', '4.5', '10.16.30.99'] 
execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:99
2016-09-19 18:58:52.696 23696 ERROR neutron.agent.linux.utils [-] Exit code: 2; 
Stdin: ; Stdout: ; Stderr: bind: Cannot assign requested address

2016-09-19 18:58:52.697 23696 ERROR neutron.agent.linux.ip_lib [-]
Failed sending gratuitous ARP to 10.16.30.99 on fg-6b5906d0-d9 in
namespace fip-790354c7-f286-4fd1-a4a1-ec9749c61fbf


However, it is worth noting that bumping up the ping timeout to about 300 
seconds, all VMS are pingable but it takes 100-200x the time it was taking in 
legacy case.

This is the rally plugin used(create network, subnet, boot server with fip and 
ping):
https://github.com/openstack/browbeat/blob/master/rally/rally-plugins/netcreate-boot-ping/netcreate_nova-boot-fip-ping.py

The Rally results for legacy:
https://paste.fedoraproject.org/431120/43123471/

The Rally results for DVR:
https://paste.fedoraproject.org/431119/47431226/

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

Title:
  Booting VM with a Floating IP and pinging it via that takes a long
  time with errors in L3-Agent logs when using DVR

Status in neutron:
  New

Bug description:
  A Rally test to launch a VM, attach a floating IP and ping the VM via
  the floating IP 40 times in case of legacy routers vs DVR routers was
  done for comparison. Time taken to create network,subnet, launch VM,
  attach floating IP etc. are similar in legacy and DVR cases but for
  the VM to be pingable via the floating ip(after it has been booted
  with floating ip) it takes a lot more time in some iterations with
  DVR. The VM is ping ready(after booting and being given a floating ip)
  in less than a second not counting time to boot or attach floating ip
  in case of Legacy. However in case of DVR sometimes we see the VM
  being ping ready in less than 1 second  whereas in some cases it takes
  around 250 seconds. Digging into the L3-agent logs on the computes we
  see this for the instances that were taking the most time to be
  pingable via the floating ip

  https://paste.fedoraproject.org/431117/74312098/

  Specifically we keep seeing errors like this:

  2016-09-19 18:58:52.675 23696 DEBUG neutron.agent.linux.utils [-] Running 
command (rootwrap daemon): ['ip', 'netns', 'exec', 
'fip-790354c7-f286-4fd1-a4a1-ec9749c61fbf', 'arping', '-A', '-I', 
'fg-6b5906d0-d9', '-c', '3', '-w', '4.5', '10.16.30.99'] 
execute_rootwrap_daemon 
/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py:99
  2016-09-19 18:58:52.696 23696 ERROR neutron.agent.linux.utils [-] Exit code: 
2; Stdin: ; Stdout: ; Stderr: bind: Cannot assign requested address

  2016-09-19 18:58:52.697 23696 ERROR neutron.agent.linux.ip_lib [-]
  Failed sending gratuitous ARP to 10.16.30.99 on fg-6b5906d0-d9 in
  namespace fip-790354c7-f286-4fd1-a4a1-ec9749c61fbf

  
  However, it is worth noting that bumping up the ping timeout to about 300 
seconds, all VMS are pingable but it takes 100-200x the time it was taking in 
legacy case.

  This is the rally plugin used(create network, subnet, boot server with fip 
and ping):
  
https://github.com/openstack/browbeat/blob/master/rally/rally-plugins/netcreate-boot-ping/netcreate_nova-boot-fip-ping.py

  The Rally results for legacy:
  https://paste.fedoraproject.org/431120/43123471/

  The Rally results for DVR:
  https://paste.fedoraproject.org/431119/47431226/

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

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

[Yahoo-eng-team] [Bug 1622644] Re: OVS agent ryu/native implementation breaks non-OF1.3 uses

[OpenStack Infra]

Reviewed:  https://review.openstack.org/372272
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=039673c2a412282eba9c26f9ff4ac148748ebfb4
Submitter: Jenkins
Branch:master

commit 039673c2a412282eba9c26f9ff4ac148748ebfb4
Author: Thomas Morin 
Date:   Mon Sep 19 09:39:57 2016 +0200

OVS agent: configure both OF10 and OF13

This change avoids issues where a piece of code restricts
a bridge to OF13 while there is code still needing OF10, and
vice-versa, by configuring bridge to both versions.

This is aimed to be a less complex and easier to merge fix than
Id5ac7e6431c97fc70d8404b16f89533b6f270eee.

Change-Id: I4475865c4f83cb9f3e12c709af752bc490692ca3
Closes-Bug: 1622644


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

Title:
  OVS agent ryu/native implementation breaks non-OF1.3 uses

Status in networking-bgpvpn:
  Confirmed
Status in BaGPipe:
  New
Status in neutron:
  Fix Released

Bug description:
  The ryu-based OVS agent variant forces the bridge Openflow version to 1.3 
only [1], which breaks a few things:
  - troubleshooting tools relying on ovs-ofctl, unless they specify "-O 
Openflow13", will break:
version negotiation failed (we support version 0x01, peer supports version 
0x04)
ovs-ofctl: br-tun: failed to connect to socket (Broken pipe)

  - calling add_flow on an OVSCookieBridge derived from a bridge that is
  an native.ovs_bridge.OVSAgentBridge, will fail with the same error,
  because add_flow will call ovs-ofctl without specifying "-O
  Openflow13"  (this issue is currently hitting networking-bgpvpn: [2])

  It seems like a possible fix would be to not restrict the set of
  Openflow versions supported by the bridge to Openflow13, but to just
  *add* Openflow13 to the set of supported versions.

  [1] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/ovs_bridge.py#L78
  [2] 
https://github.com/openstack/networking-bagpipe/blob/master/networking_bagpipe/agent/bagpipe_bgp_agent.py#L512

To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1622644/+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 1625325] [NEW] OVS port momentary lapse of reason

[Armando Migliaccio]

Public bug reported:

A phenomenon where OVS ports appear, disappear and show up again has
been experienced lately (e.g. [1]). This seems to be associated to
traces like below, where two separate interfaces get associated to the
same ofport right about the same time:

2016-09-19T17:34:48.065Z|00247|bridge|INFO|bridge br-int: added interface 
qvo9d9ab7b1-59 on port 89
2016-09-19T17:34:48.077Z|00248|bridge|INFO|bridge br-int: added interface 
tapc9e6d02e-2c on port 89

We need to figure out what's causing it, and fix it for good.

[1] http://logs.openstack.org/40/367340/8/check/gate-grenade-dsvm-
neutron-ubuntu-trusty/c809d17/logs/openvswitch/ovs-vswitchd.txt.gz

** Affects: neutron
 Importance: High
 Status: New


** Tags: newton-rc-potential

** Changed in: neutron
Milestone: None => newton-rc2

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

** Tags added: newton-rc-potential

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

Title:
  OVS port momentary lapse of reason

Status in neutron:
  New

Bug description:
  A phenomenon where OVS ports appear, disappear and show up again has
  been experienced lately (e.g. [1]). This seems to be associated to
  traces like below, where two separate interfaces get associated to the
  same ofport right about the same time:

  2016-09-19T17:34:48.065Z|00247|bridge|INFO|bridge br-int: added interface 
qvo9d9ab7b1-59 on port 89
  2016-09-19T17:34:48.077Z|00248|bridge|INFO|bridge br-int: added interface 
tapc9e6d02e-2c on port 89

  We need to figure out what's causing it, and fix it for good.

  [1] http://logs.openstack.org/40/367340/8/check/gate-grenade-dsvm-
  neutron-ubuntu-trusty/c809d17/logs/openvswitch/ovs-vswitchd.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625325/+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 1625321] [NEW] Hitting "Authentication required" on migration when building network info model

[Ludovic Beliveau]

Public bug reported:

Description
===

I observed this issue a few times, mainly while doing stress testing of
cold migration.

Neutron returns this error (see stack trace):
Unauthorized: Authentication required

Steps to reproduce
==

1) Boot multiple vms (5-6) 
2) Stress test cold migration: migrate all vms, once confirmed, redo again, 
over and over 

Actual result
=

2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] Traceback (most recent call last): 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 4271, in 
finish_resize 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] disk_info, image_meta) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 4210, in 
_finish_resize 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] network_info = 
self.network_api.get_instance_nw_info(context, instance) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/network/base_api.py", line 253, in 
get_instance_nw_info 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] result = 
self._get_instance_nw_info(context, instance, **kwargs) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 994, in 
_get_instance_nw_info 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] preexisting_port_ids) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 1787, in 
_build_network_info_model 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] context, instance, networks, port_ids) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 1017, in 
_gather_port_ids_and_networks 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] net_ids) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/nova/network/neutronv2/api.py", line 207, in 
_get_available_networks 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] nets = 
neutron.list_networks(**search_opts).get('networks', []) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 105, in 
with_params 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] ret = self.function(instance, *args, 
**kwargs) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 730, in 
list_networks 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] **_params) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 384, in 
list 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] for r in self._pagination(collection, 
path, **params): 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 399, in 
_pagination 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] res = self.get(path, params=params) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 
"/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 369, in 
get 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] headers=headers, params=params) 
2016-09-02 13:53:14.887 61968 ERROR nova.compute.manager [instance: 
da6e6dd9-6042-478f-9886-c88d332eb4e3] File 

[Yahoo-eng-team] [Bug 1625322] [NEW] nova newton specs docs link to sections of live-migrate-rescued-instances spec

[Matt Riedemann]

Public bug reported:

If you look at the approved newton specs:

https://specs.openstack.org/openstack/nova-specs/specs/newton/index.html

You'll see some called "Problem description" and "Proposed change".
These are linked from:

https://specs.openstack.org/openstack/nova-specs/specs/newton/approved
/live-migrate-rescued-instances.html

Looks like something got messed up with the formatting in that spec
which bleeds into the listing of the approved specs.

** Affects: nova
 Importance: Undecided
 Assignee: Matt Riedemann (mriedem)
 Status: In Progress

** Changed in: nova
 Assignee: (unassigned) => Matt Riedemann (mriedem)

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

Title:
  nova newton specs docs link to sections of live-migrate-rescued-
  instances spec

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  If you look at the approved newton specs:

  https://specs.openstack.org/openstack/nova-
  specs/specs/newton/index.html

  You'll see some called "Problem description" and "Proposed change".
  These are linked from:

  https://specs.openstack.org/openstack/nova-specs/specs/newton/approved
  /live-migrate-rescued-instances.html

  Looks like something got messed up with the formatting in that spec
  which bleeds into the listing of the approved specs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1625322/+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 1625310] [NEW] Minor UI issues on instance details overview tab

[Ying Zuo]

Public bug reported:

There are two minor UI issues on the instance details overview tab.
- no space between the navbar and the first field (Name).
- misalignment in the security groups section.

** Affects: horizon
 Importance: Undecided
 Assignee: Ying Zuo (yingzuo)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Ying Zuo (yingzuo)

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

Title:
  Minor UI issues on instance details overview tab

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  There are two minor UI issues on the instance details overview tab.
  - no space between the navbar and the first field (Name).
  - misalignment in the security groups section.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1625310/+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 1625305] [NEW] neutron-openvswitch-agent is crashing due to KeyError in _restore_local_vlan_map()

[Esha Seth]

Public bug reported:

Neutron openvswitch agent is unable to restart because vms with
untagged/flat networks (tagged 3999) cause issue with
_restore_local_vlan_map

Loaded agent extensions: []
2016-09-06 07:57:39.682 70085 CRITICAL neutron 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] KeyError: 3999
2016-09-06 07:57:39.682 70085 ERROR neutron Traceback (most recent call last):
2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/bin/neutron-openvswitch-agent", line 28, in 
2016-09-06 07:57:39.682 70085 ERROR neutron sys.exit(main())
2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 235, in __init__
2016-09-06 07:57:39.682 70085 ERROR neutron self._restore_local_vlan_map()
2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 356, in _restore_local_vlan_map
2016-09-06 07:57:39.682 70085 ERROR neutron 
self.available_local_vlans.remove(local_vlan)
2016-09-06 07:57:39.682 70085 ERROR neutron KeyError: 3999
2016-09-06 07:57:39.682 70085 ERROR neutron
2016-09-06 07:57:39.684 70085 INFO oslo_rootwrap.client 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] Stopping rootwrap daemon 
process with pid=70197

** Affects: neutron
 Importance: Undecided
 Status: New

** Summary changed:

- neutron-openvswitch-agent is crashing due to KeyError in 
._restore_local_vlan_map()
+ neutron-openvswitch-agent is crashing due to KeyError in 
_restore_local_vlan_map()

** Description changed:

- Neutron openvswitch agent is unable to restart because vms with untagged
- networks (tagged 3999) cause issue with _restore_local_vlan_map
+ Neutron openvswitch agent is unable to restart because vms with
+ untagged/flat networks (tagged 3999) cause issue with
+ _restore_local_vlan_map
  
  Loaded agent extensions: []
  2016-09-06 07:57:39.682 70085 CRITICAL neutron 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] KeyError: 3999
  2016-09-06 07:57:39.682 70085 ERROR neutron Traceback (most recent call last):
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/bin/neutron-openvswitch-agent", line 28, in 
  2016-09-06 07:57:39.682 70085 ERROR neutron sys.exit(main())
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 235, in __init__
  2016-09-06 07:57:39.682 70085 ERROR neutron self._restore_local_vlan_map()
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 356, in _restore_local_vlan_map
  2016-09-06 07:57:39.682 70085 ERROR neutron 
self.available_local_vlans.remove(local_vlan)
  2016-09-06 07:57:39.682 70085 ERROR neutron KeyError: 3999
  2016-09-06 07:57:39.682 70085 ERROR neutron
  2016-09-06 07:57:39.684 70085 INFO oslo_rootwrap.client 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] Stopping rootwrap daemon 
process with pid=70197

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

Title:
  neutron-openvswitch-agent is crashing due to KeyError in
  _restore_local_vlan_map()

Status in neutron:
  New

Bug description:
  Neutron openvswitch agent is unable to restart because vms with
  untagged/flat networks (tagged 3999) cause issue with
  _restore_local_vlan_map

  Loaded agent extensions: []
  2016-09-06 07:57:39.682 70085 CRITICAL neutron 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] KeyError: 3999
  2016-09-06 07:57:39.682 70085 ERROR neutron Traceback (most recent call last):
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/bin/neutron-openvswitch-agent", line 28, in 
  2016-09-06 07:57:39.682 70085 ERROR neutron sys.exit(main())
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 235, in __init__
  2016-09-06 07:57:39.682 70085 ERROR neutron self._restore_local_vlan_map()
  2016-09-06 07:57:39.682 70085 ERROR neutron   File 
"/usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py",
 line 356, in _restore_local_vlan_map
  2016-09-06 07:57:39.682 70085 ERROR neutron 
self.available_local_vlans.remove(local_vlan)
  2016-09-06 07:57:39.682 70085 ERROR neutron KeyError: 3999
  2016-09-06 07:57:39.682 70085 ERROR neutron
  2016-09-06 07:57:39.684 70085 INFO oslo_rootwrap.client 
[req-ef8eea4f-c1ed-47a0-8318-eb5473b7c667 - - - - -] Stopping rootwrap daemon 
process with pid=70197

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

-- 
Mailing list: 

[Yahoo-eng-team] [Bug 1588888] Re: Set migration status to 'error' on live-migration failure

[OpenStack Infra]

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

commit a7c0a84a1e50a9f83acd27ece64f393ac454cf7f
Author: Anusha Unnam 
Date:   Mon Aug 29 21:09:48 2016 +

Add a new release note

Add a new reno note to specify that migration status is changed
from 'failed' to 'error' on live-migration failure. That was landed
as change I7a0c5a32349b0d3604802d22e83a3c2dab4b1370

Change-Id: I4e1693fa52bcb33b8770ec59640890abd2b911c8
Closes-bug: #158


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

Title:
  Set migration status to 'error' on live-migration failure

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  https://review.openstack.org/215483
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/nova" 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 d61e15818c1d108275b3286a6665fa3e6540e7e7
  Author: Rajesh Tailor 
  Date:   Thu Jul 2 03:22:01 2015 -0700

  Set migration status to 'error' on live-migration failure
  
  (A) In resize, confirm-resize and revert-resize operation, migration 
status
  is marked as 'error' in case of failure for respective operation.
  
  Migration object support is added in live-migration operation, which mark
  migration status to 'failed' if live-migration operation fails in-between.
  
  To make live-migration consistent with resize, confirm-resize and revert-
  resize operation, it needs to mark migration status to 'error' instead of
  'failed' in case of failure.
  
  (B) Apart from consistency, proposed change fixes issue (similar to [1])
  which might occur on live-migration failure as follows:
  If live-migration fails (which sets migration status to 'failed') after
  copying instance files from source to dest node and then user request for
  instance deletion. In that case, delete api will only remove instance
  files from instance.host and not from other host (which could be either
  source or dest node but not instance.host). Since instance is already
  deleted, instance files will remain on other host (not instance.host).
  
  Set migration status to 'error' on live-migration failure, so that
  periodic task _cleanup_incomplete_migrations [2] will remove orphaned
  instance files from compute nodes after instance deletion in above case.
  
  [1] https://bugs.launchpad.net/nova/+bug/1392527
  [2] https://review.openstack.org/#/c/219299/
  
  DocImpact: On live-migration failure, set migration status to 'error'
  instead of 'failed'.
  
  Change-Id: I7a0c5a32349b0d3604802d22e83a3c2dab4b1370
  Closes-Bug: 1470420

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/158/+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 1612913] Re: The description of "Inject guest networking config" in support-matrix is misleading

[OpenStack Infra]

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

commit 4ca189acd4c62f3921b5173d0da586abee0d5946
Author: xhzhf 
Date:   Sat Aug 13 15:02:02 2016 +0800

modify description of "Inject guest networking config"

The description of "Inject guest networking config" in
support-matrix is misleading. Correct it.
In fact, If we config static ip,
guest os can not access metadata service to get ip config.
Closes-Bug: #1612913

Change-Id: I1892e5273a77516dd8e1525e6064fb95fa65e4d3


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

Title:
  The description of "Inject guest networking config" in support-matrix
  is misleading

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===
  
link:http://docs.openstack.org/developer/nova/support-matrix.html#guest_setup_inject_networking

  The problem of configuring networking is better solved by DHCP or by
  obtaining static config via the metadata service or config drive.
  Therefore this operation is considered optional to support.

  In fact, If we config static ip, guest os can not access metadata service to 
get ip config.
  Because it has not ip address and can not access outer service.So changing 
description as below

  The problem of configuring networking is better solved by DHCP or by
  obtaining static config via config drive. Therefore this operation is
  considered optional to support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1612913/+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 1624221] Re: RequiredOptError: value required for option lock_path in group [DEFAULT]

[venkatamahesh]

** No longer affects: neutron

** Tags added: low-hanging-fruit neutron

** Changed in: openstack-manuals
   Importance: Undecided => Medium

** Changed in: openstack-manuals
   Status: New => Triaged

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

Title:
  RequiredOptError: value required for option lock_path in group
  [DEFAULT]

Status in openstack-manuals:
  Triaged

Bug description:
  2016-09-16 10:56:49.490 4505 ERROR oslo_messaging.rpc.server   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 
140, in _get_lock_path
  2016-09-16 10:56:49.490 4505 ERROR oslo_messaging.rpc.server raise 
cfg.RequiredOptError('lock_path')
  2016-09-16 10:56:49.490 4505 ERROR oslo_messaging.rpc.server 
RequiredOptError: value required for option lock_path in group [DEFAULT]

  
  After adding the option in neutron.conf the problem is rectified. So it 
should be updated in install-guide

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1624221/+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 1599787] Re: The documentation of disk=0 in flavor is misleading

[OpenStack Infra]

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

commit 9d08e805a8889d84ff1076da2373c37057670f23
Author: Balazs Gibizer 
Date:   Thu Jul 7 16:28:10 2016 +0200

doc: fix disk=0 use case in flavor doc

The 0 value of the disk parameter of the flavor is only meaningfull
if the instance is booted from volume as in any other case the
instance will use local disk and the scheduler will not be
able to select the hosts based on the real image size as that
information is not available for the scheduler.

Change-Id: I6b3ba2fb323341071eae6b9e9f54ef833fdbaff7
Closes-Bug: #1599787
DocImpact: admin guide


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

Title:
  The documentation of disk=0 in flavor is misleading

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===

  Current nova api documentation states the following about disk=0 in
  flavor:

  The size of the root disk that will be created in GiB. If 0 the
  root disk will be set to exactly the size of the image used to
  deploy the instance. [1]

  However scheduler does not check the actual image size during select
  destintation and also resource tracker does not calculate the used
  space properly.

  
  [1] 
https://github.com/openstack/nova/blob/master/api-ref/source/parameters.yaml#L1548-L1555
 

  
  Steps to reproduce
  ==
  1. Create a sizeable image. e.g. 8GB
  +--+--+
  | Property | Value|
  +--+--+
  | checksum | bde0b00c072a8b5ab28ac58a3b8ea6ed |
  | container_format | bare |
  | created_at   | 2016-07-07T09:25:33Z |
  | disk_format  | qcow2|
  | id   | ea14a784-252a-4193-9129-a311f64c01f4 |
  | min_disk | 0|
  | min_ram  | 0|
  | name | my_image |
  | owner| 0878b2a9a9fa4c538931df5d67708b51 |
  | protected| False|
  | size | 8591507456   |
  | status   | active   |
  | tags | []   |
  | updated_at   | 2016-07-07T09:29:35Z |
  | virtual_size | None |
  | visibility   | private  |
  +--+--+

  2. Check the current host-describe output to see the available and used space
  vagrant@controller:~$ nova host-describe controller
  ++--+-+---+-+
  | HOST   | PROJECT  | cpu | memory_mb | disk_gb |
  ++--+-+---+-+
  | controller | (total)  | 8   | 7794  | 39  |
  | controller | (used_now)   | 0   | 512   | 0   |
  | controller | (used_max)   | 0   | 64| 0   |
  ++--+-+---+-+

  3. boot a vm with a flavor disk=0
  vagrant@controller:/opt/stack/nova/nova/scheduler/filters$ nova flavor-list
  
++---+---+--+---+--+---+-+---+
  | ID | Name  | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor 
| Is_Public |
  
++---+---+--+---+--+---+-+---+
  | 1  | m1.tiny   | 512   | 1| 0 |  | 1 | 1.0 
| True  |
  | 2  | m1.small  | 2048  | 20   | 0 |  | 1 | 1.0 
| True  |
  | 3  | m1.medium | 4096  | 40   | 0 |  | 2 | 1.0 
| True  |
  | 4  | m1.large  | 8192  | 80   | 0 |  | 4 | 1.0 
| True  |
  | 42 | m1.nano   | 64| 0| 0 |  | 1 | 1.0 
| True  |
  | 5  | m1.xlarge | 16384 | 160  | 0 |  | 8 | 1.0 
| True  |
  | 84 | m1.micro  | 128   | 0| 0 |  | 1 | 1.0 
| True  |
  | c1 | cirros256 | 256   | 0| 0 |  | 1 | 1.0 
| True  |
  | d1 | ds512M| 512   | 5| 0 |  | 1 | 1.0 
| True  |
  | d2 | 

[Yahoo-eng-team] [Bug 1625260] [NEW] doc: fix disk=0 use case in flavor doc

[OpenStack Infra]

Public bug reported:

https://review.openstack.org/339034
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/nova" 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 9d08e805a8889d84ff1076da2373c37057670f23
Author: Balazs Gibizer 
Date:   Thu Jul 7 16:28:10 2016 +0200

doc: fix disk=0 use case in flavor doc

The 0 value of the disk parameter of the flavor is only meaningfull
if the instance is booted from volume as in any other case the
instance will use local disk and the scheduler will not be
able to select the hosts based on the real image size as that
information is not available for the scheduler.

Change-Id: I6b3ba2fb323341071eae6b9e9f54ef833fdbaff7
Closes-Bug: #1599787
DocImpact: admin guide

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: doc nova

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

Title:
  doc: fix disk=0 use case in flavor doc

Status in OpenStack Compute (nova):
  New

Bug description:
  https://review.openstack.org/339034
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/nova" 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 9d08e805a8889d84ff1076da2373c37057670f23
  Author: Balazs Gibizer 
  Date:   Thu Jul 7 16:28:10 2016 +0200

  doc: fix disk=0 use case in flavor doc
  
  The 0 value of the disk parameter of the flavor is only meaningfull
  if the instance is booted from volume as in any other case the
  instance will use local disk and the scheduler will not be
  able to select the hosts based on the real image size as that
  information is not available for the scheduler.
  
  Change-Id: I6b3ba2fb323341071eae6b9e9f54ef833fdbaff7
  Closes-Bug: #1599787
  DocImpact: admin guide

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1625260/+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 1625253] [NEW] Collection of test artifacts in integration tests is broken after transition to xenial

[Timur Sufiev]

Public bug reported:

The destination path for gathering artifacts in
tools/gate/integration/post_test_hook.sh was harcoded to a specific
workspace dir name (which was derived in turn from job name). When the
job name changed due to transition trusty->xenial, artifacts were no
longer collected. We should not rely on any particular workspace name as
it's very fragile. Will use relative paths instead.

** Affects: horizon
 Importance: High
 Assignee: Timur Sufiev (tsufiev-x)
 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/1625253

Title:
  Collection of test artifacts in integration tests is broken after
  transition to xenial

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The destination path for gathering artifacts in
  tools/gate/integration/post_test_hook.sh was harcoded to a specific
  workspace dir name (which was derived in turn from job name). When the
  job name changed due to transition trusty->xenial, artifacts were no
  longer collected. We should not rely on any particular workspace name
  as it's very fragile. Will use relative paths instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1625253/+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 1625252] [NEW] Hide Horizon elements that don't apply to baremetal only environment

[Tyr Johanson]

Public bug reported:

When running in a baremetal environment, some "core" panels or columns
in Horizon don't apply, or are misleading.

For example:
* Horizon refers to CPUs as vCPUs
* Floating IPs are not currently supported by Ironic
* Security Groups are not currently supported by Ironic

Provide a way for Horizon, or for Horizon deployers to indicate that the
current Keystone region is baremetal only, and if so, customize the
visible panels, table columns, actions and potentially labels to be
applicable to a physical, baremetal-only environment.

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

Title:
  Hide Horizon elements that don't apply to baremetal only environment

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When running in a baremetal environment, some "core" panels or columns
  in Horizon don't apply, or are misleading.

  For example:
  * Horizon refers to CPUs as vCPUs
  * Floating IPs are not currently supported by Ironic
  * Security Groups are not currently supported by Ironic

  Provide a way for Horizon, or for Horizon deployers to indicate that
  the current Keystone region is baremetal only, and if so, customize
  the visible panels, table columns, actions and potentially labels to
  be applicable to a physical, baremetal-only environment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1625252/+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 1615467] Re: [api-ref]: Computer API show version refer wrong link

[OpenStack Infra]

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

commit 47275d08c62dde225db2ca3aa33e4bcac51b2f61
Author: Ha Van Tu 
Date:   Tue Aug 23 09:05:41 2016 +0700

Fix link reference in Nova API version

This patch replaces link reference in "API Guide/ Links
and Reference" in [1] from [2] to [3].
[2] leads to a wrong link (error 404 not found).
[1] http://developer.openstack.org/api-ref/compute/
[2] http://docs.openstack.org/developer/nova/v2/
links_and_references.html
[3] http://developer.openstack.org/api-guide/compute/
links_and_references.html

Closes-Bug: #1615467
Change-Id: I10a0520cb0233114c30a6e34ef927ee74bf3cf4c


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

Title:
  [api-ref]: Computer API show version refer wrong link

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The link reference in [1] Computer API show version is wrong.
  The "API Guide / Links and References" lead to [2] is a wrong link (error 404 
not found).
  It should be changed to [3].

  [1] 
http://developer.openstack.org/api-ref/compute/#show-details-of-specific-api-version
  [2] http://docs.openstack.org/developer/nova/v2/links_and_references.html
  [3] http://developer.openstack.org/api-guide/compute/links_and_references.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1615467/+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 1625230] [NEW] Role Assignment Incorrectly Reports Inheritance when --name is Used

[Sean Carlisle]

Public bug reported:

When retrieving role assignments via the openstack client, passing the
--name flag will cause Keystone to not return the value of inherited, so
openstack client always reports false.

My test environment is an OSA AIO using OSA 13.1.3, which is using Keystone 
commit 87d67946e75db2ec2a6af72447211ca1ee291940.
 
Steps to reproduce:
* assign a role to a user on a domain and pass --inherited, so the role will be 
inherited to the domain's projects
* run "openstack role assignment list --user  --name"

Example output with debug request response without --name:

:~# openstack --debug role assignment list --user 
14bc7c6869374b33bd5125f6c61d44b9
...
REQ: curl -g -i -X GET 
http://172.29.236.100:35357/v3/role_assignments?user.id=14bc7c6869374b33bd5125f6c61d44b9
 -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}65c4fb6823ecccbf9441b041c2764e9eb2424fca"
"GET /v3/role_assignments?user.id=14bc7c6869374b33bd5125f6c61d44b9 HTTP/1.1" 
200 586
RESP: [200] Content-Length: 586 Vary: X-Auth-Token Server: Apache Date: Mon, 19 
Sep 2016 15:07:23 GMT Content-Type: application/json x-openstack-request-id: 
req-0ace9479-bb24-423c-8269-83da8a57ff6f
RESP BODY: {"role_assignments": [{"scope": {"domain": {"id": 
"c000bbc3b52f41fe99e9f560666b36f1"}, "OS-INHERIT:inherited_to": "projects"}, 
"role": {"id": "9fe2ff9ee4384b1894a90878d3e92bab"}, "user": {"id": 
"14bc7c6869374b33bd5125f6c61d44b9"}, "links": {"assignment": 
"http://172.29.236.100:35357/v3/OS-INHERIT/domains/c000bbc3b52f41fe99e9f560666b36f1/users/14bc7c6869374b33bd5125f6c61d44b9/roles/9fe2ff9ee4384b1894a90878d3e92bab/inherited_to_projects"}}],
 "links": {"self": 
"http://172.29.236.100:35357/v3/role_assignments?user.id=14bc7c6869374b33bd5125f6c61d44b9;,
 "previous": null, "next": null}}

+--+--+---+-+--+---+
| Role | User | Group | 
Project | Domain   | Inherited |
+--+--+---+-+--+---+
| 9fe2ff9ee4384b1894a90878d3e92bab | 14bc7c6869374b33bd5125f6c61d44b9 |   | 
| c000bbc3b52f41fe99e9f560666b36f1 | True  |
+--+--+---+-+--+---+

Example output with debug request response with --name:

:~# openstack --debug role assignment list --user 
14bc7c6869374b33bd5125f6c61d44b9 --name
...
REQ: curl -g -i -X GET 
http://172.29.236.100:35357/v3/role_assignments?user.id=14bc7c6869374b33bd5125f6c61d44b9_names=True
 -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}1ee295769134d215d26474bfc59704338ddbfb52"
"GET 
/v3/role_assignments?user.id=14bc7c6869374b33bd5125f6c61d44b9_names=True
 HTTP/1.1" 200 681
RESP: [200] Content-Length: 681 Vary: X-Auth-Token Server: Apache Date: Mon, 19 
Sep 2016 15:08:52 GMT Content-Type: application/json x-openstack-request-id: 
req-70f3eb92-0cdd-4a02-866c-e8d1b2cbd113
RESP BODY: {"role_assignments": [{"scope": {"domain": {"id": 
"c000bbc3b52f41fe99e9f560666b36f1", "name": "mytestdomain"}}, "role": {"id": 
"9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}, "user": {"domain": 
{"id": "c000bbc3b52f41fe99e9f560666b36f1", "name": "mytestdomain"}, "id": 
"14bc7c6869374b33bd5125f6c61d44b9", "name": "testdomainuser"}, "links": 
{"assignment": 
"http://172.29.236.100:35357/v3/domains/c000bbc3b52f41fe99e9f560666b36f1/users/14bc7c6869374b33bd5125f6c61d44b9/roles/9fe2ff9ee4384b1894a90878d3e92bab"}}],
 "links": {"self": 
"http://172.29.236.100:35357/v3/role_assignments?user.id=14bc7c6869374b33bd5125f6c61d44b9_names=True;,
 "previous": null, "next": null}}

+--+-+---+-+--+---+
| Role | User| Group | Project | Domain   | 
Inherited |
+--+-+---+-+--+---+
| _member_ | testdomainuser@mytestdomain |   | | mytestdomain | 
False |
+--+-+---+-+--+---+

Thanks,

Sean

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

Title:
  Role Assignment Incorrectly Reports Inheritance when --name is Used

Status in OpenStack Identity (keystone):
  New

Bug description:
  When retrieving role assignments via the openstack client, passing the
  --name flag will cause Keystone to not return the value of inherited,
  so openstack client always reports false.

  My test environment is an OSA AIO using 

[Yahoo-eng-team] [Bug 1624973] Re: Not possible to allow non "admin" user to change owner on image

[Nikhil Komawar]

I think the use case is reasonable. I would prefer a spec-lite for this
change, it's a feature more than a bug.


You can file one here:
https://github.com/openstack/glance-specs/blob/master/specs/ocata/approved/glance/lite-specs.rst

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

** Changed in: glance
   Importance: Undecided => Wishlist

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

Title:
  Not possible to allow non "admin" user to change owner on image

Status in Glance:
  Opinion

Bug description:
  I want to allow a special role to update the owner attribute of an
  image.

  It looks as if this action is hard coded to only allow context
  "is_admin" to to this operation.

  This should be configurable via policy

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1624973/+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 1625221] [NEW] Fullstack looses test workers if eventlet's Timeout is raised

[Ihar Hrachyshka]

Public bug reported:

Seems like unittest module is not capable to catch the exception,
instead killing the whole worker. We need to catch the exception
ourselves, if a test case raises it for us. Otherwise we loose some test
cases (all of those that were scheduled for the dead worker to execute).

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


** Tags: fullstack

** Tags added: fullstack

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

Title:
  Fullstack looses test workers if eventlet's Timeout is raised

Status in neutron:
  In Progress

Bug description:
  Seems like unittest module is not capable to catch the exception,
  instead killing the whole worker. We need to catch the exception
  ourselves, if a test case raises it for us. Otherwise we loose some
  test cases (all of those that were scheduled for the dead worker to
  execute).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625221/+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 1625220] [NEW] get_function_by_ifname does not return true for physical function

[edan david]

Public bug reported:

Due to a missing slash ('\') an incorrect path was passed to read the
number of VFs and determine if the device is a PF or not.

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

Title:
  get_function_by_ifname does not return true for physical function

Status in OpenStack Compute (nova):
  New

Bug description:
  Due to a missing slash ('\') an incorrect path was passed to read the
  number of VFs and determine if the device is a PF or not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1625220/+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 1621891] Re: Extra characters in create server responses description

[OpenStack Infra]

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

commit 2f202bb3e30624c96bb488ca1bcad1cf19d46172
Author: ianeta hutchinson 
Date:   Fri Sep 9 19:15:19 2016 +

Updates URL and removes trailing characters

Removes trailing '`_' and updates URL to be consistent with rest of
document by providing a full sentence.

Closes Bug: 1621891

Change-Id: Iea47703b624db6de0912abe7ad42a018596d951e


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

Title:
  Extra characters in create server responses description

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  In the description of addresses property in the response in Create
  Server in api reference of Nova [1] there is an extra "`_" in the
  text.


  [1]: http://developer.openstack.org/api-ref/compute/?expanded=create-
  server-detail

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1621891/+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 1618572] Re: apt-key add fails in overlayfs

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.4.0-38.57

---
linux (4.4.0-38.57) xenial; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
- LP: #1620658

  * CIFS client: access problems after updating to kernel 4.4.0-29-generic
(LP: #1612135)
- Revert "UBUNTU: SAUCE: (namespace) Bypass sget() capability check for nfs"
- fs: Call d_automount with the filesystems creds

  * apt-key add fails in overlayfs (LP: #1618572)
- SAUCE: overlayfs: fix regression in whiteout detection

linux (4.4.0-37.56) xenial; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
- LP: #1618040

  * [Feature] Instruction decoder support for new SKX instructions- AVX512
(LP: #1591655)
- x86/insn: perf tools: Fix vcvtph2ps instruction decoding
- x86/insn: Add AVX-512 support to the instruction decoder
- perf tools: Add AVX-512 support to the instruction decoder used by Intel 
PT
- perf tools: Add AVX-512 instructions to the new instructions test

  * [Ubuntu 16.04] FCoE Lun not visible in OS with inbox driver - Issue with
ioremap() call on 32bit kernel (LP: #1608652)
- lpfc: Correct issue with ioremap() call on 32bit kernel

  * [Feature] turbostat support for Skylake-SP server (LP: #1591802)
- tools/power turbostat: decode more CPUID fields
- tools/power turbostat: CPUID(0x16) leaf shows base, max, and bus frequency
- tools/power turbostat: decode HWP registers
- tools/power turbostat: Decode MSR_MISC_PWR_MGMT
- tools/power turbostat: allow sub-sec intervals
- tools/power turbostat: Intel Xeon x200: fix erroneous bclk value
- tools/power turbostat: Intel Xeon x200: fix turbo-ratio decoding
- tools/power turbostat: re-name "%Busy" field to "Busy%"
- tools/power turbostat: add --out option for saving output in a file
- tools/power turbostat: fix compiler warnings
- tools/power turbostat: make fewer systems calls
- tools/power turbostat: show IRQs per CPU
- tools/power turbostat: show GFXMHz
- tools/power turbostat: show GFX%rc6
- tools/power turbostat: detect and work around syscall jitter
- tools/power turbostat: indicate SMX and SGX support
- tools/power turbostat: call __cpuid() instead of __get_cpuid()
- tools/power turbostat: correct output for MSR_NHM_SNB_PKG_CST_CFG_CTL dump
- tools/power turbostat: bugfix: TDP MSRs print bits fixing
- tools/power turbostat: SGX state should print only if --debug
- tools/power turbostat: print IRTL MSRs
- tools/power turbostat: initial BXT support
- tools/power turbostat: decode BXT TSC frequency via CPUID
- tools/power turbostat: initial SKX support

  * [BYT] display hotplug doesn't work on console (LP: #1616894)
- drm/i915/vlv: Make intel_crt_reset() per-encoder
- drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
- drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
- drm/i915: Enable polling when we don't have hpd

  * [Feature]intel_idle enabling on Broxton-P (LP: #1520446)
- intel_idle: add BXT support

  * [Feature] EDAC: Update driver for SKX-SP (LP: #1591815)
- [Config] CONFIG_EDAC_SKX=m
- EDAC, skx_edac: Add EDAC driver for Skylake

  * [Feature] KBL: Sandy Peak(3168) WiFi/BT support (LP: #1591648)
- Bluetooth: Add support for Intel Bluetooth device 3168 [8087:0aa7]

  * MacBookPro11,4 fails to poweroff or suspend (LP: #1587714)
- SAUCE: PCI: Workaround to enable poweroff on Mac Pro 11

  * Support Edge Gateway's Bluetooth LED (LP: #1512999)
- SAUCE: Bluetooth: Support for LED on Edge Gateways
- SAUCE: Bluetooth: Use host bridge subsystem IDs to identify Edge Gateways

  * Please add support for alps touchpad. (LP: #1616813)
- [Config] CONFIG_HID_ALPS=m
- HID: add Alps I2C HID Touchpad-Stick support
- HID: alps: struct u1_dev *priv is internal to the driver
- HID: alps: pass correct sizes to hid_hw_raw_request()
- HID: alps: match alps devices in core
- HID: alps: a few cleanups

  * DINO2M - System hangs with a black screen during s4 stress test
(LP: #1616781)
- x86/power/64: Fix kernel text mapping corruption during image restoration

  * Xenial update to v4.4.17 stable release (LP: #1611833)
- USB: OHCI: Don't mark EDs as ED_OPER if scheduling fails
- x86/quirks: Apply nvidia_bugs quirk only on root bus
- x86/quirks: Reintroduce scanning of secondary buses
- x86/quirks: Add early quirk to reset Apple AirPort card
- dmaengine: at_xdmac: align descriptors on 64 bits
- dmaengine: at_xdmac: fix residue corruption
- dmaengine: at_xdmac: double FIFO flush needed to compute residue
- mm, sl[au]b: add __GFP_ATOMIC to the GFP reclaim mask
- mm, compaction: abort free scanner if split fails
- fs/nilfs2: fix potential underflow in call to crc32_le
- mm, compaction: prevent VM_BUG_ON when terminating freeing scanner
- mm, meminit: always return a valid node from early_pfn_to_nid

[Yahoo-eng-team] [Bug 1625209] [NEW] ipv6 options are being checked for ipv4 subnet

[Aleksey Kasatkin]

Public bug reported:

When DHCP agent tries to set fixed_ips parameter for DHCP port (see 
https://bugs.launchpad.net/networking-calico/+bug/1541490) Neutron checks 
ipv6_address_mode and ipv6_ra_mode options of subnet that corresponds to the 
given fixed IP even for IPv4 subnet. And this fails as IPv4 subnet does not 
have such options (see traceback http://paste.openstack.org/show/580996/). And, 
of course, you cannot set such flags for IPv4 subnet.
I'd expect that such check is performed for IPv6 subnets only.

Probably, this situation is possible not only while using non-native
DHCP agent.

Neutron version: Newton (7f6b5b5d8953159740f74b0a4a5280527f6baa69).
Environment: Calico (https://github.com/openstack/networking-calico) over 
Neutron.
Point of failure: 
https://github.com/openstack/neutron/blob/7f6b5b5d8953159740f74b0a4a5280527f6baa69/neutron/agent/linux/dhcp.py#L1342
Traceback: http://paste.openstack.org/show/580996/
Failure rate: always.

** Affects: neutron
 Importance: Undecided
 Status: New


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

Title:
  ipv6 options are being checked for ipv4 subnet

Status in neutron:
  New

Bug description:
  When DHCP agent tries to set fixed_ips parameter for DHCP port (see 
https://bugs.launchpad.net/networking-calico/+bug/1541490) Neutron checks 
ipv6_address_mode and ipv6_ra_mode options of subnet that corresponds to the 
given fixed IP even for IPv4 subnet. And this fails as IPv4 subnet does not 
have such options (see traceback http://paste.openstack.org/show/580996/). And, 
of course, you cannot set such flags for IPv4 subnet.
  I'd expect that such check is performed for IPv6 subnets only.

  Probably, this situation is possible not only while using non-native
  DHCP agent.

  Neutron version: Newton (7f6b5b5d8953159740f74b0a4a5280527f6baa69).
  Environment: Calico (https://github.com/openstack/networking-calico) over 
Neutron.
  Point of failure: 
https://github.com/openstack/neutron/blob/7f6b5b5d8953159740f74b0a4a5280527f6baa69/neutron/agent/linux/dhcp.py#L1342
  Traceback: http://paste.openstack.org/show/580996/
  Failure rate: always.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625209/+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 1538169] Re: Quota_server_group_members parameter is not respected with min_count/max_count

[OpenStack Infra]

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

commit 43826e458eefc4157b45d8a04422cbdcdec4f7ff
Author: yuntongjin 
Date:   Tue Mar 1 16:00:16 2016 +0800

Add members in InstanceGroup object members field

In InstanceGroup object, add_members method doesn't add members
into object members field, which causes
objects.Quotas.count(server_group_members) won't increase, and
instance group quota check invalid. This makes an issue that user
could spawn with one call more instances in server group than
was allowed in quota_server_group_members is it was below
instances quota settting.

Co-authored-by: yuntongjin 

Change-Id: Icdd8aef688776f00fef6ede6e1bed01af29f9917
Closes-bug: #1538169


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

Title:
  Quota_server_group_members parameter is not respected with
  min_count/max_count

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When I create instances which I want to be in the same server group
  (--hint group=)  with parameter: --num-instances or --min-count
  /--max-count   and I have quota_server_group_members set to 5, nova is
  spawning all instances regardless quota.

   Example:
  nova boot --image $image --flavor small  --hint 
group=528ff1e3-5a6d-475c-826e-c70d7a56e769 --nic net-id= --min-count=2 
--max-count=10  test-instance

  All Instances has spawned correct. In next request I have an error:
  ERROR (Forbidden): Quota exceeded, too many servers in group (HTTP 403) 
(Request-ID: req-f8aa39cd-2a14-486d-95a9-747ed9eecbfc)

  
  Normally request which should spawn 10 instances (but quota is set to 5) 
should give an error with Quota exceeded.
  The same situation is with  --num-instances parameter.

  
  I check it many times in Juno release and on devstack using nova master 
branch.

  
  I added simple patch to forbidden creating new instances over quota, but it's 
should be changed and it's not working correctly with --min-count/--max-count 
parameter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1538169/+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 1624701] Re: OVS port pulled from under dnsmasq

[OpenStack Infra]

Reviewed:  https://review.openstack.org/371890
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=251922f5de2de35fb4766da6ab3e7a195c30310c
Submitter: Jenkins
Branch:master

commit 251922f5de2de35fb4766da6ab3e7a195c30310c
Author: Kevin Benton 
Date:   Thu Sep 15 14:10:20 2016 -0700

Disable DHCP on agent port removal

The previous logic was just ripping the interface out without
stopping dnsmasq. This would lead to a file handle remaining to the
interface which would cause OVS to completely freak out and assign
the same ofport to multiple ports.

This preserves the behavior introduced in
I40b85033d075562c43ce4d0e68296211b3241197 but just fully disables
DHCP rather than relying on an exception generation to cause the
resync.

Closes-bug: #1624701
Change-Id: Icdd9ac136eeb3707c912853b134dbb58109e6940


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

Title:
  OVS port pulled from under dnsmasq

Status in neutron:
  Fix Released

Bug description:
  Change [1] has triggered an issue with the DHCP agent. This can be
  reproduced as below:

  - A subnet gets deleted
  - A dhcp port is deleted
  - A notification is sent to the agent
  - DHCP agent deletes the port from OVS without killing dnsmasq first
  - dnsmasq is holding a file handle to the interface still
  - To this many times
  - OVS goes nuts with [2], where traces 'added interface tap%% on port ##' 
happens a gazillion time pointing to the same OVS and of port.

  [1] https://review.openstack.org/#/c/355117/
  [2] 
http://logs.openstack.org/74/370974/2/check/gate-tempest-dsvm-neutron-dvr-ubuntu-xenial/4d01980/logs/openvswitch/ovs-vswitchd.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1624701/+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 1624976] Re: neutron fails to start with vpnaas devstack plugin

[OpenStack Infra]

Reviewed:  https://review.openstack.org/372231
Committed: 
https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=e9d8afa2d7c778b4c4ba7325b989953726700b0c
Submitter: Jenkins
Branch:master

commit e9d8afa2d7c778b4c4ba7325b989953726700b0c
Author: rabi 
Date:   Mon Sep 19 11:01:19 2016 +0530

Add vpnaas conf to Q_PLUGIN_EXTRA_CONF_FILES

A recent change[1] that adds lbaas conf files to
Q_PLUGIN_EXTRA_CONF_FILES has broken vpnaas devstack
plugin.

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

Change-Id: Ice58bce3c2bd469a52299b9c830b9b588d700acf
Closes-Bug: #1624976


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

Title:
  neutron fails to start with vpnaas devstack plugin

Status in heat:
  New
Status in neutron:
  Fix Released

Bug description:
  I can see the below error in the neutron logs.

  2016-09-18 23:45:48.183 4787 DEBUG neutron.db.servicetype_db [-] Adding 
provider configuration for service VPN add_provider_configuration 
/opt/stack/new/neutron/neutron/db/servicetype_db.py:52
  2016-09-18 23:45:48.183 4787 ERROR neutron.services.service_base [-] No 
providers specified for 'VPN' service, exiting

  http://logs.openstack.org/27/369827/4/check/gate-heat-dsvm-functional-
  orig-mysql-
  lbaasv2/7bdf656/logs/screen-q-svc.txt.gz#_2016-09-18_23_45_48_183

  Not sure what neutron/vpnaas change has resulted in this failure.

  As we're now using the vpnaas devstack plugin for jobs, we could
  probably stop setting the default service_provider in
  pre_test_hook.sh.

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1624976/+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 1625140] [NEW] Deprecation warning for unused code

[Gary Kotton]

Public bug reported:

2016-09-18 03:20:37.403628 | Captured stderr:
2016-09-18 03:20:37.403670 | 
2016-09-18 03:20:37.403795 | neutron/tests/unit/api/test_api_common.py:33: 
DeprecationWarning: Using class 'NeutronController' (either directly or via 
inheritance) is deprecated in version 'newton' and will be removed in version 
'ocata'
2016-09-18 03:20:37.404051 |   self.controller = FakeController(None)
2016-09-18 03:20:37.404091 |

** Affects: neutron
 Importance: Undecided
 Assignee: Gary Kotton (garyk)
 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/1625140

Title:
  Deprecation warning for unused code

Status in neutron:
  In Progress

Bug description:
  2016-09-18 03:20:37.403628 | Captured stderr:
  2016-09-18 03:20:37.403670 | 
  2016-09-18 03:20:37.403795 | 
neutron/tests/unit/api/test_api_common.py:33: DeprecationWarning: Using class 
'NeutronController' (either directly or via inheritance) is deprecated in 
version 'newton' and will be removed in version 'ocata'
  2016-09-18 03:20:37.404051 |   self.controller = FakeController(None)
  2016-09-18 03:20:37.404091 |

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625140/+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 1625136] [NEW] linuxbridge trunk plugin doesn't handle subport changes without trunk update

[Kevin Benton]

Public bug reported:

The subport event handler is not correctly triggering wiring changes
when the subports for a trunk already present on the agent are changed.
This leaves a trunk dataplane frozen in time once its first wired up on
the linux bridge agent unless it receives another trunk event.

** Affects: neutron
 Importance: Undecided
 Assignee: Kevin Benton (kevinbenton)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Kevin Benton (kevinbenton)

** Changed in: neutron
Milestone: None => newton-rc2

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

Title:
  linuxbridge trunk plugin doesn't handle subport changes without trunk
  update

Status in neutron:
  In Progress

Bug description:
  The subport event handler is not correctly triggering wiring changes
  when the subports for a trunk already present on the agent are
  changed. This leaves a trunk dataplane frozen in time once its first
  wired up on the linux bridge agent unless it receives another trunk
  event.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625136/+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 1625135] [NEW] removing all subports from trunk leaves trunk in DOWN status with openvswitch driver

[Kevin Benton]

Public bug reported:

Removing all of the subports from a trunk leaves it in the DOWN status
rather than it transitioning back to ACTIVE after finishing the wiring
as expected.

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

Title:
  removing all subports from trunk leaves trunk in DOWN status with
  openvswitch driver

Status in neutron:
  New

Bug description:
  Removing all of the subports from a trunk leaves it in the DOWN status
  rather than it transitioning back to ACTIVE after finishing the wiring
  as expected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625135/+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 1563029] Re: Nova instance fail to launch: "Unexpected API Error."

[zhubingbing]

It has been 5 months, we can not reproduce this bug.

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

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

Title:
  Nova instance fail to launch: "Unexpected API Error."

Status in kolla:
  Won't Fix
Status in kolla mitaka series:
  Confirmed
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  This is a Kolla installation of openstack. The docker images build
  well and some services work great; e.g cinder, glance and neutron.

  Nova seems to have a problem that is prevent provisioning instances.
  The manila-api logs below says:

  "Returning 500 to user: Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   __call__ 
/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:1070"


  1. The GIT commit level is:

  lsorrillo@ptest:~/git/kolla$ git log -1
  commit 90321d0497f14bda370908610cfc44296a940523
  Merge: 328a7e8 a789346
  Author: Jenkins 
  Date:   Sun Mar 27 23:42:47 2016 +

  Merge "Fix gate to use world writeable docker socket"
  lsorrillo@ptest:~/git/kolla$

  RPM version:

  lsorrillo@ptest:~$
  lsorrillo@ptest:~$ docker exec -ti nova_api bash
  bash-4.2$
  bash-4.2$
  bash-4.2$
  bash-4.2$ rpm -qa | grep nova
  python-novaclient-3.3.1-0.20160303082753.d63800d.el7.centos.noarch
  openstack-nova-common-13.0.0.0b4-0.20160304162843.c5a45a2.el7.centos.noarch
  python-nova-13.0.0.0b4-0.20160304162843.c5a45a2.el7.centos.noarch
  openstack-nova-api-13.0.0.0b4-0.20160304162843.c5a45a2.el7.centos.noarch
  bash-4.2$

  2.

  The following error is seen in the nova-api.log:

  2016-03-28 19:53:40.086 29 DEBUG oslo.messaging._drivers.impl_rabbit 
[req-88ffb6f7-1b1f-4332-b066-5b0b41827988 5bd4af0c54a14a789661d868a9fb1d84 
9e4b40d958e741599adc497b0a9d955a - - -] Connecting to AMQP server on 
192.168.0.121:5672 __init__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py:535
  2016-03-28 19:53:40.132 29 DEBUG oslo.messaging._drivers.impl_rabbit 
[req-88ffb6f7-1b1f-4332-b066-5b0b41827988 5bd4af0c54a14a789661d868a9fb1d84 
9e4b40d958e741599adc497b0a9d955a - - -] Connected to AMQP server on 
192.168.0.121:5672 via [amqp] client __init__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py:562
  2016-03-28 19:53:40.148 29 DEBUG oslo.messaging._drivers.pool 
[req-88ffb6f7-1b1f-4332-b066-5b0b41827988 5bd4af0c54a14a789661d868a9fb1d84 
9e4b40d958e741599adc497b0a9d955a - - -] Pool creating new connection create 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/pool.py:109
  2016-03-28 19:53:40.151 29 DEBUG oslo.messaging._drivers.impl_rabbit 
[req-88ffb6f7-1b1f-4332-b066-5b0b41827988 5bd4af0c54a14a789661d868a9fb1d84 
9e4b40d958e741599adc497b0a9d955a - - -] Connecting to AMQP server on 
192.168.0.121:5672 __init__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py:535
  2016-03-28 19:53:40.205 29 DEBUG oslo.messaging._drivers.impl_rabbit 
[req-88ffb6f7-1b1f-4332-b066-5b0b41827988 5bd4af0c54a14a789661d868a9fb1d84 
9e4b40d958e741599adc497b0a9d955a - - -] Connected to AMQP server on 
192.168.0.121:5672 via [amqp] client __init__ 
/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py:562
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions 
[req-88ffb6f7-1b1f-4332-b066-5b0b41827988 5bd4af0c54a14a789661d868a9fb1d84 
9e4b40d958e741599adc497b0a9d955a - - -] Unexpected exception in API method
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 478, 
in wrapped
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
  2016-03-28 19:54:40.216 29 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 
630, in create
  2016-03-28 19:54:40.216 29 ERROR 

[Yahoo-eng-team] [Bug 1251224] Re: ICMP security group rules should have a type and code params instead of using "--port-range-min" and "--port-range-max"

[Itzik Brown]

Still relevant in Newton.

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

Title:
  ICMP security group rules should have a type and code params instead
  of using "--port-range-min" and "--port-range-max"

Status in neutron:
  Confirmed

Bug description:
  Version
  ==
  Havana on rhel

  Description
  =
  I couldn't find a doc specifying whether icmp security group rules ignore the 
"--port-range-min" and "--port-range-max" params or use then as code and type 
as we know from nova security group rules.
  I think that it should be:

  i. Well documented.
  ii. prohibited for use of "--port-range-min" and "--port-range-max" in icmp 
rules context, new switches should be created for code and type.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1251224/+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 1624097] Re: Neutron LBaaS CLI quota show includes l7policy and doesn't include member

[OpenStack Infra]

Reviewed:  https://review.openstack.org/371342
Committed: 
https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=91c4509afe1bdf89f89a40dfc0a3cb808fd2004a
Submitter: Jenkins
Branch:master

commit 91c4509afe1bdf89f89a40dfc0a3cb808fd2004a
Author: Reedip 
Date:   Fri Sep 16 13:39:54 2016 +0530

Fix quota-update issue in LBaaS

Currently L7Policies cannot be updated( it was missing
in implementation in neutronclient). The same has been
taken care in the current patch.

Also, currently quota doesnt support updating the members
in an LBaaS pool. This patch temporarily removes it, till
it is not confirmed that LBaaS v2 needs to support quotas
for members or not.

Change-Id: I25a54a57debb762a32a280ece8c081fc52365f0f
Closes-Bug: #1624097


** Changed in: python-openstackclient
   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/1624097

Title:
  Neutron LBaaS CLI quota show includes l7policy and doesn't include
  member

Status in neutron:
  Incomplete
Status in python-openstackclient:
  Fix Released

Bug description:
  When running devstack and executing "neutron quota-show" it lists an
  l7 policy quota, but does not show a member quota.  However, the help
  message for "neutron quota-update" includes a member quota, but not an
  l7 policy quota.  The show command should not have the l7 policy
  quota, but should have the member quota.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1624097/+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 1625120] [NEW] Keystone should provide more verbose messages in case of 401 and 403 errors

[Timur Nurlygayanov]

Public bug reported:

On many our environments we can see 401 and 403 errors during the
execution of Tempest tests, but after the execution of the tests we
can't debug the issue because we don't have any information about 401
errors in keystone logs. In the same time we can have many different
reasons why we got 401 error, and in the case of Tempest we sure that we
use correct credentials.

We need to have an ability to get the information about the reasons of
401/403 errors in Keystone, at least write short human-readable messages
in debug mode, so we will be able to understand the line of code where
the issue happened and try to guess how we can fix it.

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

Title:
  Keystone should provide more verbose messages in case of 401 and 403
  errors

Status in OpenStack Identity (keystone):
  New

Bug description:
  On many our environments we can see 401 and 403 errors during the
  execution of Tempest tests, but after the execution of the tests we
  can't debug the issue because we don't have any information about 401
  errors in keystone logs. In the same time we can have many different
  reasons why we got 401 error, and in the case of Tempest we sure that
  we use correct credentials.

  We need to have an ability to get the information about the reasons of
  401/403 errors in Keystone, at least write short human-readable
  messages in debug mode, so we will be able to understand the line of
  code where the issue happened and try to guess how we can fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1625120/+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 1625106] [NEW] gate failure: check_public_network_connectivity

[LIU Yulong]

Public bug reported:

http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22in%20check_public_network_connectivity%5C%22

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: gate-failure

** Tags added: gate-failure

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

Title:
  gate failure: check_public_network_connectivity

Status in neutron:
  New

Bug description:
  
http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22in%20check_public_network_connectivity%5C%22

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1625106/+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 1625105] [NEW] During rebuild/spawn instance stopped compute, the instances set error_state

[Alex Szarka]

Public bug reported:

Error cases:
1) If we create any new instance and stop nova while spawn, then the nova 
compute at start set this instance to error state. 
2) If we start rebuild any instance and stop nova while not rebuilt, then the 
nova compute at start set this instance to error state.

We should start again (or resume) the interrupted process at nova start
instead of set to error state the related instances.

** Affects: nova
 Importance: Undecided
 Assignee: Alex Szarka (xavvior)
 Status: In Progress

** Changed in: nova
 Assignee: (unassigned) => Alex Szarka (xavvior)

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

Title:
  During rebuild/spawn instance stopped compute, the instances set
  error_state

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Error cases:
  1) If we create any new instance and stop nova while spawn, then the nova 
compute at start set this instance to error state. 
  2) If we start rebuild any instance and stop nova while not rebuilt, then the 
nova compute at start set this instance to error state.

  We should start again (or resume) the interrupted process at nova
  start instead of set to error state the related instances.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1625105/+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 1625101] [NEW] Some cinder failures return "500" errors to users

[Alvaro Lopez]

Public bug reported:

When a user tries to delete a volume that is attached to a VM using nova
the user gets an "Unexpected Exception" error when cinderclient fails
with an InvalidInput exception. This is not particularly helpful for
troubleshooting and the message is misleading for users.

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

Title:
  Some cinder failures return "500" errors to users

Status in OpenStack Compute (nova):
  New

Bug description:
  When a user tries to delete a volume that is attached to a VM using
  nova the user gets an "Unexpected Exception" error when cinderclient
  fails with an InvalidInput exception. This is not particularly helpful
  for troubleshooting and the message is misleading for users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1625101/+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 1625075] [NEW] Shared & public images no working with multi-tenant swift backend

[Andrew Battye]

Public bug reported:

Hi,

We are seeing issues when trying to using public and shared images when
Glance is configured to use a multi-tenant Swift backend.

Here's what we see :

1. Create a public image in project cf8fc081a9954cef81befb67b4002ce8 
2. Attempt to create instance from image in project 
67e22ed6876d432d9e48f9bd2a20a527
3. The instance creation fails, with the following log line in the Glance API 

Object GET failed:
https://objectstore.domain.corp:443/v1/AUTH_67e22ed6876d432d9e48f9bd2a20a527
/glance_6e84cb8d-7f09-4f78-8363-a6005e0c51d2/6e84cb8d-
7f09-4f78-8363-a6005e0c51d2 404 Not Found

The issue appears to be that the storage url in the swift store driver
is determined from the catalog in the context of the current request
(which is scoped to the project we are creating the instance in) not
project where the image is created.

Looking at the changes introduced here
https://git.openstack.org/cgit/openstack/glance_store/commit/?id=68762058cc5d063f3a846b495af03150e648224f
it seems to us that storage_url can only contain the account
AUTH_[current_context_project_id] and in this case its not clear how a
public or shared image from another project can be retrieved from Swift.

Since this is pretty fundamental for the use case we can only assume we are 
missing some configuration option. The direct url in Glance is stored as 
direct_url='swift+config://swift-global/glance_c7396e07-484c-4ef3-b54c-9b6ea0cb367e/c7396e07-484c-4ef3-b54c-9b6ea0cb367e'
 and 
 since the driver and location seem to have no information on the image other 
than the image id its not clear how it could make the distinction between 
public/shared images and private ones or determine the project if of the shared 
image. 

The only way we can get this to work is first to create an instance on
each hypervisor in the project of the shared image. When we do this
creating instances in a second project work because the image is cached
on the hypervisor - obviously this is not a viable workaround.

Any information on how to get this scenario working would be much
appreciated.

Thanks

Andrew

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  Shared & public images no working with multi-tenant swift backend

Status in Glance:
  New

Bug description:
  Hi,

  We are seeing issues when trying to using public and shared images
  when Glance is configured to use a multi-tenant Swift backend.

  Here's what we see :

  1. Create a public image in project cf8fc081a9954cef81befb67b4002ce8 
  2. Attempt to create instance from image in project 
67e22ed6876d432d9e48f9bd2a20a527
  3. The instance creation fails, with the following log line in the Glance API 

  Object GET failed:
  https://objectstore.domain.corp:443/v1/AUTH_67e22ed6876d432d9e48f9bd2a20a527
  /glance_6e84cb8d-7f09-4f78-8363-a6005e0c51d2/6e84cb8d-
  7f09-4f78-8363-a6005e0c51d2 404 Not Found

  The issue appears to be that the storage url in the swift store driver
  is determined from the catalog in the context of the current request
  (which is scoped to the project we are creating the instance in) not
  project where the image is created.

  Looking at the changes introduced here
  
https://git.openstack.org/cgit/openstack/glance_store/commit/?id=68762058cc5d063f3a846b495af03150e648224f
  it seems to us that storage_url can only contain the account
  AUTH_[current_context_project_id] and in this case its not clear how a
  public or shared image from another project can be retrieved from
  Swift.

  Since this is pretty fundamental for the use case we can only assume we are 
missing some configuration option. The direct url in Glance is stored as 
direct_url='swift+config://swift-global/glance_c7396e07-484c-4ef3-b54c-9b6ea0cb367e/c7396e07-484c-4ef3-b54c-9b6ea0cb367e'
 and 
   since the driver and location seem to have no information on the image other 
than the image id its not clear how it could make the distinction between 
public/shared images and private ones or determine the project if of the shared 
image. 

  The only way we can get this to work is first to create an instance on
  each hypervisor in the project of the shared image. When we do this
  creating instances in a second project work because the image is
  cached on the hypervisor - obviously this is not a viable workaround.

  Any information on how to get this scenario working would be much
  appreciated.

  Thanks

  Andrew

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1625075/+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 1625061] [NEW] parameters of datatable in tabletab can't store in session

[markrui]

Public bug reported:

When I use datatable in a tabletab, I use filter_type = "server" and 
filter_choices = (('hostname', _("host name"), True),). Then I can't get the 
data from table. However, it is just OK in datatable directly in view.
I read about source code and write my filter function as below:
def get_filters(self, filters):
filter_action = self._tables.items()[0][1]._meta._filter_action
if filter_action:
filter_field = self._tables.items()[0][1].get_filter_field()
if filter_action.is_api_filter(filter_field):
filter_string = self._tables.items()[0][1].get_filter_string()
if filter_field and filter_string:
filters[filter_field] = filter_string
return filters

I print the self._tables.items()[0][1] and it is the table instance I need. I 
print self._tables.items()[0][1].get_filter_field() but it is null. Then I read 
the source code and find the function is like this:
def get_filter_field(self):
"""Get the filter field value used for 'server' type filters. This
is the value from the filter action's list of filter choices.
"""
filter_action = self._meta._filter_action
param_name = '%s_field' % filter_action.get_param_name()
filter_field = self.request.session.get(param_name, '')
return filter_field
I print param_name and it is the field from the website. Then I know 
filter_field is get from the session according to the code note. I print the 
session(with __dict__) but it doesn't have a field called '*__q_field'(* is 
short for my table name), so I wonder if the parameters are stored in session 
as the code note said.

Can anyone give me any advice?

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: datatable tabletab

** Tags added: datatable tabletab

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

Title:
  parameters of datatable in tabletab can't store in session

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  When I use datatable in a tabletab, I use filter_type = "server" and 
filter_choices = (('hostname', _("host name"), True),). Then I can't get the 
data from table. However, it is just OK in datatable directly in view.
  I read about source code and write my filter function as below:
  def get_filters(self, filters):
  filter_action = self._tables.items()[0][1]._meta._filter_action
  if filter_action:
  filter_field = self._tables.items()[0][1].get_filter_field()
  if filter_action.is_api_filter(filter_field):
  filter_string = self._tables.items()[0][1].get_filter_string()
  if filter_field and filter_string:
  filters[filter_field] = filter_string
  return filters

  I print the self._tables.items()[0][1] and it is the table instance I need. I 
print self._tables.items()[0][1].get_filter_field() but it is null. Then I read 
the source code and find the function is like this:
  def get_filter_field(self):
  """Get the filter field value used for 'server' type filters. This
  is the value from the filter action's list of filter choices.
  """
  filter_action = self._meta._filter_action
  param_name = '%s_field' % filter_action.get_param_name()
  filter_field = self.request.session.get(param_name, '')
  return filter_field
  I print param_name and it is the field from the website. Then I know 
filter_field is get from the session according to the code note. I print the 
session(with __dict__) but it doesn't have a field called '*__q_field'(* is 
short for my table name), so I wonder if the parameters are stored in session 
as the code note said.

  Can anyone give me any advice?

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1625061/+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 1623871] Re: Nova hugepage support does not include aarch64

[OpenStack Infra]

Fix proposed to branch: master
Review: https://review.openstack.org/372304

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

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

Title:
  Nova hugepage support does not include aarch64

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Although aarch64 supports spawning a vm with hugepages, in nova code,
  the libvirt driver considers only x86_64 and I686. Both for NUMA and
  Hugepage support, AARCH64 needs to be added. Due to this bug, vm can
  not be launched with hugepage using OpenStack on aarch64 servers.

  Steps to reproduce:
  On an openstack environment running on aarch64:
  1. Configure compute to use hugepages.
  2. Set mem_page_size="2048" for a flavor
  3. Launch a VM using the above flavor. 

  Expected result:
  VM should be launched with hugepages and the libvirt xml should have 



  



  Actual result:
  VM is launched without hugepages.

  There are no error logs in nova-scheduler.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1623871/+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 1623099] Re: FWaaSv2 - 'firewall_policy_id' is missing in firewall_rule response body

[Reedip]

As per [1] , firewall_policy_id need not be a part of the firewall
rules.

[1]:  https://github.com/openstack/neutron-
specs/blob/master/specs/newton/fwaas-api-2.0.rst

** Changed in: neutron
   Status: In Progress => Invalid

** Changed in: neutron
 Assignee: Reedip (reedip-banerjee) => (unassigned)

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

Title:
  FWaaSv2 - 'firewall_policy_id' is missing in firewall_rule response
  body

Status in neutron:
  Invalid

Bug description:
  This is FWaaS v2.

  [How to reproduce]
  $ source devstack/openrc admin admin
  $ export TOKEN=`openstack token issue | grep ' id ' | get_field 2`
  $  curl -s -X GET -H "x-auth-token:$TOKEN" 
localhost:9696/v2.0/fwaas/firewall_rules/19230148-740b-4546-9d9a-ab0c50178369 | 
jq "."

  {
    "firewall_rule": {
  "protocol": null,
  "description": "",
  "source_ip_address": null,
  "destination_ip_address": null,
  "source_port": null,
  "destination_port": null,
  "id": "19230148-740b-4546-9d9a-ab0c50178369",
  "name": "rule3",
  "tenant_id": "aa8dcde3d61747b48f699dca6832af62",
  "enabled": true,
  "action": "deny",
  "ip_version": 4,
  "public": false
    }
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623099/+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 1625013] [NEW] dhcpv6-stateless cause dhcp _generate_opts_per_subnet fail

[ZongKai LI]

Public bug reported:

ipv6 subnet with dhcpv6_stateless address mode cause KeyError in
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L895
, when force_metadata is configured as True.

2016-09-19 06:55:44.211 ERROR neutron.agent.dhcp.agent [-] Unable to enable 
dhcp for c0eea6e2-f98d-48b9-aab0-67113a82a70e.
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent Traceback (most recent 
call last):
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 114, in call_driver
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent getattr(driver, 
action)(**action_kwargs)
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 213, in enable
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent self.spawn_process()
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 425, in spawn_process
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self._spawn_or_reload_process(reload_with_HUP=False)
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 434, in 
_spawn_or_reload_process
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self._output_config_files()
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 467, in 
_output_config_files
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self._output_opts_file()
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 845, in _output_opts_file
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent options, 
subnet_index_map = self._generate_opts_per_subnet()
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 895, in 
_generate_opts_per_subnet
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent subnet_dhcp_ip = 
subnet_to_interface_ip[subnet.id]
2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent KeyError: 
u'7e086056-521a-4d91-b2a7-6d1b3fffb49b'

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

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

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

Title:
  dhcpv6-stateless cause dhcp _generate_opts_per_subnet fail

Status in neutron:
  New

Bug description:
  ipv6 subnet with dhcpv6_stateless address mode cause KeyError in
  
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/dhcp.py#L895
  , when force_metadata is configured as True.

  2016-09-19 06:55:44.211 ERROR neutron.agent.dhcp.agent [-] Unable to enable 
dhcp for c0eea6e2-f98d-48b9-aab0-67113a82a70e.
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent Traceback (most recent 
call last):
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 114, in call_driver
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent getattr(driver, 
action)(**action_kwargs)
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 213, in enable
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self.spawn_process()
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 425, in spawn_process
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self._spawn_or_reload_process(reload_with_HUP=False)
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 434, in 
_spawn_or_reload_process
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self._output_config_files()
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 467, in 
_output_config_files
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent 
self._output_opts_file()
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 845, in _output_opts_file
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent options, 
subnet_index_map = self._generate_opts_per_subnet()
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent   File 
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 895, in 
_generate_opts_per_subnet
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent subnet_dhcp_ip = 
subnet_to_interface_ip[subnet.id]
  2016-09-19 06:55:44.211 TRACE neutron.agent.dhcp.agent KeyError: 
u'7e086056-521a-4d91-b2a7-6d1b3fffb49b'

To manage notifications about 

[Yahoo-eng-team] [Bug 1624976] Re: dsvm jobs broken as neutron fails to start

[Rabi Mishra]

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

** Changed in: neutron
 Assignee: (unassigned) => Rabi Mishra (rabi)

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

Title:
  dsvm jobs broken as neutron fails to start

Status in heat:
  New
Status in neutron:
  In Progress

Bug description:
  I can see the below error in the neutron logs.

  2016-09-18 23:45:48.183 4787 DEBUG neutron.db.servicetype_db [-] Adding 
provider configuration for service VPN add_provider_configuration 
/opt/stack/new/neutron/neutron/db/servicetype_db.py:52
  2016-09-18 23:45:48.183 4787 ERROR neutron.services.service_base [-] No 
providers specified for 'VPN' service, exiting

  http://logs.openstack.org/27/369827/4/check/gate-heat-dsvm-functional-
  orig-mysql-
  lbaasv2/7bdf656/logs/screen-q-svc.txt.gz#_2016-09-18_23_45_48_183

  Not sure what neutron/vpnaas change has resulted in this failure.

  As we're now using the vpnaas devstack plugin for jobs, we could
  probably stop setting the default service_provider in
  pre_test_hook.sh.

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