[Yahoo-eng-team] [Bug 1618319] [NEW] Invalid service catalog service: network error

[muralidharan]

Public bug reported:

When I am trying to access the dashboard from horizon it is working fine
for the keystone, glance etc.,

But Incase of Neutron I am always getting error.

Tried accessing the network section from both the admin and project tab.
Both return the error as follows:

[Tue Aug 30 05:45:23.039423 2016] [:error] [pid 3524:tid 140344693204736] Login 
successful for user "admin".
[Tue Aug 30 05:45:23.060751 2016] [:error] [pid 3525:tid 140344693204736] 
Internal Server Error: /horizon/admin/networks/
[Tue Aug 30 05:45:23.060783 2016] [:error] [pid 3525:tid 140344693204736] 
Traceback (most recent call last):
[Tue Aug 30 05:45:23.060786 2016] [:error] [pid 3525:tid 140344693204736]   
File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 132, 
in get_response
[Tue Aug 30 05:45:23.060789 2016] [:error] [pid 3525:tid 140344693204736] 
response = wrapped_callback(request, *callback_args, **callback_kwargs)
[Tue Aug 30 05:45:23.060791 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/decorators.py",
 line 36, in dec
[Tue Aug 30 05:45:23.060793 2016] [:error] [pid 3525:tid 140344693204736] 
return view_func(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060795 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/decorators.py",
 line 84, in dec
[Tue Aug 30 05:45:23.060797 2016] [:error] [pid 3525:tid 140344693204736] 
return view_func(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060799 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/decorators.py",
 line 52, in dec
[Tue Aug 30 05:45:23.060801 2016] [:error] [pid 3525:tid 140344693204736] 
return view_func(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060803 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/decorators.py",
 line 36, in dec
[Tue Aug 30 05:45:23.060805 2016] [:error] [pid 3525:tid 140344693204736] 
return view_func(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060807 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/decorators.py",
 line 84, in dec
[Tue Aug 30 05:45:23.060809 2016] [:error] [pid 3525:tid 140344693204736] 
return view_func(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060821 2016] [:error] [pid 3525:tid 140344693204736]   
File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 71, 
in view
[Tue Aug 30 05:45:23.060823 2016] [:error] [pid 3525:tid 140344693204736] 
return self.dispatch(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060825 2016] [:error] [pid 3525:tid 140344693204736]   
File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 89, 
in dispatch
[Tue Aug 30 05:45:23.060828 2016] [:error] [pid 3525:tid 140344693204736] 
return handler(request, *args, **kwargs)
[Tue Aug 30 05:45:23.060830 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/tables/views.py",
 line 159, in get
[Tue Aug 30 05:45:23.060831 2016] [:error] [pid 3525:tid 140344693204736] 
handled = self.construct_tables()
[Tue Aug 30 05:45:23.060833 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/tables/views.py",
 line 142, in construct_tables
[Tue Aug 30 05:45:23.060836 2016] [:error] [pid 3525:tid 140344693204736] 
tables = self.get_tables().values()
[Tue Aug 30 05:45:23.060838 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/tables/views.py",
 line 198, in get_tables
[Tue Aug 30 05:45:23.060840 2016] [:error] [pid 3525:tid 140344693204736] 
self._tables[self.table_class._meta.name] = self.get_table()
[Tue Aug 30 05:45:23.060843 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/tables/views.py",
 line 209, in get_table
[Tue Aug 30 05:45:23.060846 2016] [:error] [pid 3525:tid 140344693204736] 
self.table = self.table_class(self.request, **self.kwargs)
[Tue Aug 30 05:45:23.060850 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/admin/networks/tables.py",
 line 125, in __init__
[Tue Aug 30 05:45:23.060853 2016] [:error] [pid 3525:tid 140344693204736] 
'dhcp_agent_scheduler'):
[Tue Aug 30 05:45:23.060855 2016] [:error] [pid 3525:tid 140344693204736]   
File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../horizon/utils/memoized.py",
 line 90, in wrapped
[Tue Aug 30 05:45:23.060857 2016] [:error] [pid 3525:tid 140344693204736] 
value = cache[key] = 

[Yahoo-eng-team] [Bug 1616660] Re: TypeError: $options[jj].attr is not a function on Project Creation

[OpenStack Infra]

Reviewed:  https://review.openstack.org/359957
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=238d273caa0599f66dd1de049e263f49b30ba6b4
Submitter: Jenkins
Branch:master

commit 238d273caa0599f66dd1de049e263f49b30ba6b4
Author: Diana Whitten 
Date:   Wed Aug 24 12:39:26 2016 -0700

Project Creation from within Create User should work

Fix error in Themable Select Mutation Code

$options[jj] is just an HTML element, not a jQuery object, therefore
it didn't have an .attr function on it.

Change-Id: If763204737adcdb9bd0e4ae1ba0626a71770352a
Closes-bug: 1616660


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

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

Status in OpenStack Dashboard (Horizon):
  Fix Released

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 1617374] Re: openrc username project missing

[OpenStack Infra]

Reviewed:  https://review.openstack.org/361297
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=7e58caeaee2b8137ff38b8bcb8c8e6a5600bbc69
Submitter: Jenkins
Branch:master

commit 7e58caeaee2b8137ff38b8bcb8c8e6a5600bbc69
Author: David Medberry 
Date:   Fri Aug 26 11:11:45 2016 -0400

Display username/project during password request

There is a UX bug when asking for this password without providing
appropriate context. This patch fixes that.

Closes-bug: 1617374
Change-Id: Iaabc217cdbff82d7685985f52d5caa975fcf4413


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

Title:
  openrc username project missing

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  sourcing the openrc file asks for an openstack password, but doesn't
  provide any clue to the user which project or username is associated
  with the request, making answering this question a guessing game.
  Moreover, if you have also integrated your keystone with Active
  Directory LDAP (as many people do) you will also "LOCK" your AD
  account potentially due to wrong user/pass entered too many times.
  Simply display the username and project in the password query.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1617374/+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 1618187] Re: InvalidInput exceptions from DHCP RPC handler

[OpenStack Infra]

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

commit c05751a556a9124969de991ae226380b41a56502
Author: Kevin Benton 
Date:   Sat Aug 27 03:25:27 2016 -0700

Catch InvalidInput in DHCP port actions

The exception handler checking for concurrently deleted subnets
was missing InvalidInput, which comes from IPAM when a port creation
request references a subnet that doesn't exist.

This patch just catches that exception.

Change-Id: I14f9e4bddde845e3fef2b0d8649d3954ba5c93bd
Closes-Bug: #1618187


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

Title:
  InvalidInput exceptions from DHCP RPC handler

Status in neutron:
  Fix Released

Bug description:
  Normal tempest runs are filled with exceptions in the DHCP RPC handler
  when it tries to create or update a port on a network that has its
  subnet deleted at the same time:

  InvalidInput: Invalid input for operation: IP allocation requires
  subnets for network.

  
  
http://logs.openstack.org/82/346282/4/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d4ea1f6/logs/screen-q-svc.txt.gz?level=TRACE

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618187/+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 1617210] Re: ascii error occurs when getting servers test data

[xujun]

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

Title:
  ascii error occurs when getting servers test data

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  When I get servers test data in test case by calling self.servers.list(), 
ascii error occurs.
  Take a look at the data of server 3 and find the name is incorrect, which 
make ascii out range of [128] error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1617210/+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 1617749] Re: Angular template cache breaks when the template contains backslashes

[OpenStack Infra]

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

commit d580adb4dd9337ca4e3b6eaeaefffdf3f215ac19
Author: Paulo Matias 
Date:   Sat Aug 27 18:24:55 2016 -0300

Escape blackslash in the angular_escapes filter

Co-Authored-By: Tadeu Sampaio 
Closes-Bug: #1617749
Change-Id: Ic97c6f3b0e3c4c91323dcba82bfe43e252e16b1a


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

Title:
  Angular template cache breaks when the template contains backslashes

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  The angular_escapes filter [1] currently does not handle backslashes
  ('\'), therefore templates containing this character are broken (or
  have their behaviour modified) when they are cached.

  We faced this issue when deploying the LBaaSv2 dashboard [2], which
  uses ng-pattern="/^\d+$/" in multiple fields. This is transformed to
  ng-pattern=\"/^\d+$/\" when the pattern is cached (see [3]), which
  results in validator failures that block the usage of the LBaaSv2
  dashboard.

  Although the Horizon code base employs ng-pattern="/^[0-9]+$/" instead
  when a numeric validator is desired, we feel that not escaping the
  backslash is a dangerous behaviour which might cause other issues in
  the future.

  We will send in a few minutes a patch to gerrit proposing a fix for
  this issue.

  --

  Expected behaviour: It should be possible to create a new load
  balancer via the dashboard when deploying Horizon together with the
  LBaaSv2 dashboard.

  Actual behaviour: The validator fails on the "port" fields, which are
  mandatory to create a new load balancer. This blocks the creation of
  new load balancers through the dashboard.

  Steps to reproduce:
  * Deploy the environment
  * Go to Project > Networks > Load Balancers
  * Click on "Create Load Balancer"
  * Try to fill a Port in the "Listener Details" tab

  Environment:
  * OpenStack-Ansible, master branch
  * Multi-node deploy
  * "neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2" included 
in "neutron_plugin_base"

  
  --
  References

  [1]
  
https://github.com/openstack/horizon/blob/107488f2f53f55ce2b727e52b5496db47ffc21ce/horizon/templatetags/angular.py#L57

  [2] https://github.com/openstack/neutron-lbaas-
  
dashboard/blob/c68b80b0bb9f89acd46da717b360b429efade43a/neutron_lbaas_dashboard/static/dashboard/project/lbaasv2/workflow/members/members.html#L73

  [3] http://ix.io/1hqG

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1617749/+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 1481588] Re: Wrong HA router state after setting the admin_state_up to False

[OpenStack Infra]

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

commit 938937b94415bb79accb026a7bcc2d2a9d1dcf13
Author: Ann Kamyshnikova 
Date:   Wed Aug 24 20:52:47 2016 +0300

Set L3 agent standby if admin_state_up=False

If admin_state_up set to False L3 agent still shows as 'active'
in the HA router states on that agent. Current change adds check for such
case and updates HA router state from 'active' to 'standby' if
agent's admin_state_up is False.

Change-Id: Iaa800221fcfcd41e81ade5136a2a513a2cce8d5b
Closes-bug: #1481588


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

Title:
  Wrong HA router state after setting the admin_state_up to False

Status in neutron:
  Fix Released

Bug description:
  In an L3 HA Setup with multiple network nodes, we can query the agent
  hosting the Master HA router via l3-agent-list-hosting-router.

  For example
  neutron l3-agent-list-hosting-router h1
  
+--+++---+--+
  | id   | host   | admin_state_up | 
alive | ha_state |
  
+--+++---+--+
  | 05cbe1b6-5b1e-4685-9a67-e55741b2b4b6 | networknode_1  | True   | 
:-)   | active   |
  | 40cfc10c-ae96-4715-9aa9-d5af668a4c1e | networknode_2  | True   | 
:-)   | standby  |
  | 14b81831-366e-43af-8be4-50f7939981fe | networknode_3  | True   | 
:-)   | standby  |
  
+--+++---+--+

  Now if we set the admin state of networknode_1 to down (i.e., neutron
  agent-update  --admin_state_up=False), HA router would be
  deleted from the agent and one of the backup HA Routers would take
  over the role of Master.

  In such a situation, when we query the active HA router info, the
  state of the router on the agent is still shown as 'active' and is not
  updated, which could really be confusing.

  neutron l3-agent-list-hosting-router h1
  
+--+++---+--+
  | id   | host   | admin_state_up | 
alive | ha_state |
  
+--+++---+--+
  | 05cbe1b6-5b1e-4685-9a67-e55741b2b4b6 | networknode_1  | False  | 
:-)   | active   |
  | 40cfc10c-ae96-4715-9aa9-d5af668a4c1e | networknode_2  | True   | 
