[Yahoo-eng-team] [Bug 1602358] Re: [agent] extensions option not included in sample config files

[OpenStack Infra]

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

commit 3b38912e79746764c4e0171a9ecc7e44183f929e
Author: Ihar Hrachyshka 
Date:   Tue Jul 12 13:25:49 2016 -0400

Include [agent] extensions option into ovs/linuxbridge agent files

The option was introduced in Liberty. In Mitaka, we switched to using
oslo-config-generator but missed including this specific option.

The patch returns the option back. It should be backported to Mitaka.

Change-Id: Ie4a4ea44eedac3d6c7ac1b6e0739f6c44212b2ea
Closes-Bug: #1602358


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

Title:
  [agent] extensions option not included in sample config files

Status in neutron:
  Fix Released

Bug description:
  The [agent] section for LB and OVS agents misses the 'extensions'
  option. This is because it's missing in neutron/opts.py.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1602358/+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 1614630] Re: hz-field-directive If a property is null or undefined and does not have filters transforming, exception is logged

[OpenStack Infra]

Reviewed:  https://review.openstack.org/357360
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=210d420749124be951be55d6e02f332cf396300e
Submitter: Jenkins
Branch:master

commit 210d420749124be951be55d6e02f332cf396300e
Author: Travis Tripp 
Date:   Thu Aug 18 11:08:40 2016 -0600

hz-field-directive handle no value property

hz-field-directive was developed using hz images panel where every
single property had at least the no value filter applied. However,
when using it with properties that don't have the no value filter
applied and there is no value, we'll see the following in console.log

angular.js:12783 TypeError: Cannot read property 'then' of undefined

Change-Id: I14f8d56cc9086e7e25e11c081de34bc9d21389d0
Closes-Bug: #1614630


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

Title:
  hz-field-directive If a property is null or undefined and does not
  have filters transforming, exception is logged

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  hz-field-directive was developed using hz images panel where every
  single property had at least the no value filter applied.  However,
  when using it with properties that don't have the no value filter
  applied and there is no value, we'll see the following in console.log

  angular.js:12783 TypeError: Cannot read property 'then' of undefined
  at link 
(http://127.0.0.1:8005/static/framework/widgets/property/hz-field.directive.js:115:17)
  at http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:9073:44
  at invokeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:9079:9)
  at nodeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:8566:11)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7965:13)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7968:13)
  at nodeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:8561:24)
  at delayedNodeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:8828:11)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7965:13)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7968:13) (anonymous 
function) @ angular.js:12783(anonymous function) @ angular.js:9535invokeLinkFn 
@ angular.js:9081nodeLinkFn @ angular.js:8566compositeLinkFn @ 
angular.js:7965compositeLinkFn @ angular.js:7968nodeLinkFn @ 
angular.js:8561delayedNodeLinkFn @ angular.js:8828compositeLinkFn @ 
angular.js:7965compositeLinkFn @ angular.js:7968publicLinkFn @ 
angular.js:7845boundTranscludeFn @ angular.js:7983controllersBoundTransclude @ 
angular.js:8593ngRepeatAction @ angular.js:28080$watchCollectionAction @ 
angular.js:16066$digest @ angular.js:16203$apply @ angular.js:16467done @ 
angular.js:10852completeRequest @ angular.js:11050requestLoaded @ 
angular.js:10991
  4angular.js:12783 TypeError: Cannot read property 'then' of null
  at link 
(http://127.0.0.1:8005/static/framework/widgets/property/hz-field.directive.js:115:17)
  at http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:9073:44
  at invokeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:9079:9)
  at nodeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:8566:11)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7965:13)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7968:13)
  at nodeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:8561:24)
  at delayedNodeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:8828:11)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7965:13)
  at compositeLinkFn 
(http://127.0.0.1:8005/static/horizon/lib/angular/angular.js:7968:13) 

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1614630/+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 1490743] Re: Attempt to call strftime on a str fails revocation_list

[Steve Martinelli]

** Changed in: keystone
   Status: Fix Committed => 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/1490743

Title:
  Attempt to call strftime on a str fails revocation_list

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  This bug is nearly identical to the old bug
  https://bugs.launchpad.net/keystone/+bug/1285871 , same symptom and
  nearly identical code  . It is currently causing barbican to fail for
  us.

  2015-08-21 03:17:05.244 22742 ERROR keystone.common.wsgi [-] 'str' object has 
no a
  ttribute 'strftime'
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi Traceback (most 
recent ca
  ll last):
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 239, in 
__call__
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi result = 
method(context, **params)
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 158, in 
inner
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi return f(self, 
context, *args, **kwargs)
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 549, in 
revocation_list
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi t['expires'] = 
timeutils.isotime(expires)
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi   File 
"/usr/lib/python2.7/site-packages/oslo_utils/timeutils.py", line 52, in isotime
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi st = 
at.strftime(_ISO8601_TIME_FORMAT
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi AttributeError: 
'str' object has no attribute 'strftime'
  2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi 
  2015-08-21 03:17:05.263 22742 INFO eventlet.wsgi.server [-] 
100.72.132.128,10.50.249.37 - - [21/Aug/2015 03:17:05] "GET 
/v3/auth/tokens/OS-PKI/revoked HTTP/1.1" 500 470 0.063453

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1490743/+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 1616713] [NEW] neutron provider network type shouldn't include "vxlan" and "gre"

[brenda]

Public bug reported:

I think there is a mistake on "Networking API v2.0" document at 
http://developer.openstack.org/api-ref/networking/v2/?expanded=update-network-provider-network-detail.
 The api points that "provider:network_type" is the type of physical network 
that maps to this network resource. For example, flat, vlan, vxlan, or gre. But 
"vxlan" and "gre" network types are both overlay network types, they should not 
be included in provider network types.

** Affects: neutron
 Importance: Undecided
 Assignee: brenda (tian-mingming)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => brenda (tian-mingming)

** Description changed:

- I think there is a mistake on "Networking API v2.0" document 
athttp://developer.openstack.org/api-ref/networking/v2/?expanded=update-network-provider-network-detail.
+ I think there is a mistake on "Networking API v2.0" document at 
http://developer.openstack.org/api-ref/networking/v2/?expanded=update-network-provider-network-detail.
   The api points that "provider:network_type" is the type of physical network 
that maps to this network resource. For example, flat, vlan, vxlan, or gre. But 
"vxlan" and "gre" network types are both overlay network types, they should not 
be included in provider network types.

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

Title:
  neutron provider network type shouldn't include "vxlan" and "gre"

Status in neutron:
  New

Bug description:
  I think there is a mistake on "Networking API v2.0" document at 
http://developer.openstack.org/api-ref/networking/v2/?expanded=update-network-provider-network-detail.
   The api points that "provider:network_type" is the type of physical network 
that maps to this network resource. For example, flat, vlan, vxlan, or gre. But 
"vxlan" and "gre" network types are both overlay network types, they should not 
be included in provider network types.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616713/+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 1616709] [NEW] xstatic package release process documentation is not correct

[Richard Jones]

Public bug reported:

The xstatic package release documentation refers to a *possibility* of
an automated upper-constraints.txt patch. This is actually a reliable
thing, so we need to alter our documentation to match reality.

** Affects: horizon
 Importance: High
 Assignee: Richard Jones (r1chardj0n3s)
 Status: In Progress

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

** Changed in: horizon
 Assignee: (unassigned) => Richard Jones (r1chardj0n3s)

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

Title:
  xstatic package release process documentation is not correct

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The xstatic package release documentation refers to a *possibility* of
  an automated upper-constraints.txt patch. This is actually a reliable
  thing, so we need to alter our documentation to match reality.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616709/+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 1614594] Re: neutron-lib public APIs missing docstring

[OpenStack Infra]

Reviewed:  https://review.openstack.org/358894
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=5fbbfcc2d35cc120b3b22b4b5f11bacad0c1e778
Submitter: Jenkins
Branch:master

commit 5fbbfcc2d35cc120b3b22b4b5f11bacad0c1e778
Author: Boden R 
Date:   Mon Aug 22 16:48:03 2016 -0600

Add  docstrings for utils.net

Cleaning up a little technical debt by adding docstrings
for our public APIs.

Note: I plan to submit a patch per file as part of this bug work.
These patches won't depend on each other. The last patch of
the series will close the bug.

Change-Id: I3d51dfec0526062ecfad527121e3fa37387c22db
Closes-Bug: #1614594


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

Title:
  neutron-lib public APIs missing docstring

Status in neutron:
  Fix Released

Bug description:
  As per our neutron-lib guidelines [1], we'd like to have all public
  APIs documented via docstrings. Today we have a handful that are
  missing docs. This is just a tracking bug to get our existing neutron-
  lib public APIs docstringed.

  
  [1] 
https://github.com/openstack/neutron-lib/blob/master/doc/source/review-guidelines.rst

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614594/+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 1614452] Re: Port create time grows at scale due to dvr arp update

[OpenStack Infra]

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

commit 4bdab5cf1da333cf4e7aaf893e14b094fc5fad61
Author: Oleg Bondarev 
Date:   Thu Aug 18 11:55:33 2016 +0300

L3 DVR: use fanout when sending dvr arp table update

Sending arp update to each l3 dvr agent one by one on every port
creation is not scalable and causes serious performance degradation
if router is hosted on lots of l3 dvr agents on compute nodes (see
bug report). This increases port creation time and eventually leads
to timeouts in Nova and VMs going to ERROR state.

This patch changes notification to be fanout.
The downside is that with fanout the arp notification will be sent to
each l3 agent, even those not hosting the router. However such agents
will just skip the notification if not hosting the router - this should
be quite cheap.

Closes-Bug: #1614452
Change-Id: I1fb533d7804b131f709b790fc730ed7b97cb5499


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

Title:
  Port create time grows at scale due to dvr arp update

Status in neutron:
  Fix Released

Bug description:
  Scale tests show that sometimes VMs are not able to spawn because of timeouts 
on port creation.
  Neutron server logs show that port creation time grows due to dvr arp table 
updates being sent to each l3 dvr agent hosting the router one by one - this 
takes > 90% of time: http://paste.openstack.org/show/560761/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614452/+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 1614964] Re: NetworksSearchCriteriaTest. test_list_pagination_with_href_links fails due to external networks not filtered out

[OpenStack Infra]

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

commit c3c9cdd6f29334476479d0c0e3760ac7b90a530c
Author: Ihar Hrachyshka 
Date:   Fri Aug 19 14:32:12 2016 +0100

Filter out external networks in NetworksSearchCriteriaTest

Otherwise those networks that may even belong to another tenant still
show up in the results that we then compare iterated networks to.

Change-Id: I24b117401a1886dce0b78900b522ac9bace533bf
Closes-Bug: #1614964


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

Title:
  NetworksSearchCriteriaTest. test_list_pagination_with_href_links fails
  due to external networks not filtered out

Status in neutron:
  Fix Released

Bug description:
  http://logs.openstack.org/13/350613/6/check/gate-neutron-dsvm-
  api/0dcba21/testr_results.html.gz

  Traceback (most recent call last):
File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_networks.py", 
line 124, in test_list_pagination_with_href_links
  self._test_list_pagination_with_href_links()
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 486, 
in inner
  return f(self, *args, **kwargs)
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 477, 
in inner
  return f(self, *args, **kwargs)
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 664, 
in _test_list_pagination_with_href_links
  self._test_list_pagination_iteratively(self._list_all_with_hrefs)
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 593, 
in _test_list_pagination_iteratively
  len(expected_resources), sort_args
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 644, 
in _list_all_with_hrefs
  self.assertNotIn('next', prev_links)
File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
455, in assertNotIn
  self.assertThat(haystack, matcher, message)
File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: {u'previous': 
u'http://127.0.0.1:9696/v2.0/networks?limit=1=False_dir=asc_key=name=1a533251-9f37-4f03-bc48-6e8356baffd6_reverse=True',
 u'next': 
u'http://127.0.0.1:9696/v2.0/networks?limit=1=False_dir=asc_key=name=1a533251-9f37-4f03-bc48-6e8356baffd6'}
 matches Contains('next')

  In initial list result, we see a network that does not belong to the
  tenant. This is because it's external.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614964/+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 1616669] [NEW] Policy check target is inconsistent in use of domain_id

[Steve McLellan]

Public bug reported:

The code starting at
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/policy.py#L130
sets four keys on the policy check target equal to the user's domain id
(e.g the domain in which the user was created). Line 144 then reassigns
the 'domain_id' key with the domain to which the user has a scoped token
*if* they have such a token.

This creates a double meaning for domain_id. When keystone uses
'domain_id' in policy checks, the meaning is 'the domain to which a
token is scoped', so a check for 'is a domain admin' might be
'role:admin and domain_id:%(domain_id)s'. Under Horizon this doesn't
work, since the domain_id part essentially always passes, and thus a
project admin is indistinguishable from a domain admin.

My proposal is to set domain_id only if there is a domain scoped token.
If a policy check actually requires the user's domain, it can use
attributes on the token (token.user.domain.id).

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

Title:
  Policy check target is inconsistent in use of domain_id

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The code starting at
  
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/policy.py#L130
  sets four keys on the policy check target equal to the user's domain
  id (e.g the domain in which the user was created). Line 144 then
  reassigns the 'domain_id' key with the domain to which the user has a
  scoped token *if* they have such a token.

  This creates a double meaning for domain_id. When keystone uses
  'domain_id' in policy checks, the meaning is 'the domain to which a
  token is scoped', so a check for 'is a domain admin' might be
  'role:admin and domain_id:%(domain_id)s'. Under Horizon this doesn't
  work, since the domain_id part essentially always passes, and thus a
  project admin is indistinguishable from a domain admin.

  My proposal is to set domain_id only if there is a domain scoped
  token. If a policy check actually requires the user's domain, it can
  use attributes on the token (token.user.domain.id).

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616669/+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 1616660] [NEW] TypeError: $options[jj].attr is not a function on Project Creation

[Diana Whitten]

Public bug reported:

A rather nasty JavaScript error triggers when you attempt to do a
Project Creation from inside of the "Create User" modal.

Recreate:

hit the '+' next to the project dropdown, create the project and the
error occurs when you get kicked back to the User modal.

** Affects: horizon
 Importance: High
 Assignee: Diana Whitten (hurgleburgler)
 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/1616660

Title:
  TypeError: $options[jj].attr is not a function on Project Creation

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  A rather nasty JavaScript error triggers when you attempt to do a
  Project Creation from inside of the "Create User" modal.

  Recreate:

  hit the '+' next to the project dropdown, create the project and the
  error occurs when you get kicked back to the User modal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616660/+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 1616653] [NEW] Compile Modals only when needed

[Diana Whitten]

Public bug reported:

Right now, we compile ALL templates upfront.  We may want to only use
alerts when necessary, and so we should only compile each one as needed
and cache its value for use later.

** Affects: horizon
 Importance: Low
 Status: In Progress


** Tags: efficiency

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

Title:
  Compile Modals only when needed

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Right now, we compile ALL templates upfront.  We may want to only use
  alerts when necessary, and so we should only compile each one as
  needed and cache its value for use later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616653/+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 1616654] [NEW] Compile Modals only when needed

[Diana Whitten]

Public bug reported:

Right now, we compile ALL templates upfront.  We may want to only use
alerts when necessary, and so we should only compile each one as needed
and cache its value for use later.

** Affects: horizon
 Importance: Low
 Assignee: Diana Whitten (hurgleburgler)
 Status: In Progress


** Tags: efficiency

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

Title:
  Compile Modals only when needed

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  Right now, we compile ALL templates upfront.  We may want to only use
  alerts when necessary, and so we should only compile each one as
  needed and cache its value for use later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616654/+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 1585699] Re: Neutron Metadata Agent Configuration - nova_metadata_ip

[Brent Eagles]

** Project changed: puppet-tripleo => puppet-neutron

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

Title:
  Neutron Metadata Agent Configuration - nova_metadata_ip

Status in neutron:
  In Progress
Status in puppet-neutron:
  New

Bug description:
  I am not sure if this constitutes the tag 'bug'. However it has lead
  us to some confusion and I feel it should be updated.

  This option in neutron metadata configuration (and install docs) is
  misleading.

  {{{
  # IP address used by Nova metadata server. (string value)
  #nova_metadata_ip = 127.0.0.1
  }}}

  It implies the need to present an IP address for the nova metadata
  api. Where as in actual fact this can be a hostname or IP address.

  When using TLS encrypted sessions, this 'has' to be a hostname, else
  this ends in a SSL issue, as the hostname is embedded in the
  certificates.

  I am seeing this issue with OpenStack Liberty, however it appears to
  be in the configuration reference for Mitaka too, so I guess this is
  accross the board.

  If this needs to be listed in a different forum, please let me know!

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1585699/+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 1616253] Re: QoS api need to reformat qos_policy_data