:-)   | active   |
  | 14b81831-366e-43af-8be4-50f7939981fe | networknode_3  | True   | 
:-)   | standby  |
  
+--+++---+--+

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1481588/+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 1599287] Re: Cleanup snat redirect rules when agent restarts after stale snat namespace is cleaned.

[OpenStack Infra]

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

commit 34e51cad42960bdb08a92d1a60a33594bdf057ba
Author: Swaminathan Vasudevan 
Date:   Tue Jul 5 13:22:04 2016 -0700

DVR: Cleanup the stale snat redirect rules in router namespace

After the stale snat namespace is deleted the snat redirect rules
in router namespace should be cleaned.

Here we are basically reading the ip rule from the router namespace
and just cleaning up all the snat redirect rules leaving the default
ones untouched.

Change-Id: Ic505a46e56d9e950bd36a1596d3f1adfb5ef5577
Closes-Bug: #1599287


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

Title:
  Cleanup snat redirect rules when agent restarts after stale snat
  namespace is cleaned.

Status in neutron:
  Fix Released

Bug description:
  When the L3 agent is dead, if the gateway is removed, the snat
  namespace and its rules are not properly cleaned when agent restarts.

  Even though the patch https://review.openstack.org/#/c/326729/
  addresses the cleanup of the snat namespace, it does not remove the
  redirect rules and the gateway device from the router namespace when
  gateway is disabled.

  When agent restarts the agent does not get the gateway data from the
  server, and so it is not possible for the agent to clean it properly.

  In order to clean the snat redirect rules, the gateway data should be
  cached to the local file system and reused later when necessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1599287/+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 1617258] Re: Nova fails to boot signed image

[OpenStack Infra]

Reviewed:  https://review.openstack.org/360411
Committed: 
https://git.openstack.org/cgit/openstack/glance/commit/?id=5663196c9c30f13a61a44ac7bfd625379d3165f4
Submitter: Jenkins
Branch:master

commit 5663196c9c30f13a61a44ac7bfd625379d3165f4
Author: Darren White 
Date:   Tue Aug 23 14:56:31 2016 +0100

Image signature base64 don't wrap lines

In the image signature documentation, base64 should not use line
wrapping (defaults to 76). Disable using -w 0. With line wrapping
enabled Nova will fail to boot the image.

Added a note to inform users to use -w 0 with Glance v1 but is
optional for v2.

DocImpact

Closes-Bug: 1617258
Change-Id: I3585c5cc90e6ea738ff7ecb5a5574cbb0e737511


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

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

Title:
  Nova fails to boot signed image

Status in Glance:
  Fix Released

Bug description:
  Description
  ===
  Nova fails to boot an image which has been signed (using glance image-create) 
which uses a base64 image signature. By default base64 uses linewrapping after 
76 characters. Disabling line wrapping with -w 0 should solve the issue by I'm 
sure there are alternatives.


  Steps to reproduce
  ==
  Following these instructions to create a signed image:

  https://github.com/openstack/glance/blob/master/doc/source/signature.rst

  But using base64 without -w 0.

  Booting the image that was created using 'nova boot' the image used
  will be the one just created and the flavor used is m1.tiny.


  Expected result
  ===
  Booting the signed image should be successful.


  Actual result
  =
  Booting the signed image fails.


  Environment
  ===
  This is using the mitaka branch.

  
  Logs & Configs
  ==
  Here is the output:

  ERROR (ClientException): 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-337f86d3-697b-40a1-ac77-0cd5211ad4ad)

  I tried uploading the Nova API log but it just gives a timeout error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1617258/+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 1618260] [NEW] Image signature base64 don't wrap lines

[OpenStack Infra]

Public bug reported:

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

commit 5663196c9c30f13a61a44ac7bfd625379d3165f4
Author: Darren White 
Date:   Tue Aug 23 14:56:31 2016 +0100

Image signature base64 don't wrap lines

In the image signature documentation, base64 should not use line
wrapping (defaults to 76). Disable using -w 0. With line wrapping
enabled Nova will fail to boot the image.

Added a note to inform users to use -w 0 with Glance v1 but is
optional for v2.

DocImpact

Closes-Bug: 1617258
Change-Id: I3585c5cc90e6ea738ff7ecb5a5574cbb0e737511

** Affects: glance
 Importance: Undecided
 Status: New


** Tags: doc glance

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

Title:
  Image signature base64 don't wrap lines

Status in Glance:
  New

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

  commit 5663196c9c30f13a61a44ac7bfd625379d3165f4
  Author: Darren White 
  Date:   Tue Aug 23 14:56:31 2016 +0100

  Image signature base64 don't wrap lines
  
  In the image signature documentation, base64 should not use line
  wrapping (defaults to 76). Disable using -w 0. With line wrapping
  enabled Nova will fail to boot the image.
  
  Added a note to inform users to use -w 0 with Glance v1 but is
  optional for v2.
  
  DocImpact
  
  Closes-Bug: 1617258
  Change-Id: I3585c5cc90e6ea738ff7ecb5a5574cbb0e737511

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1618260/+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 1618244] [NEW] Possible scale issues with neutron-fwaas requesting all tenants with firewalls after RPC failures

[Sridar Kandaswamy]

Public bug reported:

Information zzelle in conversation with njohnston

An overload is caused first by some neutron-servers crashed, secondly by
every l3-agent trying to perform a "full" process_services_sync. When we
restarted every crashed neutron-servers and purge neutron queues, we
restarted crashed neutron-servers rpc workers are still overloaded
because of full syncs.

About 60 L3Agents, with one router per L3Agent.

Key question: typically i don't understand why in full sync a l3-agents
request tenants with FWs intead of requesting its tenants with FW ?

https://github.com/openstack/neutron-
fwaas/blob/master/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py#L224

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

** Tags added: fwaas

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

Title:
  Possible scale issues with neutron-fwaas requesting all tenants with
  firewalls after RPC failures

Status in neutron:
  New

Bug description:
  Information zzelle in conversation with njohnston

  An overload is caused first by some neutron-servers crashed, secondly
  by every l3-agent trying to perform a "full" process_services_sync.
  When we restarted every crashed neutron-servers and purge neutron
  queues, we restarted crashed neutron-servers rpc workers are still
  overloaded because of full syncs.

  About 60 L3Agents, with one router per L3Agent.

  Key question: typically i don't understand why in full sync a
  l3-agents request tenants with FWs intead of requesting its tenants
  with FW ?

  https://github.com/openstack/neutron-
  
fwaas/blob/master/neutron_fwaas/services/firewall/agents/l3reference/firewall_l3_agent.py#L224

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618244/+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 1618245] [NEW] neutron X-Forwarded-Proto

[Kevin Fox]

Public bug reported:

Neutron isn't doing the X-Forwarded-Protocol header override dance on
our RDO Mitaka based cloud. After talking with the oslo devs, they
mentioned needing http_proxy_to_wsgi in the api-paste.ini

Can this please be added to the default api-paste.ini so others don't
run into this issue?

Here's an example:
https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini#L31

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

Title:
  neutron X-Forwarded-Proto

Status in neutron:
  New

Bug description:
  Neutron isn't doing the X-Forwarded-Protocol header override dance on
  our RDO Mitaka based cloud. After talking with the oslo devs, they
  mentioned needing http_proxy_to_wsgi in the api-paste.ini

  Can this please be added to the default api-paste.ini so others don't
  run into this issue?

  Here's an example:
  https://github.com/openstack/nova/blob/master/etc/nova/api-paste.ini#L31

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618245/+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 1617206] Re: OpenStack Horizon: unable to update network name/state

[Rob Cresswell]

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

This looks identical to bug #1609467. It's send the 'shared' key and
getting a policy refusal; identical to the logs here.

** This bug has been marked a duplicate of bug 1609467
   Rename Network return 403 Error

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

Title:
  OpenStack Horizon: unable to update network name/state

Status in OpenStack Dashboard (Horizon):
  New
Status in openstack-dashboard package in Juju Charms Collection:
  New

Bug description:
  The issue is hitting for tenants other than the admin. I am unable to update 
"name" or "state" of the network from the owner tenant in Horizon although able 
to update subnet for the same network, routers and VMs in the same tenant.
  From horizon, admin tenant allows to update name/state of that tenant's 
network. "policy.json" looks fine as it is allowing both admin and owner tenant 
to update networks.

  
  Right now, two workarounds are available:
  1- Use CLI to update network name/state
  2- Use admin tenant to update network name/state

  Horizon version:
  $ dpkg -l | grep horizon
  ii  python-django-horizon2:9.1.0-0ubuntu1~cloud0  all 
 Django module providing web based interaction with OpenStack

  It is also hitting on version 9.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1617206/+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 1618241] [NEW] Angular actions are not themeable

[Travis Tripp]

Public bug reported:

The angular page actions are not themeable (new angular images) page,
although they are in the django page.

In our UI, we theme the actions to look more like an elipse and this is
not being displayed properly for the images page (or searchlight UI).

According to Diana:

./templates/horizon/common/_data_table_row_actions_dropdown.html
./templates/horizon/common/_data_table_table_actions.html

Those two templates need to be ported to their corresponding Angular
templates.  The markup will need to match up precisely to make use of
the existing css.

** Affects: horizon
 Importance: Undecided
 Status: New

** Changed in: horizon
Milestone: None => newton-rc1

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