[Manjeet Singh Bhatia]

I had this ticket to have a discussion with qos folks to consider reformating
the data qos extension pass to notification drivers.

this ticket can be closed or marked duplicated as similar issue is reported here
https://bugs.launchpad.net/neutron/+bug/1614728 


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

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

Title:
  QoS api need to reformat  qos_policy_data

Status in neutron:
  Invalid

Bug description:
  neutron api pass qos data to notification, 
  which is qos_policy object

  qos_policy like QosPolicy(description='',id=58c5f284-bc0d-420d-9aac-
  69b3e7cc6e0c,name='testpolicy-0',rules=[QosRule(403c3298-d51a-
  41d3-99f2-bd5cbc698448),QosRule(5c157ba8-0168-4ca9-abbf-
  93a0e7483f48)],shared=False,tenant_id='1cbe81ac17ed4703988cd390d4f0dc39')

  {'description': u'', 'rules': [{'max_kbps': 100, 'type':
  'bandwidth_limit', 'id': '403c3298-d51a-41d3-99f2-bd5cbc698448',
  'max_burst_kbps': 0, 'qos_policy_id': '58c5f284-bc0d-420d-9aac-
  69b3e7cc6e0c'}, {'dscp_mark': 14, 'type': 'dscp_marking', 'id':
  '5c157ba8-0168-4ca9-abbf-93a0e7483f48', 'qos_policy_id': '58c5f284
  -bc0d-420d-9aac-69b3e7cc6e0c'}], 'tenant_id':
  u'1cbe81ac17ed4703988cd390d4f0dc39', 'shared': False, 'id': '58c5f284
  -bc0d-420d-9aac-69b3e7cc6e0c', 'name': u'testpolicy-0'}

  Since we can attach only one rule of each type, this format is little 
confusing, 
  having rules key in dict can be mistaken as supporting multiple rules by 
policy. 

  so relevant format would be

  {'description': '', 
   'bandwidth-limit-rule': {}
   'dscp-marking-rule': {}
   'policy-id' : ''
   'project-id': ''
  }

  and other minor thing, same qos-policy-id can be seen thrice in same
  data, we have to specify policy while creating rule of any type, so it
  would make sense to pass qos-policy-id just once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616253/+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 1613542] Re: tempest.conf doesn't contain $project in [service_available] section

[OpenStack Infra]

Reviewed:  https://review.openstack.org/359056
Committed: 
https://git.openstack.org/cgit/openstack/vmware-nsx/commit/?id=e5b608ac1d51e645fe72552bbbf6611aaf22236c
Submitter: Jenkins
Branch:master

commit e5b608ac1d51e645fe72552bbbf6611aaf22236c
Author: AvnishPal 
Date:   Tue Aug 23 14:37:34 2016 +0530

Fix tempest.conf generation

[service_available] is not being generated. This patch fixes it.

Change-Id: I2813ff9c483b5bc97600d2b33decfcff9b3bda33
Closes-Bug: #1613542


** Changed in: vmware-nsx
   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/1613542

Title:
  tempest.conf doesn't contain $project in [service_available] section

Status in Aodh:
  Fix Released
Status in Ceilometer:
  In Progress
Status in ec2-api:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Ironic Inspector:
  In Progress
Status in OpenStack Identity (keystone):
  Invalid
Status in Magnum:
  Fix Released
Status in neutron:
  New
Status in OpenStack Data Processing ("Sahara") sahara-tests:
  In Progress
Status in vmware-nsx:
  Fix Released

Bug description:
  When generating the tempest conf, the tempest plugins need to register the 
config options.
  But for the [service_available] section, ceilometer (and the other mentioned 
projects) doesn't register any value so it's missng in the tempest sample 
config.

  Steps to reproduce:

  $ tox -egenconfig
  $ source .tox/genconfig/bin/activate
  $ oslo-config-generator --config-file 
.tox/genconfig/lib/python2.7/site-packages/tempest/cmd/config-generator.tempest.conf
 --output-file tempest.conf.sample

  Now check the [service_available] section from tempest.conf.sample

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1613542/+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 1613542] Re: tempest.conf doesn't contain $project in [service_available] section

[Steve Martinelli]

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

Title:
  tempest.conf doesn't contain $project in [service_available] section

Status in Aodh:
  Fix Released
Status in Ceilometer:
  In Progress
Status in ec2-api:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Ironic Inspector:
  In Progress
Status in OpenStack Identity (keystone):
  Invalid
Status in Magnum:
  Fix Released
Status in neutron:
  New
Status in OpenStack Data Processing ("Sahara") sahara-tests:
  In Progress
Status in vmware-nsx:
  In Progress

Bug description:
  When generating the tempest conf, the tempest plugins need to register the 
config options.
  But for the [service_available] section, ceilometer (and the other mentioned 
projects) doesn't register any value so it's missng in the tempest sample 
config.

  Steps to reproduce:

  $ tox -egenconfig
  $ source .tox/genconfig/bin/activate
  $ oslo-config-generator --config-file 
.tox/genconfig/lib/python2.7/site-packages/tempest/cmd/config-generator.tempest.conf
 --output-file tempest.conf.sample

  Now check the [service_available] section from tempest.conf.sample

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1613542/+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 1616547] [NEW] qos: rule api definition shouldn't include tenant_id

[Isaku Yamahata]

Public bug reported:

QoS rule doesn't have tenant_id accroding to db model and ovo object.
On the other hand, neutron/extension/qos.py defines tenant_id in rule.

the changeset of 4ee9eebd7dd5ed7c87d481eda500b664ae564644 and the change id of 
If9c7a7b9b8a5d2367d8f3225fbf07d8e3ec8865d
introduced it. But it seems accidental.

** Affects: neutron
 Importance: Undecided
 Assignee: Isaku Yamahata (yamahata)
 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/1616547

Title:
  qos: rule api definition shouldn't include tenant_id

Status in neutron:
  In Progress

Bug description:
  QoS rule doesn't have tenant_id accroding to db model and ovo object.
  On the other hand, neutron/extension/qos.py defines tenant_id in rule.

  the changeset of 4ee9eebd7dd5ed7c87d481eda500b664ae564644 and the change id 
of If9c7a7b9b8a5d2367d8f3225fbf07d8e3ec8865d
  introduced it. But it seems accidental.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616547/+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 1616539] [NEW] architecture not validated in "openstack image create"

[Gaby Beitler]

Public bug reported:

On Liberty

 

gbeitler@gaby-dell:[admin@Default/admin (v3)]~> openstack image create --public 
--container-format bare --disk-format qcow2 --min-disk 2 --min-ram 512 --file 
/home/images/SLES12SP1-cloudimage.qcow2 SLES12SP1-x86_64
+--+--+
| Field| Value|
+--+--+
| checksum | fcdeb8b10730ac96bccc9a121ee030f4 |
| container_format | bare |
| created_at   | 2016-08-02T20:51:45Z |
| disk_format  | qcow2|
| file | /v2/images/e7f289aa-e689-4f0a-a0a0-43f341986fd5/file |
| id   | e7f289aa-e689-4f0a-a0a0-43f341986fd5 |
| min_disk | 2|
| min_ram  | 512  |
| name | SLES12SP1-x86_64 |
| owner| f7ed231f244b4b2db8b1e580f36e1580 |
| protected| False|
| schema   | /v2/schemas/image|
| size | 362847744|
| status   | active   |
| updated_at   | 2016-08-02T20:51:51Z |
| virtual_size | None |
| visibility   | public   |
+--+--+

gbeitler@gaby-dell:[admin@Default/admin (v3)]~> openstack image set --name 
SLES12-SP1 --architecture x96_64 --os-distro sles --os-version 12.1 
SLES12SP1-x86_64
+--+--+
| Field| Value|
+--+--+
| architecture | x96_64   |
| checksum | fcdeb8b10730ac96bccc9a121ee030f4 |
| container_format | bare |
| created_at   | 2016-08-02T20:51:45Z |
| disk_format  | qcow2|
| file | /v2/images/e7f289aa-e689-4f0a-a0a0-43f341986fd5/file |
| id   | e7f289aa-e689-4f0a-a0a0-43f341986fd5 |
| min_disk | 2|
| min_ram  | 512  |
| name | SLES12-SP1   |
| os_distro| sles |
| os_version   | 12.1 |
| owner| f7ed231f244b4b2db8b1e580f36e1580 |
| protected| False|
| schema   | /v2/schemas/image|
| size | 362847744|
| status   | active   |
| tags | []   |
| updated_at   | 2016-08-02T20:53:00Z |
| virtual_size | None |
| visibility   | public   |
+--+--+
gbeitler@gaby-dell:[admin@Default/admin (v3)]~> openstack server create \
> --flavor m1.smaller \
> --image SLES12-SP1 \
> vm01

Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and 
attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-5fc1ad67-86ad-4a69-b7f4-905861a8f2fc)


 

gbeitler@gaby-dell:[admin@Default/admin (v3)]~> openstack image set --name 
SLES12-SP1 --architecture x86_64 --os-distro sles --os-version 12.1 SLES12-SP1
+--+--+
| Field| Value|
+--+--+
| architecture | x86_64   |
| checksum | fcdeb8b10730ac96bccc9a121ee030f4 |
| container_format | bare |
| created_at   | 2016-08-02T20:51:45Z |
| disk_format  | qcow2 

[Yahoo-eng-team] [Bug 1615718] Re: Load balancer create failed when dns extension is loaded

[Miguel Lavalle]

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

We have a fix in-flight for this:
https://review.openstack.org/#/c/346961/

** This bug has been marked a duplicate of bug 1605336
   Neutron loadbalancer VIP port fails to create

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

Title:
  Load balancer create failed when dns extension is loaded

Status in neutron:
  Confirmed

Bug description:
  when the dns extension enabled via ml2_conf.ini , the LB could not
  create because of the below Error

  in create port of loadbalancer_dbv2.py does not supply 'dns_name' as part of 
the port attributes
  
https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py#L99

  
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/extensions/dns_integration.py#L79
  at 79 neutron throws the KeyError for 'dns_name'
  Since during port_create 
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/api/v2/base.py", line 485, in 
do_create
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mreturn obj_creator(request.context, **kwargs)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/opt/stack/neutron-lbaas/neutron_lbaas/services/loadbalancer/plugin.py", line 
691, in create_loadbalancer
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mallocate_vip=not driver.load_balancer.allocates_vip)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/opt/stack/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py", 
line 301, in create_loadbalancer
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mcontext.session.flush()
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mself.force_reraise()
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00msix.reraise(self.type_, self.value, self.tb)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/opt/stack/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py", 
line 293, in create_loadbalancer
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mvip_address)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/opt/stack/neutron-lbaas/neutron_lbaas/db/loadbalancer/loadbalancer_dbv2.py", 
line 110, in _create_port_for_load_balancer
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mport = self._core_plugin.create_port(context, {'port': 
port_data})
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/plugins/ml2/plugin.py", line 
1163, in create_port
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mresult, mech_context = self._create_port_db(context, port)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/plugins/ml2/plugin.py", line 
1134, in _create_port_db
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mself.extension_manager.process_create_port(context, attrs, 
result)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/plugins/ml2/managers.py", 
line 894, in process_create_port
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mdata, result)
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File "/opt/stack/neutron/neutron/plugins/ml2/managers.py", 
line 869, in _call_on_ext_drivers
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m{'name': driver.name, 'method': method_name})
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00mself.force_reraise()
  ^[[01;31m2016-08-22 05:13:28.941 TRACE neutron.api.v2.resource 
^[[01;35m^[[00m  File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  ^[[01;31m2016-08-22 05:13:28.941 TRACE 

[Yahoo-eng-team] [Bug 1616498] [NEW] test_auto_allocate_network failing at really high rate

[Sean Dague]

Public bug reported:

This is a place holder bug to track a really high failure rate with
test_auto_allocate_network

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

Title:
  test_auto_allocate_network failing at really high rate

Status in OpenStack Compute (nova):
  New

Bug description:
  This is a place holder bug to track a really high failure rate with
  test_auto_allocate_network

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1616498/+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 1616480] [NEW] Creation of vlan transparent network fails with SR-IOV mechanism driver

[Erik Colnick]

Public bug reported:

When the SR-IOV mechanism driver (sriovnicswitch) is included in the
configured list of mechanism_drivers in ml2_conf.ini, attempts to create
a vlan transparent network ('neutron net-create --vlan-transparent True
') fail.  As the SR-IOV mechanism driver does not impact vlan
transparency support, it should override the check_vlan_transparency
method inherited from the MechanismDriver base class and return True for
that mechod.

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

Title:
  Creation of vlan transparent network fails with SR-IOV mechanism
  driver

Status in neutron:
  New

Bug description:
  When the SR-IOV mechanism driver (sriovnicswitch) is included in the
  configured list of mechanism_drivers in ml2_conf.ini, attempts to
  create a vlan transparent network ('neutron net-create --vlan-
  transparent True ') fail.  As the SR-IOV mechanism driver does
  not impact vlan transparency support, it should override the
  check_vlan_transparency method inherited from the MechanismDriver base
  class and return True for that mechod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616480/+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 1554152] Re: pollinate fails in many circumstances, cloud-init reports that failure, maas reports node failed deployment

[Launchpad Bug Tracker]

This bug was fixed in the package pollinate - 4.21-0ubuntu1~14.04

---
pollinate (4.21-0ubuntu1~14.04) trusty-proposed; urgency=medium

  [ Dustin Kirkland ]
  * pollinate:
- fix broken printing of binary data, this was breaking check_pollen
  nagios scripts on the server

  [ Junien Fridrick ]
  * entropy.ubuntu.com.pem:
- simplify CA cert to just the DigiCert chain (drop GoDaddy)

pollinate (4.20-0ubuntu1) yakkety; urgency=medium

  * debian/control:
- drop the anerd references, hasn't existed in basically forever
- update description
- add dummy | dh-apparmor dependency to get this building on precise,
  where dh-systemd doesn't exist
- drop run-one dependency, no longer needed
- make the bsdutils dependency (for logger) explicit, add epoch
  * debian/rules:
- use systemd, when possible
  * pollinate:
- fix breakage on older (trusty, precise) Ubuntu, where logger does not
  support --id=[ID]; check version of bsdutils (provides logger) to
  ensure that it's at least ubuntu wily
- cloud-init version string
  * debian/pollinate.service, debian/pollinate.upstart:
- improve the init messages logged

pollinate (4.19-0ubuntu1) yakkety; urgency=medium

  [ Martin Pitt ]
  * debian/pollinate.service: Move installation from network.target to
multi-user.target. network.target is too early and causes dependency loops
with e. g. NFS. (LP: #1576333)
  * debian/pollinate.preinst: Clean up old enablement symlink on upgrade. This
needs to be kept until after 18.04 LTS.

pollinate (4.18-0ubuntu1) yakkety; urgency=medium

  * debian/pollinate.service:
- move to later in boot, after network starts, but before ssh starts

pollinate (4.17-0ubuntu1) yakkety; urgency=medium

  * debian/pollinate.service:
- use the right flag file for LP: #1578833

pollinate (4.16-0ubuntu1) yakkety; urgency=medium

  [ Martin Pitt ]
  * Don't run pollinate.service in containers (as containers can't and should
not write the host's random pool) and when we already have a saved random
seeds (i. e. only on first boot). (LP: #1578833)
  * Bump Standards-Version to 3.9.8 (no changes needed).

  [ Dustin Kirkland ]
  * pollinate: use timeout(1) to limit curl, related to LP: #1578833

pollinate (4.15-0ubuntu1) xenial; urgency=medium

  * pollinate: LP: #1555362
- log the right pid

pollinate (4.14-0ubuntu1) xenial; urgency=medium

  * pollinate, pollinate.1: LP: #1554152
- change the failure mode of pollinate, so as to more cleanly
  tolerate network failures
- add a --strict option to re-enable the previous behavior,
  ie, strictly exit non-zero if pollinate fails for any reason
- we've always promised that pollinate would operate on a best-effort
  basis, improving the prng seeding when possible, but failing
  gracefully when not possible; as such, we've made good on the first
  half of that promise, however, the latter half has proven
  troublesome;  this is due to the fact that if pollinate exits
  non-zero, then its callers (cloud-init, maas, etc.) may well
  interpret the behavior strictly as a failure to boot the system,
  when in fact that's not the case;  instead, we'll clearly print
  a warning to syslog, and we'll retry the seeding on next pollinate
  service start (e.g. a reboot);  moreover, we'll carry a --strict
  flag in the case that users want to opt into the previous behavior

pollinate (4.13-0ubuntu1) wily; urgency=medium

  [ Robie Basak ]
  * entropy.ubuntu.com.pem:
- Add "DigiCert Global Root CA" certificate from ca-certificates
  package to entropy.ubuntu.com.pem. This is required to correctly
  verify against the new entropy.ubuntu.com SSL certificate.

pollinate (4.12-0ubuntu1) wily; urgency=medium

  * pollinate:
- add cpu hardware model to user agent
  * entropy.ubuntu.com.pem:
- entropy.ubuntu.com SSL is coming up for renewal on 2015-09-15
- update the certs for the pollinate package
- Note that this changes the issuing CA to DigiCert, which requires
  a new intermediary.

 -- Dustin Kirkland   Mon, 11 Jul 2016 10:52:57
-0500

** Changed in: pollinate (Ubuntu Trusty)
   Status: Fix Committed => Fix Released

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

Title:
  pollinate fails in many circumstances, cloud-init reports that
  failure, maas reports node failed deployment

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in pollinate package in Ubuntu:
  Fix Released
Status in pollinate source package in Trusty:
  Fix Released

Bug description:
  cloud-init runs pollinate via 'cc_seed_random.py' config job.

  Some points
  a.) in addition to seeding via pollinate seed_random will seed the random 
device with data from the datasource if it 

[Yahoo-eng-team] [Bug 1596922] Re: instance uuid not cleared in an ironic node

[OpenStack Infra]

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

commit 0e24e9e2ec254364ffe029226b9ae5956002df54
Author: Hironori Shiina 
Date:   Sun Jul 10 15:32:58 2016 +0900

ironic: Cleanup instance information when spawn fails

Instance information such as an instance_uuid set to an ironic node by
_add_driver_fields() is not cleared when spawning is aborted by an
exception raised before ironic starts deployment. Then, ironic node
stays AVAILABLE state with instance_uuid set. This information is not
cleared even if the instance is deleted. The ironic node cannot be
removed nor deployed again becuase instance_uuid remains.

This patch adds a method to remove the information. This method is
called if ironic doesn't need unprovisioning when an instance is
destroyed.

Change-Id: Idf5191aa1c990552ca2340856d5d5b6ac03f7539
Closes-Bug: 1596922


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

Title:
  instance uuid not cleared  in an ironic node

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===
  In nova with ironic environment, "instance UUID" still remains if nova boot
  got an error.  As a result, the ironic node cannot delete by API and deploy
  baremetal instance.

  
  Steps to reproduce
  ==
  1. create an ironic-node
  2. create an ironic-port
  3. nova boot for ironic instance with following illegal instance name.

 $ nova boot --flavor my-baremetal-agent --image $MY_IMAGE_UUID \
 --key-name default test3.141592 --nic net-id=$NET_UUID

  
  Expected result
  ===
  Nova got an error and state has changed "ERROR".  Then, tenant user deletes
  nova's instance($nova delete ).  After that, "instance UUID"
  of an ironic node should be cleared.

  
  Actual result
  =
  After $nova delete , "instance UUID" still remains into the
  ironic node database.

  $ ironic node-delete 0ea7c2e3-e5be-4052-85ac-a7b1adf0f30b
  Failed to delete node 0ea7c2e3-e5be-4052-85ac-a7b1adf0f30b: Node 
0ea7c2e3-e5be-4052-85ac-a7b1adf0f30b is associated with instance 
84911c1f-976b-4428-a509-8ab6cf04182a. (HTTP 409)

  
  Environment
  ===
  * Devstack all-in-one
  * Nova's source code is for "May 18".

  commit fe8a119e8d80de35d7f99e0c1d9a9e5095840146
  Merge: b56d861 6f2a46f
  Author: Jenkins 
  Date:   Wed May 18 23:33:00 2016 +

  Merge "Remove unused base_options param from
  _get_image_defined_bdms"

  2. Which hypervisor did you use?
 ironic

  3. Which networking type did you use?
 (For example: nova-network, Neutron with OpenVSwitch, ...)
  neutron + ML2 + openvswitch driver + linuxbridge driver

  Logs
  
  2016-06-28 21:03:04.670 ERROR nova.scheduler.utils 
[req-7db0e0e5-5d18-4a5a-9293-52dd2e0f4351 admin admin] [instance: 
84911c1f-976b-4428-a509-8ab6cf04182a] Error from last host: f
  urukawa-dev-ironic (node 0ea7c2e3-e5be-4052-85ac-a7b1adf0f30b): [u'Traceback 
(most recent call last):\n', u'  File 
"/opt/stack/nova/nova/compute/manager.py", line 1749, in _do_bu
  ild_and_run_instance\nfilter_properties)\n', u'  File 
"/opt/stack/nova/nova/compute/manager.py", line 1939, in 
_build_and_run_instance\ninstance_uuid=instance.uuid, reaso
  n=six.text_type(e))\n', u"RescheduledException: Build of instance 
84911c1f-976b-4428-a509-8ab6cf04182a was re-scheduled: Invalid input for 
dns_name. Reason: 'test3.141592' not a
  valid PQDN or FQDN. Reason: TLD '141592' must not be all numeric.\n"]
  2016-06-28 21:03:04.689 DEBUG oslo_messaging._drivers.amqpdriver 
[req-7db0e0e5-5d18-4a5a-9293-52dd2e0f4351 admin admin] sending reply msg_id: 
dea4917aad334ffda701e6cd23cf6a4c rep
  ly queue: reply_a163275e9821450cb6494257a3b9629f time elapsed: 
0.0230762520805s from (pid=5506) _send_reply 
/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdri
  ver.py:74
  2016-06-28 21:03:04.688 DEBUG oslo_messaging._drivers.amqpdriver 
[req-7db0e0e5-5d18-4a5a-9293-52dd2e0f4351 admin admin] CALL msg_id: 
51218c1cd9ad403798f2d830d9d0abb3 exchange 'no
  va' topic 'scheduler' from (pid=5507) _send 
/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:450
  2016-06-28 21:03:04.741 DEBUG oslo_messaging._drivers.amqpdriver [-] received 
reply msg_id: 51218c1cd9ad403798f2d830d9d0abb3 from (pid=5507) __call__ 
/usr/local/lib/python2.7/dis
  t-packages/oslo_messaging/_drivers/amqpdriver.py:298
  2016-06-28 21:03:04.743 WARNING nova.scheduler.utils 
[req-7db0e0e5-5d18-4a5a-9293-52dd2e0f4351 admin admin] Failed to 

[Yahoo-eng-team] [Bug 1616442] [NEW] SRIOV agent error when VM booted with direct-physical port

[Eran Kuris]

Public bug reported:

When assigning neutron port to PF (neutron port type - direct-physical )
the vm is booted and active but there is errors in sriov agent log 
attached  file with the errors 

Version-Release number of selected component (if applicable):
RHOS-10 
[root@controller1 ~(keystone_admin)]# rpm -qa |grep neutron 
python-neutron-lib-0.3.0-0.20160803002107.405f896.el7ost.noarch
openstack-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
puppet-neutron-9.1.0-0.20160813031056.7cf5e07.el7ost.noarch
python-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
python-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
python-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
openstack-neutron-ml2-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-metering-agent-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-openvswitch-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
python-neutronclient-5.0.0-0.20160812094704.ec20f7f.el7ost.noarch
openstack-neutron-common-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
[root@controller1 ~(keystone_admin)]# rpm -qa |grep nova
python-novaclient-5.0.1-0.20160724130722.6b11a1c.el7ost.noarch
openstack-nova-api-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
puppet-nova-9.1.0-0.20160813014843.b94f0a0.el7ost.noarch
openstack-nova-common-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-novncproxy-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-conductor-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
python-nova-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-scheduler-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-cert-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-console-14.0.0-0.20160817225441.04cef3b.el7ost.noarch

How reproducible:


Steps to Reproduce:
1.deploy SRIOV setup and set PF functionality  you can use guide : 
https://docs.google.com/document/d/1qQbJlLI1hSlE4uwKpmVd0BoGSDBd8Z0lTzx5itQ6WL0/edit#
2.boot vm & assign it to PF 
3.check in compute node sriov agent log

** Affects: neutron
 Importance: Undecided
 Status: New

** Attachment added: "sriov agent log"
   
https://bugs.launchpad.net/bugs/1616442/+attachment/4727004/+files/sriov%20agent%20log

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

Title:
  SRIOV agent error when VM booted with direct-physical port

Status in neutron:
  New

Bug description:
  When assigning neutron port to PF (neutron port type - direct-physical )
  the vm is booted and active but there is errors in sriov agent log 
  attached  file with the errors 

  Version-Release number of selected component (if applicable):
  RHOS-10 
  [root@controller1 ~(keystone_admin)]# rpm -qa |grep neutron 
  python-neutron-lib-0.3.0-0.20160803002107.405f896.el7ost.noarch
  openstack-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  puppet-neutron-9.1.0-0.20160813031056.7cf5e07.el7ost.noarch
  python-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
  python-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
  python-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
  openstack-neutron-ml2-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-metering-agent-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-openvswitch-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  python-neutronclient-5.0.0-0.20160812094704.ec20f7f.el7ost.noarch
  openstack-neutron-common-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
  [root@controller1 ~(keystone_admin)]# rpm -qa |grep nova
  python-novaclient-5.0.1-0.20160724130722.6b11a1c.el7ost.noarch
  openstack-nova-api-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  puppet-nova-9.1.0-0.20160813014843.b94f0a0.el7ost.noarch
  openstack-nova-common-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-novncproxy-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-conductor-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  python-nova-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-scheduler-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-cert-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-console-14.0.0-0.20160817225441.04cef3b.el7ost.noarch

  How reproducible:

  
  Steps to Reproduce:
  1.deploy SRIOV setup and set PF functionality  you can use guide : 
  
https://docs.google.com/document/d/1qQbJlLI1hSlE4uwKpmVd0BoGSDBd8Z0lTzx5itQ6WL0/edit#
  2.boot vm & assign it to PF 
  3.check in compute node sriov agent log

To manage notifications about this bug go to:

[Yahoo-eng-team] [Bug 1616424] [NEW] Keystone OAuth1 doesn't handle invalid request properly

[Dave Chen]

Public bug reported:

For the access token request,


- If the signature is not valid, it will raise TypeError exception.

2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/common/wsgi.py", line 227, in __call__
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result = 
method(req, **params)
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/controllers.py", line 309, in create_access_token
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params = 
oauth1.extract_non_oauth_params(b)
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for k, 
v in params if not k.startswith('oauth_')}
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType' 
object is not iterable
2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi

- If the provided consumer does not exist, it will throw
NotImplementedError exception to show that dummy_client is not
implemented.

All these exception is not properly handled, end user doens't know
anything from these exception message. It should be Unauthorized
exception raised.

** Affects: keystone
 Importance: Undecided
 Assignee: Dave Chen (wei-d-chen)
 Status: New

** Description changed:

- For the access token request, if the signature is not valid, it will
- raise TypeError exception.
+ For the access token request,
+ 
+ 
+ - If the signature is not valid, it will raise TypeError exception.
  
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/common/wsgi.py", line 227, in __call__
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result = 
method(req, **params)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/controllers.py", line 309, in create_access_token
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params = 
oauth1.extract_non_oauth_params(b)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for 
k, v in params if not k.startswith('oauth_')}
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType' 
object is not iterable
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi
  
+ - If the provided consumer does not exist, it will throw
+ NotImplementedError exception to show that dummy_client is not
+ implemented.
  
- If the provided consumer does not exist, it will throw NotImplementedError 
exception to show that dummy_client is not implemented.
- 
- 
- All these exception is not properly handled, end user doens't know anything 
from these exception message. It should be Unauthorized exception raised.
+ All these exception is not properly handled, end user doens't know
+ anything from these exception message. It should be Unauthorized
+ exception raised.

** Changed in: keystone
 Assignee: (unassigned) => Dave Chen (wei-d-chen)

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

Title:
  Keystone OAuth1 doesn't handle invalid request properly

Status in OpenStack Identity (keystone):
  New

Bug description:
  For the access token request,

  
  - If the signature is not valid, it will raise TypeError exception.

  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/common/wsgi.py", line 227, in __call__
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi result = 
method(req, **params)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/controllers.py", line 309, in create_access_token
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi params = 
oauth1.extract_non_oauth_params(b)
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi   File 
"./keystone/oauth1/core.py", line 108, in extract_non_oauth_params
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi return {k: v for 
k, v in params if not k.startswith('oauth_')}
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi TypeError: 'NoneType' 
object is not iterable
  2016-08-23 16:45:19.705 5202 TRACE keystone.common.wsgi

  - If the provided consumer does not exist, it will throw
  NotImplementedError exception to show that dummy_client is not
  implemented.

  All these exception is not properly handled, end user doens't know
  anything from these exception message. It should be Unauthorized
  exception raised.

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

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

[Yahoo-eng-team] [Bug 1616416] [NEW] The result of qos-bandwidth-limit-rule-show is different from help

[QunyingRan]

Public bug reported:

In master branch
I add '-F id' in command qos-bandwidth-limit-rule-show, the prompt information 
is:show_bandwidth_limit_rule() got an unexpected keyword argument 'fields',  
but '-F' is in help informations. 

neutron qos-bandwidth-limit-rule-show  c26581b0-de0d-4cf7-b14a-6cb3af3a209a 
policy1 -F id
show_bandwidth_limit_rule() got an unexpected keyword argument 'fields'

but '-F' in help informations:

[root@devstack162 devstack]# neutron help qos-bandwidth-limit-rule-show
usage: neutron qos-bandwidth-limit-rule-show [-h]
 [-f {json,shell,table,value,yaml}]
 [-c COLUMN]
 [--max-width ]
 [--noindent] [--prefix PREFIX]
 [--request-format {json}] [-D]
 [-F FIELD]
 BANDWIDTH_LIMIT_RULE QOS_POLICY

Show information about the given qos bandwidth limit rule.

positional arguments:
  BANDWIDTH_LIMIT_RULE  ID of bandwidth_limit_rule to look up.
  QOS_POLICYID or name of the QoS policy.

optional arguments:
  -h, --helpshow this help message and exit
  --request-format {json}
DEPRECATED! Only JSON request format is supported.
  -D, --show-detailsShow detailed information.
  -F FIELD, --field FIELD
Specify the field(s) to be returned by server. You can
repeat this option.

** Affects: neutron
 Importance: Undecided
 Assignee: QunyingRan (ran-qunying)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => QunyingRan (ran-qunying)

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

Title:
  The result of qos-bandwidth-limit-rule-show is different from help

Status in neutron:
  New

Bug description:
  In master branch
  I add '-F id' in command qos-bandwidth-limit-rule-show, the prompt 
information is:show_bandwidth_limit_rule() got an unexpected keyword argument 
'fields',  but '-F' is in help informations. 

  neutron qos-bandwidth-limit-rule-show  c26581b0-de0d-4cf7-b14a-6cb3af3a209a 
policy1 -F id
  show_bandwidth_limit_rule() got an unexpected keyword argument 'fields'

  but '-F' in help informations:

  [root@devstack162 devstack]# neutron help qos-bandwidth-limit-rule-show
  usage: neutron qos-bandwidth-limit-rule-show [-h]
   [-f 
{json,shell,table,value,yaml}]
   [-c COLUMN]
   [--max-width ]
   [--noindent] [--prefix PREFIX]
   [--request-format {json}] [-D]
   [-F FIELD]
   BANDWIDTH_LIMIT_RULE QOS_POLICY

  Show information about the given qos bandwidth limit rule.

  positional arguments:
BANDWIDTH_LIMIT_RULE  ID of bandwidth_limit_rule to look up.
QOS_POLICYID or name of the QoS policy.

  optional arguments:
-h, --helpshow this help message and exit
--request-format {json}
  DEPRECATED! Only JSON request format is supported.
-D, --show-detailsShow detailed information.
-F FIELD, --field FIELD
  Specify the field(s) to be returned by server. You can
  repeat this option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616416/+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 1615502] Re: LBAAS - housekeeping serive does not cleanup stale amphora VMs

[Elena Ezhova]

This is a bug in octavia, not in neutron-lbaas.

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

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

Title:
  LBAAS - housekeeping serive does not cleanup stale amphora VMs

Status in neutron:
  Invalid
Status in octavia:
  New

Bug description:
  1.Initially there were no spare VMs since the “spare_amphora_pool_size = 
0”
   .

   [house_keeping]
  # Pool size for the spare pool
  spare_amphora_pool_size = 0

  
  stack@hlm:~/scratch/ansible/next/hos/ansible$ nova list --all
  WARNING: Option "--all_tenants" is deprecated; use "--all-tenants"; this 
option will be removed in novaclient 3.3.0.
  
+--+--+--+++-+---+
  | ID   | Name 
| Tenant ID| Status | Task State | Power State 
| Networks  |
  
+--+--+--+++-+---+
  | 91eef324-0c51-4b91-8a54-e16abdb64e55 | vm1  
| d15f2abc106740499a453260ae6522f3 | ACTIVE | -  | Running 
| n1=4.5.6.5|
  | 7d85921c-e7d9-4b70-9023-0478c66b7e7c | vm2  
| d15f2abc106740499a453260ae6522f3 | ACTIVE | -  | Running 
| n1=4.5.6.6|
  
+--+--+--+++-+---+

  2.  Change the spare pool size to 1 and restart Octavia-
  housekeeping service. Spare Amphora VM gets created as below.

  
  stack@hlm:~/scratch/ansible/next/hos/ansible$  nova list --all
  WARNING: Option "--all_tenants" is deprecated; use "--all-tenants"; this 
option will be removed in novaclient 3.3.0.
  
+--+--+--+++-+---+
  | ID   | Name 
| Tenant ID| Status | Task State | Power State 
| Networks  |
  
+--+--+--+++-+---+
  | 6a1101cd-d9d3-4c8e-aa1d-0790f7f4ac8b | 
amphora-18f4d90f-fe6e-4085-851e-7571cba0c65a | a5e6e87d402847e7b4210e035a0fceec 
| ACTIVE | -  | Running | OCTAVIA-MGMT-NET=100.74.25.13 |
  | 91eef324-0c51-4b91-8a54-e16abdb64e55 | vm1  
| d15f2abc106740499a453260ae6522f3 | ACTIVE | -  | Running 
| n1=4.5.6.5|
  | 7d85921c-e7d9-4b70-9023-0478c66b7e7c | vm2  
| d15f2abc106740499a453260ae6522f3 | ACTIVE | -  | Running 
| n1=4.5.6.6|
  
+--+--+--+++-+---+

  3.  Now change the spare pool size to 0 and restart Octavia-
  housekeeping service. Spare Amphora VM does not get deleted.

  stack@hlm:~/scratch/ansible/next/hos/ansible$  nova list --all
  WARNING: Option "--all_tenants" is deprecated; use "--all-tenants"; this 
option will be removed in novaclient 3.3.0.
  
+--+--+--+++-+---+
  | ID   | Name 
| Tenant ID| Status | Task State | Power State 
| Networks  |
  
+--+--+--+++-+---+
  | 6a1101cd-d9d3-4c8e-aa1d-0790f7f4ac8b | 
amphora-18f4d90f-fe6e-4085-851e-7571cba0c65a | a5e6e87d402847e7b4210e035a0fceec 
| ACTIVE | -  | Running | OCTAVIA-MGMT-NET=100.74.25.13 |
  | 91eef324-0c51-4b91-8a54-e16abdb64e55 | vm1  
| d15f2abc106740499a453260ae6522f3 | ACTIVE | -  | Running 
| n1=4.5.6.5|
  | 

[Yahoo-eng-team] [Bug 1616411] [NEW] the result is not expected from the command "neutron qos-policy-show policy -F id"

[QunyingRan]

Public bug reported:

In master branch, I only want to know the policy id fron one policy ,
but rules column appeared in results.

[root@devstack162 devstack]# neutron qos-policy-show policy1  -F id
+---+--+
| Field | Value|
+---+--+
| id| 346f506b-1d35-4e4e-9ce5-500e8a69120b |
| rules |  |
+---+--+

** Affects: neutron
 Importance: Undecided
 Assignee: QunyingRan (ran-qunying)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => QunyingRan (ran-qunying)

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

Title:
  the result is not expected from the command "neutron qos-policy-show
  policy  -F id"

Status in neutron:
  New

Bug description:
  In master branch, I only want to know the policy id fron one policy ,
  but rules column appeared in results.

  [root@devstack162 devstack]# neutron qos-policy-show policy1  -F id
  +---+--+
  | Field | Value|
  +---+--+
  | id| 346f506b-1d35-4e4e-9ce5-500e8a69120b |
  | rules |  |
  +---+--+

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616411/+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 1613542] Re: tempest.conf doesn't contain $project in [service_available] section

[Vitaly Gridnev]

** No longer affects: sahara

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

Title:
  tempest.conf doesn't contain $project in [service_available] section

Status in Aodh:
  Fix Released
Status in Ceilometer:
  In Progress
Status in ec2-api:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Ironic Inspector:
  In Progress
Status in OpenStack Identity (keystone):
  In Progress
Status in Magnum:
  Fix Released
Status in neutron:
  New
Status in OpenStack Data Processing ("Sahara") sahara-tests:
  New
Status in vmware-nsx:
  In Progress

Bug description:
  When generating the tempest conf, the tempest plugins need to register the 
config options.
  But for the [service_available] section, ceilometer (and the other mentioned 
projects) doesn't register any value so it's missng in the tempest sample 
config.

  Steps to reproduce:

  $ tox -egenconfig
  $ source .tox/genconfig/bin/activate
  $ oslo-config-generator --config-file 
.tox/genconfig/lib/python2.7/site-packages/tempest/cmd/config-generator.tempest.conf
 --output-file tempest.conf.sample

  Now check the [service_available] section from tempest.conf.sample

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1613542/+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 1616388] [NEW] [RFE] Provide separation between VNIC and VIF in core Nova and Neutron

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

It might be easier to view the VM plugging process in OpenStack as composed of 
three partners, attributes of a Neutron port:
* The VIF edge (plugging in a TAP device into a bridge, configuring a NIC's 
VEB, some other form of virtual port manipulation…)
(The VNIC edge (hypervisor config, emulated hardware model, etc.)
* The transport mechanism (vhost-net, vhost-user, vfio for SR-IOV, etc.)

Currently, there are a few places in core OpenStack that conflate the
three concepts. For example, nova/network/model.py has VNIC_TYPE_* that
denote the different methods for connecting to the hardware, but
VIF_MODEL_* denotes different hardware emulation settings for the
hypervisors.

Compounding this problem is the current plugging method with libvirt.
The plugging logic for many mechanism drivers moved into libvirt,
meaning that nova passes both VNIC and VIF information to libvirt in
some cases and not in others. The OS-VIF library is a step away from
that direction: https://blueprints.launchpad.net/nova/+spec/os-vif-
library

This RFE requests a mechanism to allow for more granularity in the
plugging logic semantics: a mechanism driver should not need to re-
invent common plugging code on the VIF or VNIC side. For example, just
as primitives for plugging a netdev into a bridge should be part of the
OS-VIF library, so should the VNIC configuration by the hypervisor be as
cleanly abstracted and separated as possible.

Initially, the hypervisor driver should receive both VNIC and VIF
objects and have logic to decide to generate the required VM
configuration. For example if an OVS VIF and vhost-net VNIC is passed to
the libvirt driver, it generates xml to handle the bridge and VM
plugging. In the case a driver requires another method of plugging, but
can re-use the OVS VIF or the VNIC code it should be able to do so.

Netronome is willing to devote resources to this project in order to
improve the OpenStack infrastructure and reduce code duplication.

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: neutron nova rfe
-- 
[RFE] Provide separation between VNIC and VIF in core Nova and Neutron
https://bugs.launchpad.net/bugs/1616388
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to OpenStack Compute (nova).

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

[Yahoo-eng-team] [Bug 1613466] Re: Update credential to "ec2" type accepts a credential without the project set

[OpenStack Infra]

Reviewed:  https://review.openstack.org/357950
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=8144e28336e1c9bf2128409172f48b3ea1cd1ee5
Submitter: Jenkins
Branch:master

commit 8144e28336e1c9bf2128409172f48b3ea1cd1ee5
Author: Rodrigo Duarte Sousa 
Date:   Fri Aug 19 11:54:57 2016 -0300

Fix credential update to ec2 type

It was possible to create a credential without providing a project_id
and later updating it to the ec2 type.

This patch fixes the issue by adding a manual checking in the
manager layer since it needs to check the old credential contents
prior failing the request.

Change-Id: I1eb28a46c89e17d9c990cc798867d1a59714fe5f
Closes-Bug: #1613466


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

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

Title:
  Update credential to "ec2" type accepts a credential without the
  project set

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  In the credentials API schema validation [1] is mandatory to include a
  project when creating a credential of the "ec2" type, but we can
  create a credential from a different type and update it to "ec2"
  without providing a project [2].

  [1] 
https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L29-L55
  [2] 
https://github.com/openstack/keystone/blob/master/keystone/credential/schema.py#L57-L62

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1613466/+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 1609071] Re: test_list_pagination_with_href_links fails intermittently

[Ihar Hrachyshka]

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

Armando, that other failure you identified is for another test, and is
indeed a duplicate of what you marked the bug a duplicate for. But THIS
bug is different, we should not make it a dup of 1614964.

** This bug is no longer a duplicate of bug 1614964
   NetworksSearchCriteriaTest. test_list_pagination_with_href_links fails due 
to external networks not filtered out

** This bug has been marked a duplicate of bug 1607903
   test_list_pagination_with_marker failure in PortsSearchCriteriaTest

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

Title:
  test_list_pagination_with_href_links fails intermittently

Status in neutron:
  Confirmed

Bug description:
  http://logs.openstack.org/08/347708/2/gate/gate-neutron-dsvm-
  api/d70465a/testr_results.html.gz

  Traceback (most recent call last):
    File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_ports.py", line 
80, in test_list_pagination_with_href_links
  self._test_list_pagination_with_href_links()
    File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 485, 
in inner
  return f(self, *args, **kwargs)
    File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 476, 
in inner
  return f(self, *args, **kwargs)
    File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 663, 
in _test_list_pagination_with_href_links
  self._test_list_pagination_iteratively(self._list_all_with_hrefs)
    File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 592, 
in _test_list_pagination_iteratively
  len(expected_resources), sort_args
    File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 643, 
in _list_all_with_hrefs
  self.assertNotIn('next', prev_links)
    File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
455, in assertNotIn
  self.assertThat(haystack, matcher, message)
    File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: {u'previous': 
u'http://127.0.0.1:9696/v2.0/ports?limit=1_dir=asc_key=name=a963fff7-eaf1-4455-9597-e82528720797_reverse=True',
 u'next': 
u'http://127.0.0.1:9696/v2.0/ports?limit=1_dir=asc_key=name=a963fff7-eaf1-4455-9597-e82528720797'}
 matches Contains('next')

  or

  
  Traceback (most recent call last):
File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_networks.py", 
line 124, in test_list_pagination_with_href_links
  self._test_list_pagination_with_href_links()
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 486, 
in inner
  return f(self, *args, **kwargs)
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 477, 
in inner
  return f(self, *args, **kwargs)
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 664, 
in _test_list_pagination_with_href_links
  self._test_list_pagination_iteratively(self._list_all_with_hrefs)
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 593, 
in _test_list_pagination_iteratively
  len(expected_resources), sort_args
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 657, 
in _list_all_with_hrefs
  self.assertSameOrder(resources, reversed(resources2))
File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 516, 
in assertSameOrder
  self.assertEqual(expected[self.field], res[self.field])
File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
411, in assertEqual
  self.assertThat(observed, matcher, message)
File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 
498, in assertThat
  raise mismatch_error
  testtools.matchers._impl.MismatchError: u'123test' != u'abc1'

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1609071/+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 1616357] [NEW] The Error Response REST API GET/POST on networks is not translated

[Esha Seth]

Public bug reported:

When a GET or a POST REST API request is made to openstack neutron for
openstack/networks/v2.0/networks with invalid data then the response
message with 404 error code is not translated

Response:
 {
"NeutronError":
{
"message": "Network dcea3730-ddc6-48cf-a1e9-26cea79074d9 could not be 
found.",
"type": "NetworkNotFound",
"detail": ""
}
}

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

Title:
  The Error Response REST API GET/POST on networks is not translated

Status in neutron:
  New

Bug description:
  When a GET or a POST REST API request is made to openstack neutron for
  openstack/networks/v2.0/networks with invalid data then the response
  message with 404 error code is not translated

  Response:
   {
  "NeutronError":
  {
  "message": "Network dcea3730-ddc6-48cf-a1e9-26cea79074d9 could not be 
found.",
  "type": "NetworkNotFound",
  "detail": ""
  }
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616357/+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 1527132] Re: Small error in help_text(ICMP type and code range should 0-255) about security-rule page

[Akihiro Motoki]

-1 is a valid value which means 'ANY', so this bug is invalid.

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

** Changed in: horizon
 Assignee: Jacky_lei_zhang (lzhang1) => (unassigned)

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

Title:
  Small error in help_text(ICMP type and code range should 0-255) about
  security-rule page

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  When add a security-rule on dashboard,find help message display ICMP
  type and code value range is (-1:255),but this value range should be
  (0:255) actually

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1527132/+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 1614872] Re: delete method on auto-allocate extension returns 500

[Henry Gessau]

Client patch: https://review.openstack.org/359494

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

** Changed in: python-neutronclient
   Status: New => In Progress

** Changed in: python-neutronclient
   Importance: Undecided => Low

** Changed in: python-neutronclient
 Assignee: (unassigned) => Armando Migliaccio (armando-migliaccio)

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

Title:
  delete method on auto-allocate extension returns 500

Status in neutron:
  In Progress
Status in python-neutronclient:
  In Progress

Bug description:
  The method is not implemented correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614872/+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 1616292] Re: Create Host Aggregate need a cancel button