Title:
  Angular actions are not themeable

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  The angular page actions are not themeable (new angular images) page,
  although they are in the django page.

  In our UI, we theme the actions to look more like an elipse and this
  is not being displayed properly for the images page (or searchlight
  UI).

  According to Diana:

  ./templates/horizon/common/_data_table_row_actions_dropdown.html
  ./templates/horizon/common/_data_table_table_actions.html

  Those two templates need to be ported to their corresponding Angular
  templates.  The markup will need to match up precisely to make use of
  the existing css.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1618241/+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 1453264] Re: iptables_manager can run very slowly when a large number of security group rules are present

[Billy Olsen]

Uploading debdiff based on what is currently available in trusty-
proposed since that has been verified and pending release.

** Description changed:

+ [Impact]
+ 
  We have customers that typically add a few hundred security group rules
  or more.  We also typically run 30+ VMs per compute node.  When about
  10+ VMs with a large SG set all get scheduled to the same node, the L2
  agent (OVS) can spend many minutes in the iptables_manager.apply() code,
  so much so that by the time all the rules are updated, the VM has
  already tried DHCP and failed, leaving it in an unusable state.
  
  While there have been some patches that tried to address this in Juno
  and Kilo, they've either not helped as much as necessary, or broken SGs
  completely due to re-ordering the of the iptables rules.
  
  I've been able to show some pretty bad scaling with just a handful of
  VMs running in devstack based on today's code (May 8th, 2015) from
  upstream Openstack.
+ 
+ 
+ [Test Case]
  
  Here's what I tested:
  
  1. I created a security group with 1000 TCP port rules (you could
  alternately have a smaller number of rules and more VMs, but it's
  quicker this way)
  
  2. I booted VMs, specifying both the default and "large" SGs, and timed
  from the second it took Neutron to "learn" about the port until it
  completed it's work
  
  3. I got a :( pretty quickly
  
  And here's some data:
  
  1-3 VM - didn't time, less than 20 seconds
  4th VM - 0:36
  5th VM - 0:53
  6th VM - 1:11
  7th VM - 1:25
  8th VM - 1:48
  9th VM - 2:14
  
  While it's busy adding the rules, the OVS agent is consuming pretty
  close to 100% of a CPU for most of this time (from top):
  
-   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND   
  
+   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
  25767 stack 20   0  157936  76572   4416 R  89.2  0.5  50:14.28 python
  
  And this is with only ~10K rules at this point!  When we start crossing
  the 20K point VM boot failures start to happen.
  
  I'm filing this bug since we need to take a closer look at this in
  Liberty and fix it, it's been this way since Havana and needs some TLC.
  
  I've attached a simple script I've used to recreate this, and will start
  taking a look at options here.
+ 
+ 
+ [Regression Potential]
+ 
+ Minimal since this has been running in upstream stable for several
+ releases now (Kilo, Liberty, Mitaka).

** Also affects: neutron (Ubuntu)
   Importance: Undecided
   Status: New

** Patch added: "trusty patch based on -proposed"
   
https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1453264/+attachment/4730270/+files/lp1453264.debdiff

** Also affects: cloud-archive
   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/1453264

Title:
  iptables_manager can run very slowly when a large number of security
  group rules are present

Status in Ubuntu Cloud Archive:
  New
Status in neutron:
  Fix Released
Status in neutron kilo series:
  Fix Released
Status in neutron package in Ubuntu:
  New

Bug description:
  [Impact]

  We have customers that typically add a few hundred security group
  rules or more.  We also typically run 30+ VMs per compute node.  When
  about 10+ VMs with a large SG set all get scheduled to the same node,
  the L2 agent (OVS) can spend many minutes in the
  iptables_manager.apply() code, so much so that by the time all the
  rules are updated, the VM has already tried DHCP and failed, leaving
  it in an unusable state.

  While there have been some patches that tried to address this in Juno
  and Kilo, they've either not helped as much as necessary, or broken
  SGs completely due to re-ordering the of the iptables rules.

  I've been able to show some pretty bad scaling with just a handful of
  VMs running in devstack based on today's code (May 8th, 2015) from
  upstream Openstack.

  
  [Test Case]

  Here's what I tested:

  1. I created a security group with 1000 TCP port rules (you could
  alternately have a smaller number of rules and more VMs, but it's
  quicker this way)

  2. I booted VMs, specifying both the default and "large" SGs, and
  timed from the second it took Neutron to "learn" about the port until
  it completed it's work

  3. I got a :( pretty quickly

  And here's some data:

  1-3 VM - didn't time, less than 20 seconds
  4th VM - 0:36
  5th VM - 0:53
  6th VM - 1:11
  7th VM - 1:25
  8th VM - 1:48
  9th VM - 2:14

  While it's busy adding the rules, the OVS agent is consuming pretty
  close to 100% of a CPU for most of this time (from top):

    PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
  25767 stack 20   0  157936  76572   4416 R  89.2  0.5  50:14.28 python

  And this is with only ~10K rules at this point!  When we start
  crossing the 20K point VM boot failures start to 

[Yahoo-eng-team] [Bug 1618235] [NEW] Magic Search facet disappears when changing first character

[Travis Tripp]

Public bug reported:

Reporting this after doing a moderated usability test on magic search.
This caused significant confusion for the user.

If you select a magic search facet such as Image: Name and then start to
type something, but mistype the first character, the magic search facet
will completely disappear when you hit backspace.


http://imgur.com/a/CXkkF

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

** Affects: searchlight
 Importance: Undecided
 Status: Incomplete


** Tags: searchlight-ui

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

** Changed in: horizon
 Assignee: (unassigned) => Matt Borland (palecrow)

** Tags added: searchlight-ui

** Summary changed:

- Magic Search facet disappears to early when changing first character
+ Magic Search facet disappears when changing first character

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

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

Title:
  Magic Search facet disappears when changing first character

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Search (Searchlight):
  Incomplete

Bug description:
  Reporting this after doing a moderated usability test on magic search.
  This caused significant confusion for the user.

  If you select a magic search facet such as Image: Name and then start
  to type something, but mistype the first character, the magic search
  facet will completely disappear when you hit backspace.

  
  http://imgur.com/a/CXkkF

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1618235/+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 1614337] Re: L3 agent fails on FIP when DVR and HA both enabled in router

[Swaminathan Vasudevan]

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

Title:
  L3 agent fails on FIP when DVR and HA both enabled in router

Status in neutron:
  Invalid

Bug description:
  I have a vlan-based Neutron configuration.  My tenant networks are
  vlans, and my shared external network (br-ex) is a flat network.
  Neutron is configured for DVR+SNAT mode.  In testing floating IPs,
  I've run into issues with my neutron router, and I've traced it back
  to a single scenario: when the router is both distributed AND ha.  To
  be clear, I've tested all four possibilities:

  "--distributed False --ha False"  == works
  "--distributed True --ha False"  == works
  "--distributed False --ha True"  == works
  "--distributed True --ha True"  == fails

  * I can reproduce this again and again, just by deleting the router I
  have (which implies first clearing its gateway, and removing any
  associated ports), then re-creating the router in any of the four
  configurations above.  Then I boot some VMs, associate a FIP to any
  one of them, and attempt to reach the FIP.  Results are the same
  whether I create the router on the CLI or from within Horizon.

  * Expected result is that I should be able to associate a floating IP
  to a running VM and then ping that floating IP (and ultimately other
  kinds of activity, such as SSH access to the VM).

  
  * Actual result is that the floating IP is completely unreachable from other 
valid IPs within same L2 space.  Additionally, in /var/log/neutron/l3-agent.log 
on the compute node hosting the VM whose associated FIP I can't reach, I find 
this:

  
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent [-] Failed to 
process compatible router '13356ddb-8e36-4f54-b8b2-6a62a5aecf86'
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent Traceback (most 
recent call last):
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 501, in 
_process_router_update
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
self._process_router_if_compatible(router)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 440, in 
_process_router_if_compatible
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
self._process_updated_router(router)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 454, in 
_process_updated_router
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
ri.process(self)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr_edge_ha_router.py", line 
92, in process
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
super(DvrEdgeHaRouter, self).process(agent)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr_local_router.py", line 
488, in process
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
super(DvrLocalRouter, self).process(agent)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/dvr_router_base.py", line 
30, in process
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
super(DvrRouterBase, self).process(agent)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/agent/l3/ha_router.py", line 386, in 
process
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
super(HaRouter, self).process(agent)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 385, in call
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent self.logger(e)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
self.force_reraise()
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent 
six.reraise(self.type_, self.value, self.tb)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 
"/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 382, in call
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent return 
func(*args, **kwargs)
  2016-08-17 22:33:25.512 11369 ERROR neutron.agent.l3.agent   File 

[Yahoo-eng-team] [Bug 1618231] [NEW] dhcp agent uses same request ID for every request

[Kevin Benton]

Public bug reported:

The DHCP agent uses the same context and subsequently the same request
ID for every request it makes to the Neutron server. This makes
searching for single actions based on request ID very ineffective.

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

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

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

Title:
  dhcp agent uses same request ID for every request

Status in neutron:
  In Progress

Bug description:
  The DHCP agent uses the same context and subsequently the same request
  ID for every request it makes to the Neutron server. This makes
  searching for single actions based on request ID very ineffective.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618231/+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 1618216] [NEW] dhcp agent RPC handler doesn't retry DBError

[Kevin Benton]

Public bug reported:

The RPC handler to create a port is catching DBError's before the retry
decorator gets a chance to retry them. This ends up being treated like a
broken network to the agent so the network will not have any DHCP
service, leading to difficult to debug failures like this one:

http://logs.openstack.org/82/346282/4/check/gate-tempest-dsvm-neutron-
full-ubuntu-xenial/d4ea1f6/console.html

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

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

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

Title:
  dhcp agent RPC handler doesn't retry DBError

Status in neutron:
  In Progress

Bug description:
  The RPC handler to create a port is catching DBError's before the
  retry decorator gets a chance to retry them. This ends up being
  treated like a broken network to the agent so the network will not
  have any DHCP service, leading to difficult to debug failures like
  this one:

  http://logs.openstack.org/82/346282/4/check/gate-tempest-dsvm-neutron-
  full-ubuntu-xenial/d4ea1f6/console.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618216/+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 1321378] Re: keystone user-role-delete operation fails when user no longer exists in backend

[Adam Young]

So...this is a continuing Saga.  The fix that went in for Keystone only
allows the V3  AP call to continue.  However, there is currently no way
to call that API except for CURL.


Something like:

 curl -X DELETE  -H"X-Auth-Token:$TOKEN" -H "Content-type:
application/json"
$OS_AUTH_URL/projects/e9d504e8524e4c8d9876d179420dab89/users/tuser/roles/95a2366f8b514d43a5584342aefe448e