[venkatamahesh]

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

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

Title:
  Create Host Aggregate need a cancel button

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  In Create Host Aggregate form, no cancel button. If user want to
  cancel the operation, they have to click the panel to go back to the
  dashboard.

  The screen shot is attached。

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616292/+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 1616317] [NEW] floatingip cannot be associated even there's static route to the network

[Bali Bao]

Public bug reported:

Hi All

Currently in the neturon floating ip associate code, there is a
limitation that if the port's network is not connected to any router,
then the floating ip cannot be associated.

(neutron) floatingip-associate 52a8cbea-cc3c-4162-8a16-bf7f31a92622 
d40331e7-7c16-4ba5-ac38-44d805eb9cc0
External network cb3ac47c-60be-4754-a540-ee03e9b3668c is not reachable from 
subnet 14c83a82-ca86-45ad-93e4-a14720cfec54.  Therefore, cannot associate Port 
d40331e7-7c16-4ba5-ac38-44d805eb9cc0 with a Floating IP.
Neutron server returns request_ids: ['req-91073bb6-a54e-4a6c-8400-4499e53a940d']
(neutron) 

This behavior is right in normal case, but there is a real case will be blocked:
See the attached use case picture, we deployed a pfSense as router, the 
private-network-1 is not connected to the router but connect to the pfSense as 
the default gw. And in the router, we added a static route that any traffic 
going to the private-network-1 nexthop to pfSense. In case, we can not set the 
floating ip for the vm1.