Will work, but there is no way to invoke that from python-keystoneclient
or python-openwstackclient as both will attempt to list the users and do
a lookup.

We probably need a --userid option that indicates that the passed in
value is a userid, and do not attempt to look it up.

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

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

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

Title:
  keystone user-role-delete operation fails when user no longer exists
  in backend

Status in OpenStack Identity (keystone):
  Fix Released
Status in python-keystoneclient:
  New
Status in python-openstackclient:
  New

Bug description:
  When using an external user catalog (in our case, AD), if the user is
  removed on the backend catalog, the user-role-* keystone CLI commands
  no longer work, because keystone cannot look up the user.

  The specific situation is a user had been granted roles on some
  projects, but then that user left the company and was removed from the
  backend directory.  When going back to remove the roles assigned to
  that user, the keystone commands fail.

  It may still be possible to do these operations directly through the
  API, I didn't check that.  But ultimately was able to work around it
  by directly removing the entries in the keystone user_project_metadata
  table.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1321378/+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 1590779] Re: Cache region invalidation works for local CacheRegion object only

[OpenStack Infra]

Reviewed:  https://review.openstack.org/349704
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=42eda48c78f1153081b4c193dc13c88561409fd3
Submitter: Jenkins
Branch:master

commit 42eda48c78f1153081b4c193dc13c88561409fd3
Author: David Stanek 
Date:   Mon Aug 1 21:06:50 2016 +

Distributed cache namespace to invalidate regions

dogpile.cache's region invalidation is not designed to work across
processes. This patch enables distributed invalidation of keys in a
region.

Instead of using a static cache key, we use the original cache key
and append a dynamic value to it. This value is looked up in
memcached using the region name as a key. So anytime the value of
the region key changes the cache keys in that region are
effectively invalidated.

Closes-Bug: #1590779
Change-Id: Ib80d41d43ef815b37282d72ad68e7aa8e1ff354e


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

Title:
  Cache region invalidation works for local CacheRegion object only

Status in OpenStack Identity (keystone):
  Fix Released
Status in oslo.cache:
  In Progress

Bug description:
  oslo_cache uses dogpile.cache's CacheRegion
  which invalidates by setting region object attributes:
  - self._hard_invalidated
  - self._soft_invalidated
  Then it checks these attributes on value get.
  So this invalidation works for particular region object only.

  If there is a need to invalidate a region so that values in it are no
  more valid for other instances of CacheRegion (either in the same
  process or in another one) - it's simply impossible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1590779/+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 1597461] Re: L3 HA: 2 masters after reboot of controller

[OpenStack Infra]

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

commit 25f5912cf8f69f18d111bd60a6cc6ee488755ff3
Author: AKamyshnikova 
Date:   Thu Aug 18 23:18:40 2016 +0300

Check for ha port to become ACTIVE

After reboot(restart of l3 and l2 agents) of the node routers
can be processed by l3 agent before openvswitch agent sets up
appropriate ha ports. This change add notification for l3 agent
that ha port becomes ACTIVE and keepalived can be enabled.

Closes-bug: #1597461

Co-Authored-By: venkata anil 

Change-Id: Iedad1ccae45005efaaa74d5571df04197757d07a


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

Title:
  L3 HA: 2 masters after reboot of controller

Status in neutron:
  Fix Released

Bug description:
  ENV: Mitaka 3 controllers 45 computes DVR + L3 HA (L3 HA as well
  affected)

  After reboot of controller on which l3 agent is active, another l3
  agent becomes active. When rebooted node recover, that l3 agent
  becomes active as well - this lead to extra loss of external
  connectivity in tenant network. After some time the only one agent
  remains to be active - the one from rebooted node. Sometimes
  connectivity does not come back, as snat port ends up on wrong host.

  The root cause of this problem is that routers are processed by l3
  agent before openvswitch agent sets up appropriate ha ports, so for
  some time recovered ha routers is isolated from ha routers on other
  hosts and becomes active.

  The possible solution for this is proper serialization of ha network
  creation by l3 agent after ha network is set up on controller.

  With 100 routers and networks this issues has been reproduced with
  every reboot.

  Actually this is L3 HA problem, it is just increased with DVR as the
  number of ports that openvswith agent should handle is higher.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1597461/+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 1617319] Re: test_trunk_manager functional test is unstable

[OpenStack Infra]

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

commit 2618726458d2cb75a39521bf9fd71c6bfd1c0c67
Author: Jakub Libosvar 
Date:   Tue Aug 23 15:45:25 2016 -0400

functional: Make trunk tests more robust

New methods for connection tester are introduced in this patch. They
send certain amount of icmp packets and then compare the results, so we
succeed in positive tests only when all packets were replied. We succeed
in negative tests only when all packets were lost. Both approaches are
wrapped by actively waiting for successful result so we don't fail in
case where we test connectivity while resources are not wired yet.

This change is a followup to https://review.openstack.org/#/c/335536/ to
improve stability of its functional tests.

Closes-Bug: 1617319

Change-Id: I907ebd790f4ba3b4ecb0dce711c9f7d2c5244765


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

Title:
  test_trunk_manager functional test is unstable

Status in neutron:
  Fix Released

Bug description:
  Functional tests for trunk manager test connectivity while resource
  might not be ready yet because of asynchronous interaction with ovs.
  That means e.g. we want to remove subport from trunk and then test
  that port in trunk can't be accessed using vlan id from removed
  subport. Since it may take some time to ovs to completely remove
  plugging, some packets can still get through and fail the test.

  A failure mode:

  http://logs.openstack.org/36/335536/18/check/gate-neutron-dsvm-
  functional/4d0529d/testr_results.html.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1617319/+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 1614086] Re: SRIOV- when numvfs=0 SRIOV agent is failed to start

[OpenStack Infra]

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

commit f2b33b67272962abd7d6e61ab3d2b7aca3428dc5
Author: Edan David 
Date:   Thu Aug 18 16:56:56 2016 +0300

Allow SR-IOV agent to start when number of vf is 0

Remove number of vf validation from scan_vf_devices method
in the eswitch manager module, to allow the SR-IOV agent
to load when using PF passthrough.

Closes-Bug: #1614086

Change-Id: Iff5bf3a5542d5b19f45637e954a72a14402a30ae


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

Title:
  SRIOV- when numvfs=0 SRIOV agent is failed to start

Status in neutron:
  Fix Released

Bug description:
  Deployed SRIOV ENV with X VFs (for example 4 ). After that I wanted to move 
the VFs.
  When setting SRIOV system with numvfs=0  and restart SRIOV agent it failed to 
start
  # echo 0> sys/class/net/enp5s0f1/device/sriov_numvfs 
  # systemctl restart neutron-sriov-nic-agent
  # systemctl status neutron-sriov-nic-agent

  version - RHOS10
  python-neutron-lbaas-9.0.0-0.20160722053816.0c73910.el7ost.noarch
  python-neutronclient-4.2.1-0.20160721230146.3b1c538.el7ost.noarch
  openstack-neutron-common-9.0.0-0.20160726001729.6a23add.el7ost.noarch
  python-neutron-9.0.0-0.20160726001729.6a23add.el7ost.noarch
  openstack-neutron-fwaas-9.0.0-0.20160720211704.c3e491c.el7ost.noarch
  openstack-neutron-metering-agent-9.0.0-0.20160726001729.6a23add.el7ost.noarch
  openstack-neutron-openvswitch-9.0.0-0.20160726001729.6a23add.el7ost.noarch
  puppet-neutron-9.1.0-0.20160725142451.4061b39.el7ost.noarch
  python-neutron-lib-0.2.1-0.20160726025313.405f896.el7ost.noarch
  python-neutron-fwaas-9.0.0-0.20160720211704.c3e491c.el7ost.noarch
  openstack-neutron-lbaas-9.0.0-0.20160722053816.0c73910.el7ost.noarch
  openstack-neutron-ml2-9.0.0-0.20160726001729.6a23add.el7ost.noarch
  openstack-neutron-9.0.0-0.20160726001729.6a23add.el7ost.noarch
  openstack-neutron-sriov-nic-agent-9.0.0-0.20160726001729.6a23add.el7ost.noarch


  
  attached the log file

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614086/+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 1617707] Re: Auto allocate: when router creation fails network and subnets are not cleaned up

[OpenStack Infra]

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

commit 8fdc430e62e8f575499940ea73225d842db3927a
Author: Gary Kotton 
Date:   Sun Aug 28 00:20:56 2016 -0700

Auto allocation: ensure that networks and subnets are cleaned up

In the event of a router create failure we need to make sure that
the allocated resources are cleaned up.

When router allocation fails it is difficult for an admin to
understand the root cause. Adding the exception here will provide
a little additional information.

Closes-bug: #1617707

Change-Id: I41940bea0327ee31494bd95867d0e60d9b5a24b8


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

Title:
  Auto allocate: when router creation fails network and subnets are not
  cleaned up

Status in neutron:
  Fix Released

Bug description:
  When the router allocation fails then the auto allocated networks and subnets 
are left dangling.
  An example of this is when the external network does not have a subnet 
created on it (this is a validation that is done on the vmware_nsx plugin - as 
an edge appliance needs to be able to have a external interface on the external 
network)
  Another reason may be the tenant exceed in the router quota they she/he has.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1617707/+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 1611546] Re: db_models.rst isn't included in any toctree

[OpenStack Infra]

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

commit f1edd59b1f129f86cfb15154e059c29ab69d4bf2
Author: Victor Morales 
Date:   Tue Aug 9 18:09:55 2016 -0500

Include db_models document to avoid errors

The db_models.rst file was not referenced by any other document. This
was generating warnings during the creation of documentation.

Change-Id: I432aabb3c22b12faa29ca88e13392e6c2d0e33d8
Closes-Bug: #1611546


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

Title:
  db_models.rst isn't included in any toctree

Status in neutron:
  Fix Released

Bug description:
  Neutron documentation warnings are treated them as errors.

  $ sphinx-build -W -b html doc/source doc/build/html   

 18:00:59
  Running Sphinx v1.2.3
  fatal: unknown date format local -
  loading pickled environment... not yet created
  Using openstack theme from 
/Users/vjmorale/src/vagrant-intel-devstack/stack/neutron/.venv/lib/python2.7/site-packages/oslosphinx/theme
  building [html]: targets for 57 source files that are out of date
  updating environment: 57 added, 0 changed, 0 removed
  reading sources... [100%] stadium/sub_projects


   
  looking for now-outdated files... none found
  pickling environment... done
  checking consistency... 
  Warning, treated as error:
  
/Users/vjmorale/src/vagrant-intel-devstack/stack/neutron/doc/source/devref/db_models.rst::
 WARNING: document isn't included in any toctree

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1611546/+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 1618205] [NEW] neutron-lib eventlet hacking check test was reverted