So we suggest, when associating floating ip, neutron should not only
check the direct connected subnets, but also check the whether there're
static route can cover that port.

Thanks,

Bali

** Affects: neutron
 Importance: Undecided
 Status: New

** Attachment added: "user case with static route"
   
https://bugs.launchpad.net/bugs/1616317/+attachment/4726777/+files/fw%20topo%20after%20fw%20enabled%20vm1-ext.jpeg

** Summary changed:

- floatingip cannot be associated when there's static route to the network
+ floatingip cannot be associated even there's static route to the network

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

Title:
  floatingip cannot be associated even there's static route to the
  network

Status in neutron:
  New

Bug description:
  Hi All

  Currently in the neturon floating ip associate code, there is a
  limitation that if the port's network is not connected to any router,
  then the floating ip cannot be associated.

  (neutron) floatingip-associate 52a8cbea-cc3c-4162-8a16-bf7f31a92622 
d40331e7-7c16-4ba5-ac38-44d805eb9cc0
  External network cb3ac47c-60be-4754-a540-ee03e9b3668c is not reachable from 
subnet 14c83a82-ca86-45ad-93e4-a14720cfec54.  Therefore, cannot associate Port 
d40331e7-7c16-4ba5-ac38-44d805eb9cc0 with a Floating IP.
  Neutron server returns request_ids: 
['req-91073bb6-a54e-4a6c-8400-4499e53a940d']
  (neutron) 

  This behavior is right in normal case, but there is a real case will be 
blocked:
  See the attached use case picture, we deployed a pfSense as router, the 
private-network-1 is not connected to the router but connect to the pfSense as 
the default gw. And in the router, we added a static route that any traffic 
going to the private-network-1 nexthop to pfSense. In case, we can not set the 
floating ip for the vm1.

  So we suggest, when associating floating ip, neutron should not only
  check the direct connected subnets, but also check the whether
  there're static route can cover that port.

  Thanks,

  Bali

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