[Boden R]

Public bug reported:

As part of a neutron-lib revert [1], we accidentally removed a UT for
our eventlet hacking check function. We need to put that UT back in
tree.

[1] https://github.com/openstack/neutron-
lib/commit/27cfad92102b4f54b4dbea175fcf944b46397289#diff-
f8d50ee8f7928145d126ae36c0d16900L259

** Affects: neutron
 Importance: Undecided
 Assignee: Boden R (boden)
 Status: In Progress


** Tags: lib

** Changed in: neutron
 Assignee: (unassigned) => Boden R (boden)

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

Title:
  neutron-lib eventlet hacking check test was reverted

Status in neutron:
  In Progress

Bug description:
  As part of a neutron-lib revert [1], we accidentally removed a UT for
  our eventlet hacking check function. We need to put that UT back in
  tree.

  [1] https://github.com/openstack/neutron-
  lib/commit/27cfad92102b4f54b4dbea175fcf944b46397289#diff-
  f8d50ee8f7928145d126ae36c0d16900L259

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618205/+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 1618192] [NEW] UX: login alert shows message with misaligned bullet

[Eddie Ramirez]

Public bug reported:

How to reproduce:

1. Open the Horizon Log in form.
2. Make the authetication process fail (wrong password, keystone down, etc)
3. See how the error message is shown with a bullet next to the border of its 
container box.

If only one error message is shown, then using a list () might be
unnecessary.

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: low-hanging-fruit ux

** Attachment added: "Screenshot"
   
https://bugs.launchpad.net/bugs/1618192/+attachment/4730216/+files/horizon_login.png

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

Title:
  UX: login alert shows message with misaligned bullet

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  How to reproduce:

  1. Open the Horizon Log in form.
  2. Make the authetication process fail (wrong password, keystone down, etc)
  3. See how the error message is shown with a bullet next to the border of its 
container box.

  If only one error message is shown, then using a list () might be
  unnecessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1618192/+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 1618187] [NEW] InvalidInput exceptions from DHCP RPC handler

[Kevin Benton]

Public bug reported:

Normal tempest runs are filled with exceptions in the DHCP RPC handler
when it tries to create or update a port on a network that has its
subnet deleted at the same time:

InvalidInput: Invalid input for operation: IP allocation requires
subnets for network.


http://logs.openstack.org/82/346282/4/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d4ea1f6/logs/screen-q-svc.txt.gz?level=TRACE

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


** Tags: logging

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

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

Title:
  InvalidInput exceptions from DHCP RPC handler

Status in neutron:
  In Progress

Bug description:
  Normal tempest runs are filled with exceptions in the DHCP RPC handler
  when it tries to create or update a port on a network that has its
  subnet deleted at the same time:

  InvalidInput: Invalid input for operation: IP allocation requires
  subnets for network.

  
  
http://logs.openstack.org/82/346282/4/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/d4ea1f6/logs/screen-q-svc.txt.gz?level=TRACE

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618187/+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 1618082] Re: security rule with --protocol 255 does not gets programmed

[Brian Haley]

I could not find any patch that would have changed this, and I correctly
see a rule for protocol 255 being allowed when I try this:

# iptables-save | grep 255
-A neutron-openvswi-i2232cefa-0 -p 255 -j RETURN

Since 255 is a valid, although reserved, protocol value, the code seems
to be operating normally.  For what you're trying to do you should not
be specifying any --protocol value - 255 is not a wildcard.

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

Title:
  security rule with --protocol 255 does not gets programmed

Status in neutron:
  Invalid

Bug description:
  With the latest master (August 29, 2016) I see an issue with neutron
  security group, these sequence of commands should create a group
  allowign all traffic in or out:

  neutron security-group-create  all-in-all-out
  neutron security-group-rule-create --direction ingress --ethertype ipv4 
--protocol 255 --remote-ip-prefix 0.0.0.0/0  all-in-all-out  
  neutron security-group-rule-create --direction ingress --ethertype ipv6 
--protocol 255 --remote-ip-prefix ::/0  all-in-all-out  

  when this group gets attached to the instance, these rules do not get 
programmed. In order to be able to ping the instance from outside I need to add 
this rule:
   
  neutron  security-group-rule-create --direction ingress --ethertype ipv4 
--protocol icmp --remote-ip-prefix 0.0.0.0/0 all-in-all-out

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618082/+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 1612183] Re: l3 router's driver controller is using wrong invalid exception

[OpenStack Infra]

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

commit 78554d9b35df7d8087e6e18b6e6af8335b568050
Author: gong yong sheng 
Date:   Thu Aug 11 18:37:56 2016 +0800

Add test cases for Invalid exception type

Partially-Implements: blueprint multi-l3-backends
Closes-Bug: #1612183

Change-Id: I76ab8b3a99d4459a24a8e43223e0c13654395216


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

Title:
  l3 router's driver controller is using wrong invalid exception

Status in neutron:
  Fix Released

Bug description:
  many places  at driver_controller are using wrong Invalid exception which has 
been moved to neutron_lib. For example:
  
https://github.com/openstack/neutron/blob/master/neutron/services/l3_router/service_providers/driver_controller.py#L113

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1612183/+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 1613488] Re: changed fields of versionedobjects not tracked properly when down-versioning object

[Chris Friesen]

The review for the oslo.versionedobjects change is here:
https://review.openstack.org/#/c/355981/

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

** Project changed: nova => oslo.versionedobjects

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

Title:
  changed fields of versionedobjects not tracked properly when down-
  versioning object

Status in oslo.versionedobjects:
  Fix Released

Bug description:
  Sorry for the complicated write-up below, but the issue is
  complicated.

  
  I'm running into a problem between Mitaka and Kilo, but I *think* it'll also 
hit Mitaka/Liberty.  The problem scenario is when we have older and newer 
services talking to each other.  The problem occurs when nova-conductor writes 
to an object field that is removed in obj_make_compatible().  In particular, 
I'm hitting this with 'parent_addr' in the PciDevice class since it gets 
written in PciDevice._from_db_object().

  In oslo_versionedobjects/base.py the remotable() function has the following 
line:
self._changed_fields = set(updates.get('obj_what_changed', []))

  This blindly sets the local self._changed_fields to be whatever the
  remote end sent as updates['obj_what_changed'].

  This is a problem because the far end can include fields that don't
  actually exist in the older object version.  On the far end (which may
  be newer) in nova.conductor.manager.ConductorManager.object_action(),
  we will call the following (where 'objinst' is the current version of
  the object):

  updates['obj_what_changed'] = objinst.obj_what_changed()

  Since this is called against the newer object code, it can specify
  fields that do not exist in the older version of the object if nova-
  conductor has written those fields.

  The only workaround I've been able to come up with for this is to
  modify oslo_versionedobjects.base.remotable() to only include a field
  in self._changed_fields if it's in self.fields.  This requires
  updating the older code prior to an upgrade, however.

  
  I think there's another related issue.  In VersionedObject.obj_to_primitive() 
we set the changes in the primitive like this:

  if self.obj_what_changed():
  obj[self._obj_primitive_key('changes')] = list(
  self.obj_what_changed())

  Since we call self.obj_what_changed() on the newer version of the
  object, I think we will include changes to fields that were removed by
  obj_make_compatible_from_manifest().

  It seems to me that in obj_to_primitive() we should not allow fields
  to be included in obj[self._obj_primitive_key('changes')] unless
  they're also listed in obj[self._obj_primitive_key('data')].

To manage notifications about this bug go to:
https://bugs.launchpad.net/oslo.versionedobjects/+bug/1613488/+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 1618117] [NEW] fwaas: icmp traffic blocked on adding tcp deny (ssh) rule

[Soumya Kolbhandari]

Public bug reported:

When tcp deny rules are added to a firewall or no rules are there in
firewall policy, icmp traffic is block until icmp allow rule is added to
firewall

Steps:
1. Boot two VM in different network and router associated to both the VMs 
subnet.
2. Add security group rule for ssh and ping.
3. Make sure SSH and ping works from one VM to another.
4. Add tcp deny (ssh) or tcp deny (http) or no firewall rule.
5. Try to ssh it fails worked as expected since firewall rule for deny tcp is 
added.
6. Try to ping the VMs it also fails
Actual : Ping (icmp) traffic get denied by adding tcp deny rule.
Expected : Only ssh should be blocked not the icmp.

ICMP traffic is allowed only when ICMP allow rule is added to the
firewall, is this expected behaviour..?

** Affects: neutron
 Importance: Undecided
 Status: New

** Summary changed:

- icmp traffic blocked on adding tcp deny (ssh) rule
+ fwaas: icmp traffic blocked on adding tcp deny (ssh) rule

** Project changed: python-neutronclient => 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/1618117

Title:
  fwaas: icmp traffic blocked on adding tcp deny (ssh) rule

Status in neutron:
  New

Bug description:
  When tcp deny rules are added to a firewall or no rules are there in
  firewall policy, icmp traffic is block until icmp allow rule is added
  to firewall

  Steps:
  1. Boot two VM in different network and router associated to both the VMs 
subnet.
  2. Add security group rule for ssh and ping.
  3. Make sure SSH and ping works from one VM to another.
  4. Add tcp deny (ssh) or tcp deny (http) or no firewall rule.
  5. Try to ssh it fails worked as expected since firewall rule for deny tcp is 
added.
  6. Try to ping the VMs it also fails
  Actual : Ping (icmp) traffic get denied by adding tcp deny rule.
  Expected : Only ssh should be blocked not the icmp.

  ICMP traffic is allowed only when ICMP allow rule is added to the
  firewall, is this expected behaviour..?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618117/+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 1618115] [NEW] TestStableObjectJsonFixture.test_changes_sort fails with oslo.versionedobjects 1.17.0

[Matt Riedemann]

Public bug reported:

Seen here:

http://logs.openstack.org/76/360476/2/check/gate-cross-nova-python27-db-
ubuntu-xenial/14ae1cc/console.html#_2016-08-29_04_56_08_994629

The failure is due to this change:

https://github.com/openstack/oslo.versionedobjects/commit/39a057becc10d1cfb5a5d5024bfcbbe6db1b56be

Since the same fixture is in oslo.versionedobjects since 1.9.0 we can
just remove it from nova along with the nova unit tests for it that fail
with 1.17.0.

** Affects: nova
 Importance: High
 Assignee: Matt Riedemann (mriedem)
 Status: Triaged


** Tags: oslo testing unified-objects

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

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

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

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

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

Title:
  TestStableObjectJsonFixture.test_changes_sort fails with
  oslo.versionedobjects 1.17.0

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  Seen here:

  http://logs.openstack.org/76/360476/2/check/gate-cross-nova-python27
  -db-ubuntu-xenial/14ae1cc/console.html#_2016-08-29_04_56_08_994629

  The failure is due to this change:

  
https://github.com/openstack/oslo.versionedobjects/commit/39a057becc10d1cfb5a5d5024bfcbbe6db1b56be

  Since the same fixture is in oslo.versionedobjects since 1.9.0 we can
  just remove it from nova along with the nova unit tests for it that
  fail with 1.17.0.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1618115/+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 1618117] [NEW] fwaas: icmp traffic blocked on adding tcp deny (ssh) rule

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

When tcp deny rules are added to a firewall or no rules are there in
firewall policy, icmp traffic is block until icmp allow rule is added to
firewall

Steps:
1. Boot two VM in different network and router associated to both the VMs 
subnet.
2. Add security group rule for ssh and ping.
3. Make sure SSH and ping works from one VM to another.
4. Add tcp deny (ssh) or tcp deny (http) or no firewall rule.
5. Try to ssh it fails worked as expected since firewall rule for deny tcp is 
added.
6. Try to ping the VMs it also fails
Actual : Ping (icmp) traffic get denied by adding tcp deny rule.
Expected : Only ssh should be blocked not the icmp.

ICMP traffic is allowed only when ICMP allow rule is added to the
firewall, is this expected behaviour..?

** Affects: neutron
 Importance: Undecided
 Status: New

-- 
fwaas: icmp traffic blocked on adding tcp deny (ssh) rule
https://bugs.launchpad.net/bugs/1618117
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to neutron.

-- 
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 1618111] [NEW] fullstack using deprecated oslo policy and oslo concurrency options

[Assaf Muller]

Public bug reported:

>From recent fullstack logs:

Option "policy_file" from group "DEFAULT" is deprecated. Use option 
"policy_file" from group "oslo_policy".
Option "lock_path" from group "DEFAULT" is deprecated. Use option "lock_path" 
from group "oslo_concurrency".

** Affects: neutron
 Importance: Low
 Assignee: Assaf Muller (amuller)
 Status: In Progress


** Tags: fullstack

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

Title:
  fullstack using deprecated oslo policy and oslo concurrency options

Status in neutron:
  In Progress

Bug description:
  From recent fullstack logs:

  Option "policy_file" from group "DEFAULT" is deprecated. Use option 
"policy_file" from group "oslo_policy".
  Option "lock_path" from group "DEFAULT" is deprecated. Use option "lock_path" 
from group "oslo_concurrency".

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618111/+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 1618013] Re: metadata route is absent and metadata server unavailable for instance with network w/o gateway (regression)

[Sean Dague]

This was when we changed the default to use metadata server all the
time. It sounds like previously the ec2api didn't work if it was using
metadata server instead of config drive.

Is there some default additional metadata route that needs to be put
into neutron during such a config?

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

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

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

Title:
  metadata route is absent and metadata server unavailable for instance
  with network w/o gateway (regression)

Status in neutron:
  New
Status in OpenStack Compute (nova):
  Incomplete

Bug description:
  ubuntu 14.04
  latest devstack (28.08.2016)
  enabled services: nova, glance, cinder, keystone, horizon, neutron, 
neutron-vpnaas, ec2-api

  steps to reproduce:
  0) source demo credentials
  1) create network
  2) create subnet without gateway
  3) boot instance from cirros image
  4) run vnc console
  5) run 'route -n':
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  10.10.0.0   10.10.2.1   255.255.0.0 UG0  00 eth0
  10.10.2.0   0.0.0.0 255.255.255.0   U 0  00 eth0

  6) run 'curl http://169.254.169.254/latest/'
  curl: (7) Failed to connect to 169.254.169.254: Network is unreachable

  
  if user runs instance with predefined network that all works well:
  $ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 10.10.1.1   0.0.0.0 UG0  00 eth0
  10.10.0.0   10.10.1.1   255.255.0.0 UG0  00 eth0
  10.10.1.0   0.0.0.0 255.255.255.0   U 0  00 eth0
  169.254.169.254 10.10.1.1   255.255.255.255 UGH   0  00 eth0

  
  according to gating jobs it was broken between "Aug 25 2:05 PM" (last check 
pipeline - https://review.openstack.org/#/c/360230/)
  and "Aug 26 1:05 AM" (patch 4 first check pipeline - 
https://review.openstack.org/#/c/357766/)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618013/+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 1618103] [NEW] fullstack using deprecated oslo messaging options

[Assaf Muller]

Public bug reported:

In https://bugs.launchpad.net/neutron/+bug/1487322 we switched fullstack
to use oslo messaging options from the DEFAULT section to the
oslo_messaging_rabbit section. Now these options have been deprecated as
well and the new directive is to use the transport_url option:
http://docs.openstack.org/developer/oslo.messaging/opts.html#DEFAULT.transport_url.
It doesn't seem like the option is documented, but the format is:
rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:$PORT/$virtual_host

** Affects: neutron
 Importance: Low
 Assignee: Assaf Muller (amuller)
 Status: In Progress


** Tags: fullstack

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

Title:
  fullstack using deprecated oslo messaging options

Status in neutron:
  In Progress

Bug description:
  In https://bugs.launchpad.net/neutron/+bug/1487322 we switched
  fullstack to use oslo messaging options from the DEFAULT section to
  the oslo_messaging_rabbit section. Now these options have been
  deprecated as well and the new directive is to use the transport_url
  option:
  
http://docs.openstack.org/developer/oslo.messaging/opts.html#DEFAULT.transport_url.
  It doesn't seem like the option is documented, but the format is:
  rabbit://$RABBIT_USERID:$RABBIT_PASSWORD@$RABBIT_HOST:$PORT/$virtual_host

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618103/+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 1618094] [NEW] Cloudinit fails to find config drive data due to wrong call on stages.Init(ds_deps=[])

[test]

Public bug reported:

Came across this issue while manually setting up an Ubuntu 14.04 devstack image 
with the following setup:
dpkg-reconfigure cloud-init
[*] ConfigDrive: Reads data from Openstack Config Drive

The issue was that with every instance launch, cloud-init would fail to find 
the config data mounted on a drive on the instance (in particular /dev/sr0) and 
was not setting up mainly the ssh keys and the rest of the command 
customizations.
To test the issue, I ran the following command find the culprit:

root@ubuntu14:/home/test# cloud-init modules --mode=final
Can not apply stage final, no datasource found! Likely bad things to 
come!

Traceback (most recent call last):
  File "/usr/bin/cloud-init", line 318, in main_modules
init.fetch()
  File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 
308, in fetch
return self._get_data_source()
  File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 
236, in _get_data_source
pkg_list)
  File 
"/usr/lib/python2.7/dist-packages/cloudinit/sources/__init__.py", line 263, in 
find_source
raise DataSourceNotFoundException(msg)
DataSourceNotFoundException: Did not find any data source, searched 
classes: ()

As it stands out, in https://git.launchpad.net/cloud-
init/tree/cloudinit/cmd/main.py:346 the stage Init is not properly done:

init = stages.Init(ds_deps=[], reporter=args.reporter)

the stages.py:61 init however is not properly addressed in this call and thus 
assigns the empty list with the following line:

if ds_deps is not None: 
self.ds_deps = ds_deps # which is an empty list in this case

Thus makes cloudinit ommit mounting and searching device drives for the
config data.

As a fix, either files can be changed:
- main.py:346 > init = stages.Init(ds_deps=None, reporter=args.reporter)
- stages.py:61 > if ds_deps is not None and len(ds_deps) > 0: (not sure if 
this is used init is used otherwise)

Anyways the first one fixed my problem.

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

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

Title:
  Cloudinit fails to find config drive data due to wrong call on
  stages.Init(ds_deps=[])

Status in cloud-init:
  New

Bug description:
  Came across this issue while manually setting up an Ubuntu 14.04 devstack 
image with the following setup:
  dpkg-reconfigure cloud-init
  [*] ConfigDrive: Reads data from Openstack Config Drive

  The issue was that with every instance launch, cloud-init would fail to find 
the config data mounted on a drive on the instance (in particular /dev/sr0) and 
was not setting up mainly the ssh keys and the rest of the command 
customizations.
  To test the issue, I ran the following command find the culprit:

root@ubuntu14:/home/test# cloud-init modules --mode=final
Can not apply stage final, no datasource found! Likely bad things to 
come!

Traceback (most recent call last):
  File "/usr/bin/cloud-init", line 318, in main_modules
init.fetch()
  File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 
308, in fetch
return self._get_data_source()
  File "/usr/lib/python2.7/dist-packages/cloudinit/stages.py", line 
236, in _get_data_source
pkg_list)
  File 
"/usr/lib/python2.7/dist-packages/cloudinit/sources/__init__.py", line 263, in 
find_source
raise DataSourceNotFoundException(msg)
DataSourceNotFoundException: Did not find any data source, searched 
classes: ()

  As it stands out, in https://git.launchpad.net/cloud-
  init/tree/cloudinit/cmd/main.py:346 the stage Init is not properly
  done:

  init = stages.Init(ds_deps=[], reporter=args.reporter)

  the stages.py:61 init however is not properly addressed in this call and thus 
assigns the empty list with the following line:
  
  if ds_deps is not None: 
  self.ds_deps = ds_deps # which is an empty list in this case

  Thus makes cloudinit ommit mounting and searching device drives for
  the config data.

  As a fix, either files can be changed:
  - main.py:346 > init = stages.Init(ds_deps=None, reporter=args.reporter)
  - stages.py:61 > if ds_deps is not None and len(ds_deps) > 0: (not sure 
if this is used init is used otherwise)

  Anyways the first one fixed my problem.

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

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

[Yahoo-eng-team] [Bug 1618082] [NEW] security rule with --protocol 255 does not gets programmed

[Serguei Bezverkhi]

Public bug reported:

With the latest master (August 29, 2016) I see an issue with neutron
security group, these sequence of commands should create a group
allowign all traffic in or out:

neutron security-group-create  all-in-all-out
neutron security-group-rule-create --direction ingress --ethertype ipv4 
--protocol 255 --remote-ip-prefix 0.0.0.0/0  all-in-all-out  
neutron security-group-rule-create --direction ingress --ethertype ipv6 
--protocol 255 --remote-ip-prefix ::/0  all-in-all-out  

when this group gets attached to the instance, these rules do not get 
programmed. In order to be able to ping the instance from outside I need to add 
this rule:
 
neutron  security-group-rule-create --direction ingress --ethertype ipv4 
--protocol icmp --remote-ip-prefix 0.0.0.0/0 all-in-all-out

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

Title:
  security rule with --protocol 255 does not gets programmed

Status in neutron:
  New

Bug description:
  With the latest master (August 29, 2016) I see an issue with neutron
  security group, these sequence of commands should create a group
  allowign all traffic in or out:

  neutron security-group-create  all-in-all-out
  neutron security-group-rule-create --direction ingress --ethertype ipv4 
--protocol 255 --remote-ip-prefix 0.0.0.0/0  all-in-all-out  
  neutron security-group-rule-create --direction ingress --ethertype ipv6 
--protocol 255 --remote-ip-prefix ::/0  all-in-all-out  

  when this group gets attached to the instance, these rules do not get 
programmed. In order to be able to ping the instance from outside I need to add 
this rule:
   
  neutron  security-group-rule-create --direction ingress --ethertype ipv4 
--protocol icmp --remote-ip-prefix 0.0.0.0/0 all-in-all-out

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618082/+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 1618079] [NEW] ignore, testing api

[Rob Cresswell]

Public bug reported:

ignore this  just testing  how the api

stores description data

** Affects: horizon
 Importance: Undecided
 Status: Won't Fix

** Changed in: horizon
   Status: New => Won't Fix

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

Title:
  ignore, testing api

Status in OpenStack Dashboard (Horizon):
  Won't Fix

Bug description:
  ignore this  just testing  how the api

  stores description data

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1618079/+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 1616094] Re: Required attribute 'lb_method' not specified when creating a LBaaSv2

[Rabi Mishra]

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

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

Title:
  Required attribute 'lb_method' not specified when creating a LBaaSv2

Status in heat:
  Invalid
Status in neutron:
  Incomplete
Status in python-neutronclient:
  In Progress

Bug description:
  When creating a LBaaS v2 loadbalancer, listener and pool, I get:

  - s n i p -
  2016-08-23 14:04:32 [pool]: CREATE_FAILED  BadRequest: resources.pool: Failed 
to parse request. Required attribute 'lb_method' not specified
  - s n i p -

  The test stack:

  - s n i p -
  heat_template_version: 2015-04-30
  description: Loadbalancer template

  resources:
    lbaas:
  type: OS::Neutron::LBaaS::LoadBalancer
  properties:
    name: lbaas-test
    description: lbaas-test
    vip_subnet: subnet-97

    listener:
  type: OS::Neutron::LBaaS::Listener
  properties:
    name: listener-test
    description: listener-test
    loadbalancer: { get_resource: lbaas }
    protocol: TCP
    protocol_port: 666

    pool:
  type: OS::Neutron::LBaaS::Pool
  properties:
    name: hapool-test
    description: hapool-test
    listener: { get_resource: listener }
    protocol: TCP
    lb_algorithm: LEAST_CONNECTIONS
  - s n i p -

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1616094/+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 1616094] Re: Required attribute 'lb_method' not specified when creating a LBaaSv2

[Reedip]

[1] states that the neutronclient still has this left over

https://github.com/openstack/python-
neutronclient/blob/master/neutronclient/neutron/v2_0/lb/pool.py#L59

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

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

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

Title:
  Required attribute 'lb_method' not specified when creating a LBaaSv2

Status in heat:
  New
Status in neutron:
  Incomplete
Status in python-neutronclient:
  In Progress

Bug description:
  When creating a LBaaS v2 loadbalancer, listener and pool, I get:

  - s n i p -
  2016-08-23 14:04:32 [pool]: CREATE_FAILED  BadRequest: resources.pool: Failed 
to parse request. Required attribute 'lb_method' not specified
  - s n i p -

  The test stack:

  - s n i p -
  heat_template_version: 2015-04-30
  description: Loadbalancer template

  resources:
    lbaas:
  type: OS::Neutron::LBaaS::LoadBalancer
  properties:
    name: lbaas-test
    description: lbaas-test
    vip_subnet: subnet-97

    listener:
  type: OS::Neutron::LBaaS::Listener
  properties:
    name: listener-test
    description: listener-test
    loadbalancer: { get_resource: lbaas }
    protocol: TCP
    protocol_port: 666

    pool:
  type: OS::Neutron::LBaaS::Pool
  properties:
    name: hapool-test
    description: hapool-test
    listener: { get_resource: listener }
    protocol: TCP
    lb_algorithm: LEAST_CONNECTIONS
  - s n i p -

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1616094/+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 1618024] [NEW] Content Security Policy support

[Taras]

Public bug reported:

There is a mechanism called Content Security Policy which web
applications can use to mitigate a broad class of content injection
vulnerabilities, such as cross-site scripting (XSS). Content Security
Policy is a declarative policy that lets the authors (or server
administrators) of a web application inform the client about the sources
from which the application expects to load resources
(https://www.w3.org/TR/CSP2/)

It will be great if OpenStack Dashboard will support it out of the box
and enforce by default. In the most cases implement CSP support into web
applicaton consist of following steps:

1. Review HTML code and try to remove all inline code (JS and CSS) and eval() 
usage
2. If you can't remove inline code you should use nonces/hashes
3. Prepare CSP policy and switch it on in Report-Only mode for some time
4. Fix all the bugs from the CSP log
5. Switch CSP into block mode

Additional information:
* https://www.w3.org/TR/CSP2/
* http://githubengineering.com/githubs-csp-journey/
* http://www.html5rocks.com/en/tutorials/security/content-security-policy/
* https://developer.mozilla.org/en/docs/Web/Security/CSP/CSP_policy_directives

** Affects: horizon
 Importance: Undecided
 Status: New


** Tags: csp

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

Title:
  Content Security Policy support

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  There is a mechanism called Content Security Policy which web
  applications can use to mitigate a broad class of content injection
  vulnerabilities, such as cross-site scripting (XSS). Content Security
  Policy is a declarative policy that lets the authors (or server
  administrators) of a web application inform the client about the
  sources from which the application expects to load resources
  (https://www.w3.org/TR/CSP2/)

  It will be great if OpenStack Dashboard will support it out of the box
  and enforce by default. In the most cases implement CSP support into
  web applicaton consist of following steps:

  1. Review HTML code and try to remove all inline code (JS and CSS) and eval() 
usage
  2. If you can't remove inline code you should use nonces/hashes
  3. Prepare CSP policy and switch it on in Report-Only mode for some time
  4. Fix all the bugs from the CSP log
  5. Switch CSP into block mode

  Additional information:
  * https://www.w3.org/TR/CSP2/
  * http://githubengineering.com/githubs-csp-journey/
  * http://www.html5rocks.com/en/tutorials/security/content-security-policy/
  * https://developer.mozilla.org/en/docs/Web/Security/CSP/CSP_policy_directives

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1618024/+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 1618025] [NEW] MTU specified during neutron network create is not honored, always set to 1500

[Sridhar Venkat]

Public bug reported:

When I try to create a new neutron network with MTU say 1000, it is
getting overwritten with a value of 1500.

Is MTU not settable per neutron network?

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

Title:
  MTU specified during neutron network create is not honored, always set
  to 1500

Status in neutron:
  New

Bug description:
  When I try to create a new neutron network with MTU say 1000, it is
  getting overwritten with a value of 1500.

  Is MTU not settable per neutron network?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618025/+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 1618013] [NEW] metadata route is absent and metadata server unavailable for instance with network w/o gateway (regression)

[Andrey Pavlov]

Public bug reported:

ubuntu 14.04
latest devstack (28.08.2016)
enabled services: nova, glance, cinder, keystone, horizon, neutron, 
neutron-vpnaas, ec2-api

steps to reproduce:
0) source demo credentials
1) create network
2) create subnet without gateway
3) boot instance from cirros image
4) run vnc console
5) run 'route -n':
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.10.0.0   10.10.2.1   255.255.0.0 UG0  00 eth0
10.10.2.0   0.0.0.0 255.255.255.0   U 0  00 eth0

6) run 'curl http://169.254.169.254/latest/'
curl: (7) Failed to connect to 169.254.169.254: Network is unreachable


if user runs instance with predefined network that all works well:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 10.10.1.1   0.0.0.0 UG0  00 eth0
10.10.0.0   10.10.1.1   255.255.0.0 UG0  00 eth0
10.10.1.0   0.0.0.0 255.255.255.0   U 0  00 eth0
169.254.169.254 10.10.1.1   255.255.255.255 UGH   0  00 eth0


according to gating jobs it was broken between "Aug 25 2:05 PM" (last check 
pipeline - https://review.openstack.org/#/c/360230/)
and "Aug 26 1:05 AM" (patch 4 first check pipeline - 
https://review.openstack.org/#/c/357766/)

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

Title:
  metadata route is absent and metadata server unavailable for instance
  with network w/o gateway (regression)

Status in OpenStack Compute (nova):
  New

Bug description:
  ubuntu 14.04
  latest devstack (28.08.2016)
  enabled services: nova, glance, cinder, keystone, horizon, neutron, 
neutron-vpnaas, ec2-api

  steps to reproduce:
  0) source demo credentials
  1) create network
  2) create subnet without gateway
  3) boot instance from cirros image
  4) run vnc console
  5) run 'route -n':
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  10.10.0.0   10.10.2.1   255.255.0.0 UG0  00 eth0
  10.10.2.0   0.0.0.0 255.255.255.0   U 0  00 eth0

  6) run 'curl http://169.254.169.254/latest/'
  curl: (7) Failed to connect to 169.254.169.254: Network is unreachable

  
  if user runs instance with predefined network that all works well:
  $ route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse Iface
  0.0.0.0 10.10.1.1   0.0.0.0 UG0  00 eth0
  10.10.0.0   10.10.1.1   255.255.0.0 UG0  00 eth0
  10.10.1.0   0.0.0.0 255.255.255.0   U 0  00 eth0
  169.254.169.254 10.10.1.1   255.255.255.255 UGH   0  00 eth0

  
  according to gating jobs it was broken between "Aug 25 2:05 PM" (last check 
pipeline - https://review.openstack.org/#/c/360230/)
  and "Aug 26 1:05 AM" (patch 4 first check pipeline - 
https://review.openstack.org/#/c/357766/)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1618013/+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 1572187] Re: no lock required for reading secret key

[OpenStack Infra]

Reviewed:  https://review.openstack.org/307859
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=3963f03f462aac92fa28d7cd224dc4db86ce9a95
Submitter: Jenkins
Branch:master

commit 3963f03f462aac92fa28d7cd224dc4db86ce9a95
Author: Matthias Runge 
Date:   Tue Apr 19 16:53:02 2016 +0200

No lock required for reading secret key

Change-Id: I5b73db259153eb28e7c3bd5259d5c99476694804
Closes-Bug: #1572187


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

Title:
  no lock required for reading secret key

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  the current implementation for generating or reading secret key
  involves a file lock even for reading the key. this is not necessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1572187/+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 1617996] Re: paginate_query warns if sort_keys does not contain 'id'

[Ihar Hrachyshka]

Added Neutron to the list of affected projects to track requirement
bump.

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

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

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

Title:
  paginate_query warns if sort_keys does not contain 'id'

Status in neutron:
  New
Status in oslo.db:
  New

Bug description:
  Models do not necessarily have the 'id' attribute. The only reason to
  warn is when sort_keys would not guarantee stable sorting order. We
  should inspect the model to determine its unique keys.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1617996/+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 1617952] [NEW] Juno Devstack installation failure while uploading image

[vk]

Public bug reported:

Devstack installation is failing while uploading image. Below is the
exception which I am getting everytime. I also cherry-picked this fix -
https://review.openstack.org/#/c/151506/ , but of no use.


2016-08-29 09:39:34.219 | + '[' -n 
/home/stack/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
 ']'
2016-08-29 09:39:34.220 | ++ openstack --os-token 
749c7e1fa55042318ac987b906a19890 --os-url http://192.168.100.101:9292 image 
create cirros-0.3.4-x86_64-uec-kernel --public --container-format aki 
--disk-format aki
2016-08-29 09:39:34.220 | ++ grep ' id '
2016-08-29 09:39:34.220 | ++ get_field 2
2016-08-29 09:39:34.225 | ++ local data field
2016-08-29 09:39:34.225 | ++ read data
2016-08-29 09:39:38.678 | ERROR: openstack 
2016-08-29 09:39:38.679 |  
2016-08-29 09:39:38.679 |   401 Unauthorized
2016-08-29 09:39:38.679 |  
2016-08-29 09:39:38.679 |  
2016-08-29 09:39:38.679 |   401 Unauthorized
2016-08-29 09:39:38.679 |   This server could not verify that you are 
authorized to access the document you requested. Either you supplied the wrong 
credentials (e.g., bad password), or your browser does not understand how to 
supply the credentials required.
2016-08-29 09:39:38.679 | 
2016-08-29 09:39:38.679 |  
2016-08-29 09:39:38.679 |  (HTTP 401)
2016-08-29 09:39:38.736 | + kernel_id=
2016-08-29 09:39:38.736 | + '[' -n 
/home/stack/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-initrd
 ']'
2016-08-29 09:39:38.737 | ++ openstack --os-token 
749c7e1fa55042318ac987b906a19890 --os-url http://192.168.100.101:9292 image 
create cirros-0.3.4-x86_64-uec-ramdisk --public --container-format ari 
--disk-format ari
2016-08-29 09:39:38.737 | ++ grep ' id '
2016-08-29 09:39:38.737 | ++ get_field 2
2016-08-29 09:39:38.738 | ++ local data field
2016-08-29 09:39:38.738 | ++ read data
2016-08-29 09:39:41.687 | ERROR: openstack 
2016-08-29 09:39:41.687 |  
2016-08-29 09:39:41.687 |   401 Unauthorized
2016-08-29 09:39:41.687 |  
2016-08-29 09:39:41.687 |  
2016-08-29 09:39:41.687 |   401 Unauthorized
2016-08-29 09:39:41.687 |   This server could not verify that you are 
authorized to access the document you requested. Either you supplied the wrong 
credentials (e.g., bad password), or your browser does not understand how to 
supply the credentials required.
2016-08-29 09:39:41.687 | 
2016-08-29 09:39:41.687 |  
2016-08-29 09:39:41.687 |  (HTTP 401)
2016-08-29 09:39:41.745 | + ramdisk_id=
2016-08-29 09:39:41.745 | + openstack --os-token 
749c7e1fa55042318ac987b906a19890 --os-url http://192.168.100.101:9292 image 
create cirros-0.3.4-x86_64-uec --public --container-format ami --disk-format ami
2016-08-29 09:39:44.906 | ERROR: openstack 
2016-08-29 09:39:44.906 |  
2016-08-29 09:39:44.906 |   401 Unauthorized
2016-08-29 09:39:44.906 |  
2016-08-29 09:39:44.906 |  
2016-08-29 09:39:44.906 |   401 Unauthorized
2016-08-29 09:39:44.906 |   This server could not verify that you are 
authorized to access the document you requested. Either you supplied the wrong 
credentials (e.g., bad password), or your browser does not understand how to 
supply the credentials required.
2016-08-29 09:39:44.906 | 
2016-08-29 09:39:44.906 |  
2016-08-29 09:39:44.906 |  (HTTP 401)
2016-08-29 09:39:44.957 | + exit_trap
2016-08-29 09:39:44.957 | + local r=1
2016-08-29 09:39:44.958 | ++ jobs -p
2016-08-29 09:39:44.959 | + jobs=
2016-08-29 09:39:44.959 | + [[ -n '' ]]
2016-08-29 09:39:44.959 | + kill_spinner
2016-08-29 09:39:44.959 | + '[' '!' -z '' ']'
2016-08-29 09:39:44.959 | + [[ 1 -ne 0 ]]
2016-08-29 09:39:44.959 | + echo 'Error on exit'
2016-08-29 09:39:44.959 | Error on exit
2016-08-29 09:39:44.959 | + [[ -z /opt/stack/logs ]]
2016-08-29 09:39:44.959 | + /home/stack/devstack/tools/worlddump.py -d 
/opt/stack/logs
2016-08-29 09:39:45.024 | + exit 1

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  Juno Devstack installation failure while uploading image

Status in Glance:
  New

Bug description:
  Devstack installation is failing while uploading image. Below is the
  exception which I am getting everytime. I also cherry-picked this fix
  - https://review.openstack.org/#/c/151506/ , but of no use.

  
  2016-08-29 09:39:34.219 | + '[' -n 
/home/stack/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
 ']'
  2016-08-29 09:39:34.220 | ++ openstack --os-token 
749c7e1fa55042318ac987b906a19890 --os-url http://192.168.100.101:9292 image 
create cirros-0.3.4-x86_64-uec-kernel --public --container-format aki 
--disk-format aki
  2016-08-29 09:39:34.220 | ++ grep ' id '
  2016-08-29 09:39:34.220 | ++ get_field 2
  2016-08-29 09:39:34.225 | ++ local data field
  2016-08-29 09:39:34.225 | ++ read data
  2016-08-29 09:39:38.678 | ERROR: openstack 
  2016-08-29 09:39:38.679 |  
  2016-08-29 

[Yahoo-eng-team] [Bug 1584647] Re: "Interface monitor is not active" can be observed at ovs-agent start

[OpenStack Infra]

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

commit 95ff46722d195eb894e79b08c5a6eb13082cc799
Author: Hong Hui Xiao 
Date:   Mon May 23 08:33:55 2016 +

Wait for ovsdb_monitor to be active before use it

There is a race between ovsdb_monitor becoming active and using
ovsdb_monitor. Sometimes, code [1] will be hit at ovs-agent startup.

The fix here will block the start of ovsdb_monitor, so that the
following code to use the ovsdb_monitor will have ovsdb_monitor be
active.

[1] https://goo.gl/RJX4I5
Closes-bug: #1584647

Change-Id: I893a3b250339006f50aa003686fb95d7f2465edc


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

Title:
  "Interface monitor is not active" can be observed at ovs-agent start

Status in neutron:
  Fix Released

Bug description:
  I noticed this error message in neutron-ovs-agent log when start
  neutron-openvswitch-agent

  ERROR neutron.agent.linux.ovsdb_monitor [req-a7c7a398-a13b-490e-
  adf8-c5afb24b4b9c None None] Interface monitor is not active.

  ovs-agent will start ovsdb_monitor at [1], and first use it at [2].
  There is no guarantee that ovsdb_monitor is ready at [2]. So, I can
  see the error when start neutron-openvswitch-agent.

  We should block the start to wait for the process to be active, and
  then use it. Or else, the use of ovsdb_monitor will be meaningless.


  [1]
  
https://github.com/openstack/neutron/blob/6da27a78f42db00c91a747861eafde7edc6f1fa7/neutron/agent/linux/polling.py#L35

  [2]
  
https://github.com/openstack/neutron/blob/6da27a78f42db00c91a747861eafde7edc6f1fa7/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L1994

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1584647/+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 1594810] Re: Remove deprecated config options for default subnetpools

[OpenStack Infra]

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

commit f7cc6a0107bd330150e2136e5a3dac99b6b2c33d
Author: John Davidge 
Date:   Thu May 26 17:42:04 2016 +0100

Remove deprecated default subnetpools

These config options were deprecated in Mitaka.
They can now be removed in Newton.

Closes-Bug: #1594810
Related-Bug: #1501328
Change-Id: I6eea7d4465cf23df1d8dae26336633052dfab871


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

Title:
  Remove deprecated config options for default subnetpools

Status in neutron:
  Fix Released

Bug description:
  These options were deprecated in the Mitaka cycle by
  https://review.openstack.org/#/c/230983/

  They can now be removed in Newton.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1594810/+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 1617447] Re: InterfaceAttachFailed: Failed to attach network adapter device

[OpenStack Infra]

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

commit ab61970644086de392f12d6d6a054ca85fb6e5d7
Author: Kevin Benton 
Date:   Fri Aug 26 16:36:20 2016 -0700

Make addbr safe to bridge add races

This makes the code that constructs a bridge safe to concurrent
additions of the same bridge.

Change-Id: I3c85731de6b6d07af54ace5f8d835f01a366f5b3
Closes-Bug: #1617447


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

Title:
  InterfaceAttachFailed: Failed to attach network adapter device

Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  New
Status in os-vif:
  In Progress

Bug description:
  This looks it shows in the gate on a master branch change:

  http://logs.openstack.org/04/353704/9/gate/gate-tempest-dsvm-neutron-
  linuxbridge/e6ca9f3/console.html#_2016-08-26_19_50_16_384253

  http://logs.openstack.org/04/353704/9/gate/gate-tempest-dsvm-neutron-
  
linuxbridge/e6ca9f3/logs/screen-n-cpu.txt.gz?level=TRACE#_2016-08-26_19_36_06_377

  http://paste.openstack.org/show/564060/

  The root cause:

  2016-08-26 19:36:06.377 24801 ERROR os_vif Stderr: u"device
  brqd7d244e3-06 already exists; can't create bridge with the same
  name\n"

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1617447/+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 1617903] [NEW] Cannot reset the instance key pair while rebuilding

[LIU Yulong]

Public bug reported:

Description
===
There is no way to reset the instance key pair, even during the rebuild 
procedure.


Expected result
===
`nova rebulid` will be a good approach to reset the instance key pair.

** Affects: nova
 Importance: Undecided
 Assignee: LIU Yulong (dragon889)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => LIU Yulong (dragon889)

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

Title:
  Cannot reset the instance key pair while rebuilding

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  There is no way to reset the instance key pair, even during the rebuild 
procedure.

  
  Expected result
  ===
  `nova rebulid` will be a good approach to reset the instance key pair.

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