[Yahoo-eng-team] [Bug 1547362] [NEW] A driver API for triggering crash dump should abstract an implementation

[Hironori Shiina]

Public bug reported:

We added a new API for triggering crash dump in Mitaka.
At first, "inject_nmi" was proposed as a new API name.
In discussion of the spec[1], we decided to abstract how to trigger crash dump
because it depends on hypervisors.

Since the function was partially implemented in Liberty, virt driver has a API 
named "inject_nmi".
We should change the API name for abstracting an implementation based on the 
spec approved in Mitaka.

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

** Affects: nova
 Importance: Undecided
 Assignee: Hironori Shiina (shiina-hironori)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Hironori Shiina (shiina-hironori)

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

Title:
  A driver API for triggering crash dump should abstract an
  implementation

Status in OpenStack Compute (nova):
  New

Bug description:
  We added a new API for triggering crash dump in Mitaka.
  At first, "inject_nmi" was proposed as a new API name.
  In discussion of the spec[1], we decided to abstract how to trigger crash dump
  because it depends on hypervisors.

  Since the function was partially implemented in Liberty, virt driver has a 
API named "inject_nmi".
  We should change the API name for abstracting an implementation based on the 
spec approved in Mitaka.

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547362/+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 1547351] [NEW] change mysql chartset latin1 to utf-8 in 314_add_resource_provider_tables

[tinytmy]

Public bug reported:

In the 314_add_resource_provider_tables.py, it use latin1 for mysql table.
Maybe we can unify mysql chartset to utf-8.

https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/314_add_resource_provider_tables.py#L54

** Affects: nova
 Importance: Undecided
 Assignee: tinytmy (tangmeiyan77)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => tinytmy (tangmeiyan77)

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

Title:
  change mysql chartset latin1 to utf-8 in
  314_add_resource_provider_tables

Status in OpenStack Compute (nova):
  New

Bug description:
  In the 314_add_resource_provider_tables.py, it use latin1 for mysql table.
  Maybe we can unify mysql chartset to utf-8.

  
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/314_add_resource_provider_tables.py#L54

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547351/+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 1529109] Re: [RFE] Security groups resources are not extendable

[OpenStack Infra]

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

commit 18bc556bd44c5f73e37dbc9687c7792065440722
Author: Roey Chen 
Date:   Thu Dec 24 06:50:00 2015 -0800

Allow other extensions to extend Securitygroup resources

The Neutron Securitygroup extension defines two resources:
security-group
security-group-rule

So that other extensions could extend one or both of this resources, the
security-group extension descriptor must override the base class method,
"neutron.extensions.ExtensionDescriptor.update_attributes_map".

Change-Id: I8c462a4ee6f60ef716bf9e4d7f83a35c7e1dead0
Closes-Bug: #1529109


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

Title:
  [RFE] Security groups resources are not extendable

Status in neutron:
  Fix Released

Bug description:
  The Security Groups extension enables tenant/project to secure its
  instances, and covers fairly common use cases where tenant may require to use 
this feature, however, there are some use-cases which can't be expressed by the 
current API:
  e.g - Allow ingress multicast traffic for a specific set of multicast
  addresses.

  Some of these use cases are naturally fitting to the security-group flow of 
use, without impairing its simplicity.
  Sure, such enhancements to the security-group API may lack support in some 
implementations or might not be even relevant - this is why such additions to 
the API should be introduced by a separate extension.
  For example, The "l3" extension defines the 'routers' resource, which is 
being further extended by "router_availability_zone".

  To support the option of extending security-group/-rules resources,
  for the reasons described above, the Securitygroup class in
  neutron/extensions/securitygroup should override the base method
  "update_attributes_map" so that the resources it defines ("security-
  group" and "security-group-rules") may be extended by other
  extensions.

  For example, the "l3" extension descriptor object overrides the same
  base method, this allows other extensions like
  "router_availability_zone" to extend the "routers" resource.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1529109/+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 1547341] [NEW] Content-body doesn't move left aligned in material theme

[Kenji Ishii]

Public bug reported:

In material theme, when the page is minimum mode, the sidebar is hidden but 
content-body doesn't move.
So, there remain much empty space on left side. The browser width is short, 
though.
It should be moved like same as the sidebar for usability.

** Affects: horizon
 Importance: Undecided
 Assignee: ryo kurahashi (kuraryo0421)
 Status: New

** Attachment added: "sample_image.png"
   
https://bugs.launchpad.net/bugs/1547341/+attachment/4575234/+files/sample_image.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/1547341

Title:
  Content-body doesn't move left aligned in material theme

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  In material theme, when the page is minimum mode, the sidebar is hidden but 
content-body doesn't move.
  So, there remain much empty space on left side. The browser width is short, 
though.
  It should be moved like same as the sidebar for usability.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1547341/+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 1544522] Re: Don't use Mock.called_once_with that does not exist

[Tang Chen]

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

** Changed in: python-openstackclient
 Assignee: (unassigned) => Tang Chen (tangchen)

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

Title:
  Don't use Mock.called_once_with that does not exist

Status in Cinder:
  Fix Released
Status in neutron:
  In Progress
Status in octavia:
  In Progress
Status in python-designateclient:
  In Progress
Status in python-openstackclient:
  New
Status in Rally:
  Fix Released
Status in Sahara:
  Fix Released
Status in Trove:
  In Progress

Bug description:
  class mock.Mock does not exist method "called_once_with", it just
  exists method "assert_called_once_with". Currently there are still
  some places where we use called_once_with method, we should correct
  it.

  NOTE: called_once_with() does nothing because it's a mock object.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1544522/+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 1457986] Re: RFE: Need API to provide network IP allocation counts

[Armando Migliaccio]

Only the spec merged

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

** Changed in: neutron
Milestone: mitaka-2 => mitaka-3

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

Title:
  RFE: Need API to provide network IP allocation counts

Status in neutron:
  In Progress

Bug description:
  Operators have requested an API that allows them to quickly and easily
  determine the IP capacity of a network or subnet. Rather than
  discovering a network is full, an api could be proactively called by
  an operator or monitor to give some measure of when a network is
  reaching its capacity.

  Some things desired from a new API for both network and subnets
  * used IPs - How many IPs are reserved from a network/subnet
  * total IPs - The capacity of IPs for this network/subnet
  * Enough information about the network/subnet to be able to fetch detailed 
information about the resource (possible examples: id, name)

  Naturally used_ips/total_ips gives the user a way to determine the
  percentage the resource has been consumed.

  Some references to those needing this API:
  * Philidelphia operators at the OPs meetup expressed great interest after 
watching a presentation describing this use.
  * GoDaddy in-house implementation: In use for 1+ years. Also called by 
in-house NetworkAwareFilterScheduler. GoDaddy 
implementation:https://github.com/godaddy/openstack-neutron/commit/fcf325f9f9f7a9f87ba6bc1c53f9212d0e2decee
  * Rackspace implementation: 
https://github.com/rackerlabs/quark/blob/master/quark/ip_availability.py#L48

  Some notes about related patches (added 2015-11-17):
  * https://review.openstack.org/180803 (Neutron Spec)
  * https://review.openstack.org/#/c/212955 (Neutron patch)
  * https://review.openstack.org/#/c/234541 (Second Neutron patch)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1457986/+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 1475792] Re: [RFE] Get me a network

[Armando Migliaccio]

Code completed.

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

Title:
  [RFE] Get me a network

Status in neutron:
  Fix Released

Bug description:
  As part of the "get me a network" work outlined in
  https://review.openstack.org/#/c/196803/ we need to be able to auto-
  allocate Neutron networks for tenants.  This is an RFE for those
  changes.

  The current Neutron v2 api calls that Nova makes to neutron live in
  nova/network/neutronv2/api.py - specifically in
  _get_available_networks().  In the 'nova boot' case where no network
  has been specified, it makes two calls to neutron:

  # (1) Retrieve non-public network list owned by the tenant.
  search_opts = {'tenant_id': project_id, 'shared': False}
  nets = neutron.list_networks(**search_opts).get('networks', [])
  # (2) Retrieve public network list.
  search_opts = {'shared': True}
  nets += neutron.list_networks(**search_opts).get('networks', []) 

  The first will get any existing networks with this tenant_id, the
  second any shared networks the admin as pre-configured.  If nothing
  exists the boot will error out and fail.

  I'm proposing a new API, tentatively called "retrieve_networks", that
  while similar to "list_networks", can also be given additional
  information such as a flag parameter, that can signal neutron to auto-
  allocate a network and return it to the caller.  This will be created
  as an extension, such that a caller could determine if it is supported
  before calling it (or falling-back to the old method).

  The arguments to it can either be similar to "list_networks", or
  something like { ids: [], tenant_id: None, flags: [] }, where flags
  can be one or more values such as:

  SHARED - return any shared networks
  ALLOCATE - if no network exists, auto-allocate one based on config settings

  This new API call would only need to be used from the call to
  _get_available_networks() in allocate_for_instance(), and not from the
  others.

  This could either be a single-step process, where a single POST is
  done, or a two-step process, such that a GET is used first.  We need
  to ask the API working group what the current recommendation would be.
  An alternative approach would be to put this logic in a library that
  Nova can call, rather than baking it into Nova.

  The neutron configuration will be done in a new database table, such
  that updating config files and restarting services are not required.
  Initially, this will be just a few variables:

   - network name to use (private_network)
   - subnet name to use (private_subnet)
   - subnet cidr to use (10.0.0.0/24)
   - router name to use (private_router)
   - external network to attach router to (must be a UUID ?)

  This information - names and CIDR range for the initial subnet, can be
  the same for every tenant since they are private networks and over-
  lapping IPs are allowed in this case.  The recommendation would be to
  use an address range in the RFC 1918 space unless otherwise specified.

  A future enhancement could be to use subnet_pools for this.

  In order to eliminate duplicate default networks being created, the
  database layer MUST use some sort of distributed locking (based on
  tenant_id) such that simultaneous calls to different neutron API
  servers for this new resource do not both succeed.  The preferred
  outcome is for the second (and subsequent) calls to block, and return
  the network allocated by the first.

  So it's in one place, the details that still need some ironing are:

  1) Get recommendation from API working group
  2) DB schema
  3) DB locking
  4) Buy-in from Nova, as this affects the nova-neutron API
  5) Type of beer desired for first landed patch :)  It's Friday here people!

  Please feel free to comment!

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1475792/+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 1547331] [NEW] AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url

[Julian Edwards]

Public bug reported:

If you create a client using a session and an endpoint override, if you
then call authenticate() on the client it blows up with the error

AuthorizationFailure: Authorization failed: Cannot authenticate without
an auth_url

There is a comment in the code that the newer  behaviour with sessions is to 
now authenticate with the server on the first call, but:
 - is authenticate() still supposed to work?
 - if not, how can you pre-auth before any work is done to validate 
user-supplied credentials?

** Affects: python-keystoneclient
 Importance: Undecided
 Status: New

** Project changed: keystone => python-keystoneclient

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

Title:
  AuthorizationFailure: Authorization failed: Cannot authenticate
  without an auth_url

Status in python-keystoneclient:
  New

Bug description:
  If you create a client using a session and an endpoint override, if
  you then call authenticate() on the client it blows up with the error

  AuthorizationFailure: Authorization failed: Cannot authenticate
  without an auth_url

  There is a comment in the code that the newer  behaviour with sessions is to 
now authenticate with the server on the first call, but:
   - is authenticate() still supposed to work?
   - if not, how can you pre-auth before any work is done to validate 
user-supplied credentials?

To manage notifications about this bug go to:
https://bugs.launchpad.net/python-keystoneclient/+bug/1547331/+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 1545101] Re: "TypeError: __init__() takes exactly 3 arguments (2 given)" in n-api logs for nova metadata api request

[Armando Migliaccio]

Looks like my grenade fix that removed the deprecated middleware [1] did
the trick. We got a clean pass in [2].

[1] 
http://logs.openstack.org/00/281600/6/experimental/gate-grenade-dsvm-neutron-multinode/40e16c8/logs/etc/nova/api-paste.ini.txt.gz
[2] 
http://logs.openstack.org/00/281600/6/experimental/gate-grenade-dsvm-neutron-multinode/40e16c8/logs/testr_results.html.gz


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

** Changed in: grenade
   Status: New => Confirmed

** Changed in: neutron
 Assignee: Sean M. Collins (scollins) => (unassigned)

** No longer affects: 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/1545101

Title:
  "TypeError: __init__() takes exactly 3 arguments (2 given)" in n-api
  logs for nova metadata api request

Status in grenade:
  Confirmed
Status in OpenStack Compute (nova):
  In Progress

Bug description:
  http://logs.openstack.org/59/265759/24/experimental/gate-grenade-dsvm-
  neutron-
  
multinode/8f1deec/logs/new/screen-n-api.txt.gz?level=INFO#_2016-02-12_16_28_16_860

  2016-02-12 16:28:16.860 20168 INFO nova.metadata.wsgi.server [-] Traceback 
(most recent call last):
File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 470, 
in handle_one_response
  result = self.application(self.environ, start_response)
File "/usr/local/lib/python2.7/dist-packages/paste/urlmap.py", line 216, in 
__call__
  return app(environ, start_response)
File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
  resp = self.call_func(req, *args, **self.kwargs)
File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
  return self.func(req, *args, **kwargs)
File "/opt/stack/new/nova/nova/api/ec2/__init__.py", line 32, in __call__
  return webob.exc.HTTPException(message=_DEPRECATION_MESSAGE)
  TypeError: __init__() takes exactly 3 arguments (2 given)

  This only shows up in the gate-grenade-dsvm-neutron-multinode job
  which is not running the n-api-meta service but is running the neutron
  metadata service, which has a bunch of warnings because it's not
  getting valid responses back from the nova metadata API (b/c it's not
  running):

  http://logs.openstack.org/59/265759/24/experimental/gate-grenade-dsvm-
  neutron-multinode/8f1deec/logs/new/screen-q-meta.txt.gz?level=TRACE

To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1545101/+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 1547290] [NEW] We currently do not generate Javascript API docs

[Richard Jones]

Public bug reported:

We should!

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  We currently do not generate Javascript API docs

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  We should!

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1547290/+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 1547283] [NEW] hacking rules for callback notifications

[Armando Migliaccio]

Public bug reported:

Callbacks were made available during the Liberty timeframe [1]. They
have been put to use in a number of places, like [2] and [3].

Currently there's no formal convention or place where to locate callback
notifications. This can represent a potential drawback where an
inexperienced developer may accidentally add a duplicated notification
(with exact signature) without carefully checking for existing
notifications. A reviewer can also easily miss the error during code
review.

This could lead to callbacks called multiple times: so long as callbacks
are designed to be idempotent, this is fine, but if they aren't, then
this could lead to unexpected results.

We should add a hacking rule that validates that a patch introducing a
new notification hook, does not duplicate the exact signature of an
existing notification.

[1] http://docs.openstack.org/developer/neutron/devref/callbacks.html
[2] 
https://github.com/openstack/neutron/commit/868e67b480b08cc815d802cf950547c6b5ac0153
[3] 
https://github.com/openstack/neutron/commit/593b64dee4c0923fc85d6656e29a2beb27f27b17

** Affects: neutron
 Importance: Wishlist
 Status: Confirmed


** Tags: low-hanging-fruit

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

** Tags added: low-hanging-fruit

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

** Description changed:

  Callbacks were made available during the Liberty timeframe [1]. They
  have been put to use in a number of places, like [2] and [3].
  
  Currently there's no formal convention or place where to locate callback
  notifications. This can represent a potential drawback where an
  inexperienced developer may accidentally add a duplicated notification
  (with exact signature) without carefully checking for existing
  notifications. A reviewer can also easily miss the error during code
  review.
  
  This could lead to callbacks called multiple times: so long as callbacks
  are designed to be idempotent, this is fine, but if they aren't, then
- it's trouble.
+ this could lead to unexpected results.
  
  We should add a hacking rule that validates that a patch introducing a
  new notification hook, does not duplicate the exact signature of an
  existing notifications.
  
  [1] http://docs.openstack.org/developer/neutron/devref/callbacks.html
  [2] 
https://github.com/openstack/neutron/commit/868e67b480b08cc815d802cf950547c6b5ac0153
  [3] 
https://github.com/openstack/neutron/commit/593b64dee4c0923fc85d6656e29a2beb27f27b17

** Description changed:

  Callbacks were made available during the Liberty timeframe [1]. They
  have been put to use in a number of places, like [2] and [3].
  
  Currently there's no formal convention or place where to locate callback
  notifications. This can represent a potential drawback where an
  inexperienced developer may accidentally add a duplicated notification
  (with exact signature) without carefully checking for existing
  notifications. A reviewer can also easily miss the error during code
  review.
  
  This could lead to callbacks called multiple times: so long as callbacks
  are designed to be idempotent, this is fine, but if they aren't, then
  this could lead to unexpected results.
  
  We should add a hacking rule that validates that a patch introducing a
  new notification hook, does not duplicate the exact signature of an
- existing notifications.
+ existing notification.
  
  [1] http://docs.openstack.org/developer/neutron/devref/callbacks.html
  [2] 
https://github.com/openstack/neutron/commit/868e67b480b08cc815d802cf950547c6b5ac0153
  [3] 
https://github.com/openstack/neutron/commit/593b64dee4c0923fc85d6656e29a2beb27f27b17

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

Title:
  hacking rules for callback notifications

Status in neutron:
  Confirmed

Bug description:
  Callbacks were made available during the Liberty timeframe [1]. They
  have been put to use in a number of places, like [2] and [3].

  Currently there's no formal convention or place where to locate
  callback notifications. This can represent a potential drawback where
  an inexperienced developer may accidentally add a duplicated
  notification (with exact signature) without carefully checking for
  existing notifications. A reviewer can also easily miss the error
  during code review.

  This could lead to callbacks called multiple times: so long as
  callbacks are designed to be idempotent, this is fine, but if they
  aren't, then this could lead to unexpected results.

  We should add a hacking rule that validates that a patch introducing a
  new notification hook, does not duplicate the exact signature of an
  existing notification.

  [1] http://docs.openstack.org/developer/neutron/devref/callbacks.html
  [2] 
https://github.com/openstack/neutron/commit/868e67b480b08cc815d802cf950547c6b5ac0153
  [3] 

[Yahoo-eng-team] [Bug 1547279] [NEW] nova.tests.unit.compute.test_compute.ComputeTestCase.test_run_instance_queries_macs takes an average of 1 minute to run

[Matt Riedemann]

Public bug reported:

http://status.openstack.org//openstack-health/#/job/gate-nova-
python27?groupKey=project=hour=P1M shows that the
nova.tests.unit.compute.test_compute.ComputeTestCase.test_run_instance_queries_macs
unit test is taking around 1 minute to run.  It looks like most things
should be stubbed out properly in that test so I'm not sure what's
causing the holdup.

** Affects: nova
 Importance: Medium
 Status: Confirmed


** Tags: compute testing

** Tags added: compute testing

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

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

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

Title:
  
nova.tests.unit.compute.test_compute.ComputeTestCase.test_run_instance_queries_macs
  takes an average of 1 minute to run

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  http://status.openstack.org//openstack-health/#/job/gate-nova-
  python27?groupKey=project=hour=P1M shows that
  the
  
nova.tests.unit.compute.test_compute.ComputeTestCase.test_run_instance_queries_macs
  unit test is taking around 1 minute to run.  It looks like most things
  should be stubbed out properly in that test so I'm not sure what's
  causing the holdup.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547279/+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 1546780] Re: Open vSwitch conntrack based firewall driver

[Armando Migliaccio]

I am sure this needs extensive user documentation, more than developer
documentation

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

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

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

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

Title:
  Open vSwitch conntrack based firewall driver

Status in neutron:
  Confirmed
Status in openstack-manuals:
  Confirmed

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

  commit ef29f7eb9a2a37133eacdb7f019b48ec3f9a42c3
  Author: Jakub Libosvar 
  Date:   Tue Sep 1 15:50:48 2015 +

  Open vSwitch conntrack based firewall driver
  
  This firewall requires OVS 2.5+ version supporting conntrack and kernel
  conntrack datapath support (kernel>=4.3). For more information, see
  https://github.com/openvswitch/ovs/blob/master/FAQ.md
  
  As part of this new entry points for current reference firewalls were
  added.
  
  Configuration:
  in openvswitch_agent.ini:
  - in securitygroup section set firewall_driver to openvswitch
  
  DocImpact
  Closes-bug: #1461000
  
  Co-Authored-By: Miguel Angel Ajo Pelayo 
  Co-Authored-By: Amir Sadoughi 
  
  Change-Id: I13e5cda8b5f3a13a60b14d80e54f198f32d7a529

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1546780/+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 1542417] Re: LDAP backend lacks support for user_description_attribute mapping

[OpenStack Infra]

Reviewed:  https://review.openstack.org/276873
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=448778a51126a79676e9f9ffcc9eaf4c06288a73
Submitter: Jenkins
Branch:master

commit 448778a51126a79676e9f9ffcc9eaf4c06288a73
Author: Rudolf Vriend 
Date:   Fri Feb 5 19:58:53 2016 +0100

Adds user_description_attribute mapping support to the LDAP backend

The LDAP backend supports mapping between LDAP and keystone user
attributes via the 'user__attribute' settings in the
LDAP driver configuration.

The current implementation is incomplete, since there is no support for
specifying a 'user_description_attribute' setting for user get (read)
operations.

This change adds support to the LDAP backend for mapping of user
description attributes via a 'user_description_attribute' configuration
also during user retrieval.

Change-Id: I30b63306beae3379aa8c29d0df3f327369d3f2a6
Closes-Bug: #1542417


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

Title:
  LDAP backend lacks support for user_description_attribute mapping

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  The LDAP backend supports mapping between LDAP and keystone user
  attributes via the 'user__attribute' settings in the
  ldap driver configuration.

  The implementation is incomplete, since there is no support for
  specifying a 'user_description_attribute' setting.

  As long as the LDAP attribute name is 'description', one could specify
  a 1:1 'user_additional_attribute_mapping = description:description'
  mapping as a workaround, which would yield the desired result.

  In case a users full name is stored in a different attribute (as with
  many AD backends where the users full name is contained in the
  'displayName' attribute) there is no way to specify this mapping and
  results in users having no description.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1542417/+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 1545199] Re: preserve subnet-create behavior in presence of subnet pools

[OpenStack Infra]

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

commit d38aeade9db7169955b4524a5fc8d814067dec15
Author: Armando Migliaccio 
Date:   Thu Feb 11 20:56:20 2016 -0800

Preserve subnet_create behavior in presence of subnet pools

The development of the auto_allocate extension, which relies on subnet
pools, revealed some discrepancies in the behavior of the subnet_create
API: if a user specifies a cidr on subnet_create like he/she is used
to, the API outcome changes in presence of default subnetpools. For
instance the command 'neutron subnet-create network ' returns a
subnet associated to a pool, if a default pool exists, but it does not
otherwise. At the same time, attempting to create a subnet without
passing any detail but the ip version also behaves unexpectedly
depending on the state of the system.

Whilst this could be considered convenient in some circumstances,
it is problematic for a couple of reasons: a) it breaks a well defined
contract (backward compat of the subnet-create command), and b) it
leads to ambiguity of the API.

This patch restores the semantic of the subnet_create API where it is
mandatory to specify CIDR/IP version regardless of the conditions
under which the request is issued. On the other hand, associating
subnets to subnet pools will have to be more prescriptive, and
require the user to explicitly state his/her intentions when creating
the subnet: if a user does want a subnet (CIDR) to belong to a subnet
pool, he/she will have to state so, either by specifying a subnetpool
name/uuid, or by asking for a default one.

This will be tackled as a follow-up, especially in order to address the
needs of prefix delegation which currently rely on the ambiguous
behavior that this patch is fixing.

Closes-bug: 1545199

DocImpact: subnetpools can be used to simplify IPAM, and can be specified
during subnet creation.

Change-Id: Idf516ed9db24d779742cdff0584b48182a8502d6


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

Title:
  preserve subnet-create behavior in presence of subnet pools

Status in neutron:
  Fix Released

Bug description:
  The subnet create command [1] creates a subnet that does not belong to
  a subnet pool. When a default subnet pool is present, however, the
  subnet is implicitly assigned to the default pool, and hence the
  command triggers prefix validation.

  [1] neutron subnet-create   

  It's probably better to preserve the semantic of the message
  irrespective of the presence of the (default) pool.

  If a user does want the association, he/she can either be explicit (by
  passing --subnetpool/-id) or simply specify the family of the subnet,
  like in [2] (by default the client chooses v4).

  This happens in master.

  [2] neutron subnet-create  --ip-version 

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1545199/+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 1545101] Re: "TypeError: __init__() takes exactly 3 arguments (2 given)" in n-api logs for nova metadata api request

[Armando Migliaccio]

Results from run [1] still didn't yield any result. So that's my analysis: the 
api-paste file is not upgraded and that still contains an ec2 middleware 
(ec2faultwrap). This is the one that responds with 404, inline with what patch 
[3] does. That's the reason why we don't see the trace from Sean's patch [4]. I 
think the bug lies in grenade: if we get rid of ec2faultwrap we should get past 
the 404 error.
 
[1] 
http://logs.openstack.org/00/281600/4/experimental/gate-grenade-dsvm-neutron-multinode/28b0630//logs/new/
[2] 
http://logs.openstack.org/00/281600/4/experimental/gate-grenade-dsvm-neutron-multinode/28b0630//logs/etc/nova/api-paste.ini.txt.gz
[3] https://review.openstack.org/#/c/279721/3/nova/api/ec2/__init__.py
[4] https://review.openstack.org/#/c/282025/ 

** Also affects: grenade
   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/1545101

Title:
  "TypeError: __init__() takes exactly 3 arguments (2 given)" in n-api
  logs for nova metadata api request

Status in grenade:
  New
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress

Bug description:
  http://logs.openstack.org/59/265759/24/experimental/gate-grenade-dsvm-
  neutron-
  
multinode/8f1deec/logs/new/screen-n-api.txt.gz?level=INFO#_2016-02-12_16_28_16_860

  2016-02-12 16:28:16.860 20168 INFO nova.metadata.wsgi.server [-] Traceback 
(most recent call last):
File "/usr/local/lib/python2.7/dist-packages/eventlet/wsgi.py", line 470, 
in handle_one_response
  result = self.application(self.environ, start_response)
File "/usr/local/lib/python2.7/dist-packages/paste/urlmap.py", line 216, in 
__call__
  return app(environ, start_response)
File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 130, in 
__call__
  resp = self.call_func(req, *args, **self.kwargs)
File "/usr/local/lib/python2.7/dist-packages/webob/dec.py", line 195, in 
call_func
  return self.func(req, *args, **kwargs)
File "/opt/stack/new/nova/nova/api/ec2/__init__.py", line 32, in __call__
  return webob.exc.HTTPException(message=_DEPRECATION_MESSAGE)
  TypeError: __init__() takes exactly 3 arguments (2 given)

  This only shows up in the gate-grenade-dsvm-neutron-multinode job
  which is not running the n-api-meta service but is running the neutron
  metadata service, which has a bunch of warnings because it's not
  getting valid responses back from the nova metadata API (b/c it's not
  running):

  http://logs.openstack.org/59/265759/24/experimental/gate-grenade-dsvm-
  neutron-multinode/8f1deec/logs/new/screen-q-meta.txt.gz?level=TRACE

To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1545101/+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 1547068] Re: Configuration option 'fake_call' is not used

[Ed Leafe]

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

Title:
  Configuration option 'fake_call' is not used

Status in OpenStack Compute (nova):
  New

Bug description:
  As of stable/liberty there is a configuration option named
  'fake_call', defined in nova/network/manager.py, and has been moved in
  Mitaka to nova/conf/network.py as part of the config option cleanup.
  Running grep on this name shows no usage of this option anywhere in
  the nova code base. Since it is not used, it should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547068/+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 1547068] Re: Configuration option 'fake_call' is not used

[Ed Leafe]

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

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

Title:
  Configuration option 'fake_call' is not used

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  As of stable/liberty there is a configuration option named
  'fake_call', defined in nova/network/manager.py, and has been moved in
  Mitaka to nova/conf/network.py as part of the config option cleanup.
  Running grep on this name shows no usage of this option anywhere in
  the nova code base. Since it is not used, it should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547068/+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 1369465] Re: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend

[Matt Riedemann]

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

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

** Changed in: nova/liberty
 Assignee: (unassigned) => Tony Breeds (o-tony)

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

Title:
  nova resize doesn't resize(extend) rbd disk files when using rbd disk
  backend

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) liberty series:
  In Progress
Status in nova package in Ubuntu:
  Confirmed

Bug description:
  tested with nova trunk commit eb860c2f219b79e4f4c5984415ee433145197570

  Configured Nova to use rbd disk backend

  nova.conf

  [libvirt]
  images_type=rbd

  instances booted successfully and instance disks are in rbd pools,
  when perform a nova resize  to an existing instance,  memory and CPU
  changed to be new flavors but instance disks size doesn't change

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1369465/+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 1473567] Re: Fernet tokens fail tempest runs

[Morgan Fainberg]

** Changed in: keystone
   Status: In Progress => Won't Fix

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

Title:
  Fernet tokens fail tempest runs

Status in OpenStack Identity (keystone):
  Won't Fix
Status in tempest:
  Fix Released

Bug description:
  It seems testing an OpenStack instance that was deployed with Fernet tokens 
fails on some of the tempest tests.  In my case these tests failed:
  http://paste.openstack.org/show/363017/

  bknudson also found similar in a test patch:
 https://review.openstack.org/#/c/195780

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1473567/+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 1547214] [NEW] Domain created by keystone-manage bootstrap has no description

[Brant Knudson]

Public bug reported:


When keystone-manage bootstrap creates a domain it doesn't have a description. 
Normally the description is like "Owns users and tenants (i.e. projects) 
available on Identity API v2."

Testing this requires that the default domain isn't created by keystone-
manage db_sync, which it normally is.

** Affects: keystone
 Importance: Undecided
 Assignee: Brant Knudson (blk-u)
 Status: In Progress

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

Title:
  Domain created by keystone-manage bootstrap has no description

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  
  When keystone-manage bootstrap creates a domain it doesn't have a 
description. Normally the description is like "Owns users and tenants (i.e. 
projects) available on Identity API v2."

  Testing this requires that the default domain isn't created by
  keystone-manage db_sync, which it normally is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1547214/+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 1547197] [NEW] "Additional properties are not allowed" message not getting translated

[Lauren Taylor]

Public bug reported:

During a Nova v2.1 request, the message "Additional properties are not
allowed" is not being translated.  Other parts of the API request are
being translated, but the error message seems to be hard-coded in
English.


Example:

URL:
https://9.47.82.183/powervc/openstack/compute/v2.1/dbcb06068c6e4a3fb59326a0bce653f0/os-hosts/ip9_114_181_60

Body:
{
"registration": {
"host_display_name": "MyKVMHost_updated1",
"access_ip": "912.123.233.44",
"user_id": "root",
"password": "Passw0rd"
}
}

Response:
400

{"badRequest": {"message": "Additional properties are not allowed
(u'registration' was unexpected)", "code": 400}}

** Affects: nova
 Importance: Undecided
 Assignee: Lauren Taylor (lmtaylor)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Lauren Taylor (lmtaylor)

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

Title:
  "Additional properties are not allowed" message not getting translated

Status in OpenStack Compute (nova):
  New

Bug description:
  During a Nova v2.1 request, the message "Additional properties are not
  allowed" is not being translated.  Other parts of the API request are
  being translated, but the error message seems to be hard-coded in
  English.

  
  Example:

  URL:
  
https://9.47.82.183/powervc/openstack/compute/v2.1/dbcb06068c6e4a3fb59326a0bce653f0/os-hosts/ip9_114_181_60

  Body:
  {
  "registration": {
  "host_display_name": "MyKVMHost_updated1",
  "access_ip": "912.123.233.44",
  "user_id": "root",
  "password": "Passw0rd"
  }
  }

  Response:
  400

  {"badRequest": {"message": "Additional properties are not allowed
  (u'registration' was unexpected)", "code": 400}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547197/+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 1547164] [NEW] Documentation warning on openvswitch_firewall.rst

[Victor Morales]

Public bug reported:

After executing :

$ tox -e doc

I'm  getting the following warning:

reading sources... [100%] stadium/sub_projects


Warning, treated as error:
/opt/stack/neutron/doc/source/devref/openvswitch_firewall.rst:25: WARNING: 
Title underline too short.

Open vSwitch Firewall Driver
===

** Affects: neutron
 Importance: Undecided
 Assignee: Victor Morales (electrocucaracha)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Victor Morales (electrocucaracha)

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

Title:
  Documentation warning on openvswitch_firewall.rst

Status in neutron:
  In Progress

Bug description:
  After executing :

  $ tox -e doc

  I'm  getting the following warning:

  reading sources... [100%] stadium/sub_projects

  
  Warning, treated as error:
  /opt/stack/neutron/doc/source/devref/openvswitch_firewall.rst:25: WARNING: 
Title underline too short.

  Open vSwitch Firewall Driver
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1547164/+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 1523759] Re: Nova (liberty): Unexpected API Error.

[Stepan G. Fedorov]

Got the same on Ubuntu 14.04 + liberty

On kilo with exact same configuration it works as expected.

Backtrace from nova-api.log below:

2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
[req-5c52a618-b76f-4678-91fa-6e69995761b7 6762c038fb8248cda5e5679dba68c453 
baa518b6a590402695eefd19d80e2e57 - - -] Unexpected exception in API method
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 478, 
in wrapped
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 73, in 
wrapper
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/servers.py", line 
611, in create
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
**create_kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/hooks.py", line 149, in inner
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions rv = 
f(*args, **kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 1581, in create
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
check_server_group_quota=check_server_group_quota)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 1181, in 
_create_instance
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
auto_disk_config, reservation_id, max_count)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 955, in 
_validate_and_build_base_options
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
pci_request_info, requested_networks)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/network/neutronv2/api.py", line 1059, in 
create_pci_requests_for_sriov_ports
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions neutron = 
get_client(context, admin=True)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/nova/network/neutronv2/api.py", line 237, in 
get_client
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
auth_token = _ADMIN_AUTH.get_token(_SESSION)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/base.py", line 
200, in get_token
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions return 
self.get_access(session).auth_token
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/base.py", line 
240, in get_access
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
self.auth_ref = self.get_auth_ref(session)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/auth/identity/v2.py", line 88, 
in get_auth_ref
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 
authenticated=False, log=False)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/session.py", line 501, in post
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions return 
self.request(url, 'POST', **kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/utils.py", line 337, in inner
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions   File 
"/usr/lib/python2.7/dist-packages/keystoneclient/session.py", line 401, in 
request
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions raise 
exceptions.from_response(resp, method, url)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions NotFound: The 
resource could not be found. (HTTP 404)
2016-02-18 13:18:35.454 13902 ERROR nova.api.openstack.extensions 

[Yahoo-eng-team] [Bug 1512636] Re: VLAN tag information is added to "port" after calling the agent setup port function

[OpenStack Infra]

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

commit b83fedbd78a441cf34d53dba35a3ccff7d8f4ac5
Author: Rodolfo Alonso Hernandez 
Date:   Tue Jan 26 12:45:22 2016 +

Add VLAN tag info to port before applying SG initial setup.

Before the initial SG firewall setup, the VLAN tag is added to
the port information; this assignment is removed from _bind_devices
function. This value is needed by some SG agent
implementations.

This implementation mantains the actual function call order:
  - Apply security groups.
  - Bind devices.

Change-Id: I6f70083a1d42a5be4545956406a96d6579145c00
Closes-Bug: #1512636


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

Title:
  VLAN tag information is added to "port" after calling the agent setup
  port function

Status in neutron:
  Fix Released

Bug description:
  Description:
  During the creation or modification of a neutron port, in the 
ovs_neutron_agent, the OVS tag information is added to the port after calling 
the SG agent function to setup the port.

  Pre-conditions:
  File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py
  Funtion: process_network_ports

  Step-by-step:
  During the creation or the modification of a neutron port, the following 
calls are made:
  - treat_devices_added_or_updated
  - sg_agent.setup_port_filters
  - _bind_devices

  The problem is the "port" variable if fulfilled with the VLAN OVS tag
  information during the _bind_devices call. This information is needed
  for some OVS SG driver implementations, for example
  https://review.openstack.org/#/c/240957/.

  Proposed solution:
  Call _bind_devides before the sg_agent call.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1512636/+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 1536916] Re: nova's task_state still is migrating after live migration failed

[OpenStack Infra]

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

commit 30d5d805c10b0cc6e474fe1292b2c6549fc07d33
Author: ShaoHe Feng 
Date:   Tue Feb 2 09:41:33 2016 +

reset task_state after select_destinations failed.

During live migration, there maybe exception when let scheduler
select destination, and live migration will abort. But the task
state of the instance still keep migrating, then we can not take
any action on this instance.

We need to recover the state of the task as None.
We should also recover the vm_state.

Change-Id: If1cae8f4c9037f7821554a94d4440f66d9538794
Closes-bug: #1536916


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

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

Title:
  nova's task_state still is migrating after live migration failed

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Environment:
  distribution:
  $ cat /etc/lsb-release
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=14.04
  DISTRIB_CODENAME=trusty
  DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"

  $ sudo virsh version
  Compiled against library: libvirt 1.2.2
  Using library: libvirt 1.2.2
  Using API: QEMU 1.2.2
  Running hypervisor: QEMU 2.0.0

  $ git log --oneline
  806113e Merge "Changed filter_by() to filter() during filtering instances in 
db API"
  ...

  There are two hosts in my environment.

  Host A is controller with compute node.  Host B is only as  compute
  node.

  Produce:

  1. I upgrade the nova code in Host A.  and restart  n-sch, n-cond, n-cpu.
     the nova code in Host B, and restart n-cpu.
 keep n-sch as old version.

  
  2. do live migration
  $ nova live-migration tt
  it report error. "Remote error: UnsupportedVersion Endpoint does not support 
RPC version 4.3. Attempted method: select_destinations
  $ sudo virsh list 
 x
   IdName   State   

 x
    

 x
   26instance-0002  running 

 x

  error details as follow:
  
+--+
  
--+
  | Property | Value
    
|
  
+--+
  
--+
  | OS-DCF:diskConfig| MANUAL
    
|
  | OS-EXT-AZ:availability_zone  | nova
    
|
  | OS-EXT-SRV-ATTR:host | shaohe1
    
|
  | OS-EXT-SRV-ATTR:hostname | tt   


|
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | shaohe1  


|
  | OS-EXT-SRV-ATTR:instance_name| instance-0002


|
  | OS-EXT-SRV-ATTR:kernel_id| 89e91cc1-a40c-4c9f-bcfa-37b0e94d5f57 


|
  | OS-EXT-SRV-ATTR:launch_index | 0 

[Yahoo-eng-team] [Bug 1547142] [NEW] A shelved_offload VM's volumes are still attached to a host

[Shoham Peller]

Public bug reported:

When shelve_offloading a VM, the VM loses it's connection to a host.
However, connection to the host is not terminated to it's volumes, so they are 
still attached to a host.

Afterwards, when the VM is unshleved, nova calls initialize_connection
to the new host for it's volumes, and they are now connected to 2 hosts.

The correct behaviour is to call terminate_connection on the VM's
volumes when it's being shelved_offloaded

** Affects: nova
 Importance: Undecided
 Assignee: Shoham Peller (shoham-peller)
 Status: In Progress

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

Title:
  A shelved_offload VM's volumes are still attached to a host

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  When shelve_offloading a VM, the VM loses it's connection to a host.
  However, connection to the host is not terminated to it's volumes, so they 
are still attached to a host.

  Afterwards, when the VM is unshleved, nova calls initialize_connection
  to the new host for it's volumes, and they are now connected to 2
  hosts.

  The correct behaviour is to call terminate_connection on the VM's
  volumes when it's being shelved_offloaded

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547142/+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 1547098] [NEW] namespace not updated on namespace properties change

[Lei Zhang]

Public bug reported:

When namespace properties are updated using metadata api,   the
updated_at time of namespace doesn't change.

It's not a valid result, updated time of namespace should reflect
changes to properties.  It causes problems for Searchlight.

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

Title:
  namespace not updated on namespace properties change

Status in Glance:
  New

Bug description:
  When namespace properties are updated using metadata api,   the
  updated_at time of namespace doesn't change.

  It's not a valid result, updated time of namespace should reflect
  changes to properties.  It causes problems for Searchlight.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1547098/+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 1547079] [NEW] image not updated on image member change

[Brian Rosmaita]

Public bug reported:

When an image member is added to/deleted from an image, the updated_at
time of the image does not change.

This is misleading because image membership affects image behavior, in
particular, whether an image is visible to (can be booted by) a
particular user.  Even though the image member-list is not part of the
GET v2/images/{image_id} response, *something* about the image has
changed, and the updated_at timestamp should reflect this fact.

(This is causing problems for Searchlight, it's not a purely academic
discussion.)

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

Title:
  image not updated on image member change

Status in Glance:
  New

Bug description:
  When an image member is added to/deleted from an image, the updated_at
  time of the image does not change.

  This is misleading because image membership affects image behavior, in
  particular, whether an image is visible to (can be booted by) a
  particular user.  Even though the image member-list is not part of the
  GET v2/images/{image_id} response, *something* about the image has
  changed, and the updated_at timestamp should reflect this fact.

  (This is causing problems for Searchlight, it's not a purely academic
  discussion.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1547079/+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 1547068] [NEW] Configuration option 'fake_call' is not used

[Ed Leafe]

Public bug reported:

As of stable/liberty there is a configuration option named 'fake_call',
defined in nova/network/manager.py, and has been moved in Mitaka to
nova/conf/network.py as part of the config option cleanup. Running grep
on this name shows no usage of this option anywhere in the nova code
base. Since it is not used, it should be removed.

** Affects: nova
 Importance: Undecided
 Assignee: Ed Leafe (ed-leafe)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Ed Leafe (ed-leafe)

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

Title:
  Configuration option 'fake_call' is not used

Status in OpenStack Compute (nova):
  New

Bug description:
  As of stable/liberty there is a configuration option named
  'fake_call', defined in nova/network/manager.py, and has been moved in
  Mitaka to nova/conf/network.py as part of the config option cleanup.
  Running grep on this name shows no usage of this option anywhere in
  the nova code base. Since it is not used, it should be removed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547068/+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 1547066] [NEW] Test test_live_migration_pause_vm_invalid_migration_state lacks of execution

[Roman Dobosz]

Public bug reported:

In the test test_live_migration_pause_vm_invalid_migration_state there
is an inner function _do_test() defined which actually should be called,
while it does not.

** Affects: nova
 Importance: Undecided
 Assignee: Roman Dobosz (roman-dobosz)
 Status: In Progress


** Tags: live-migration

** Changed in: nova
 Assignee: (unassigned) => Roman Dobosz (roman-dobosz)

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

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

Title:
  Test test_live_migration_pause_vm_invalid_migration_state lacks of
  execution

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  In the test test_live_migration_pause_vm_invalid_migration_state there
  is an inner function _do_test() defined which actually should be
  called, while it does not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547066/+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 1547061] [NEW] openrc v2.sh contains /v3 url

[Bernhard M. Wiedemann]

Public bug reported:

bug 1460150 introduced separate openrc downloads for v2 and v3
but when backporting this to Liberty, we found that the v2 openrc download 
still contained a /v3 URL
which would then cause client failures

The v3 codepath does
context['auth_url'] = utils.fix_auth_url_version(context['auth_url'])

and IMHO for the v2 codepath we would need the inverse replacement. e.g.

 def download_rc_file_v2(request):
 template = 'project/access_and_security/api_access/openrc_v2.sh.template'
 context = _get_openrc_credentials(request)
+context['auth_url'] = context['auth_url'].replace('/v3', '/v2.0')
 return _download_rc_file_for_template(request, context, template)

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  openrc v2.sh contains /v3 url

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  bug 1460150 introduced separate openrc downloads for v2 and v3
  but when backporting this to Liberty, we found that the v2 openrc download 
still contained a /v3 URL
  which would then cause client failures

  The v3 codepath does
  context['auth_url'] = utils.fix_auth_url_version(context['auth_url'])

  and IMHO for the v2 codepath we would need the inverse replacement.
  e.g.

   def download_rc_file_v2(request):
   template = 'project/access_and_security/api_access/openrc_v2.sh.template'
   context = _get_openrc_credentials(request)
  +context['auth_url'] = context['auth_url'].replace('/v3', '/v2.0')
   return _download_rc_file_for_template(request, context, template)

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1547061/+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 1529785] Re: Create snapshot fails on VM containing multiple SRIOV vNICs configured with the same MAC

[OpenStack Infra]

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

commit f93d808bc3ba1c0a97ec46f345fad9c0d00865f8
Author: David Edery 
Date:   Wed Dec 30 02:05:19 2015 +0200

Fix create snapshot failure on VMs with SRIOV

One use-case of guest VM network protection using SRIOV ports is having
two direct ports connected to a VM, each one is related to a network that
is connected to a different physical NIC on the host (e.g. phyNet1 on
eth0 and phyNet2 on eth1). In this use-case, due to some physical NICs
limitations it's advised to configure both ports with the same MAC
address (or else outgoing or incoming traffic will not reach its
destination in case of fail-over).

Snapshot creation on such VMs fails since libvirt's detach-interface
doesn't know which interface of the two to detach and fails. This is why
I've changed the call inside _detach_sriov_ports from (the equivalent
of) detach-interface to _detach_pci_devices with the source-device
pci address of the SRIOV VF (always present in the context of SRIOV
of course).

This fix was tested on a real environment containing the above type of
VMs. test_driver.test_detach_sriov_ports was slightly modified so
that the VIF from which data is sent to _detach_pci_devices will
contain the correct SRIOV values (pci_slot, vlan and hw_veb VIF type)

Change-Id: If3edc1965c01a077eb61984a442e0d778d870d75
Closes-Bug: #1529785


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

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

Title:
  Create snapshot fails on VM containing multiple SRIOV vNICs configured
  with the same MAC

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Use case: 
  SRIOV protection on the guest VM with Intel NICs on the host requires (at one 
scenario) 2 SRIOV ports attached to different physical NICs (e.g. phyNet1 & 
phyNet2) configured with the same MAC address (and as a result, same IP).

  Problem: 
  Create snapshot on such VM fails

  Reason: 
  (from nova-compute.log)
  2015-12-28 12:03:37.594 4616 ERROR oslo_messaging.rpc.dispatcher 
[req-57a8c147-b945-43e8-9915-5a52d3b7deb9 18800eca7d674a60995039349089e8da 
0b5c257568424704854f8d10342edf80 - - -] Exception during message handling: 
operation failed: multiple devices matching mac address fa:16:3e:e1:7f:3f found
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 142, 
in _dispatch_and_reply
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher 
executor_callback))
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 186, 
in _dispatch
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher 
executor_callback)
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 130, 
in _do_dispatch
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 6917, in 
snapshot_instance
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher return 
self.manager.snapshot_instance(ctxt, image_id, instance)
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", line 88, in wrapped
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher payload)
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 85, in __exit__
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher 
six.reraise(self.type_, self.value, self.tb)
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", line 71, in wrapped
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher return 
f(self, context, *args, **kw)
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 341, in 
decorated_function
  2015-12-28 12:03:37.594 4616 TRACE oslo_messaging.rpc.dispatcher 
LOG.warning(msg, e, instance_uuid=instance_uuid)
  2015-12-28 12:03:37.594 4616 TRACE 

[Yahoo-eng-team] [Bug 1298242] Re: live_migration_uri should be dependant on virt_type

[OpenStack Infra]

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

commit 3159c8fd5bea80c820e58bd38d96f5f8fe8f4503
Author: Alvaro Lopez Garcia 
Date:   Tue Apr 21 10:39:30 2015 +0200

libvirt: make live_migration_uri flag dependent on virt_type

The default value for the "live_migration_uri" flag should be
dependent on the "virt_type" flag, as the "connection_uri" flag is. This
way, an operator can set the "virt_type" flag without the need to check
for each individual uri.

DocImpact: Changed the default value of the "live_migration_uri" flag,
that now is dependent on the "virt_type".
Closes-Bug: #1298242
Change-Id: Id54f7bdfa14a19da41da554b13ba9496ee525c71


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

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

Title:
  live_migration_uri should be dependant on virt_type

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The "live_migration_uri" default should be dependent on the
  "virt_type" flag (this is the same behavior as "connection_uri").

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298242/+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 1540254] Re: "#flake8: noqa" is using incorrectly

[OpenStack Infra]

Reviewed:  https://review.openstack.org/281778
Committed: 
https://git.openstack.org/cgit/openstack/murano/commit/?id=8b5fcdb21fe0f07e674498b31fcedfa831e8d068
Submitter: Jenkins
Branch:master

commit 8b5fcdb21fe0f07e674498b31fcedfa831e8d068
Author: Bo Wang 
Date:   Thu Feb 18 19:37:56 2016 +0800

Remove incorrectly used "# flake8: noqa"

"# flake8: noqa" option disables all checks for the whole file.
To disable one line we should use "# noqa".
Remove unused "# flake8: noqa" and fix hidden hacking errors.

Change-Id: I8b26cb0e7e5ad4a838099c7aa3ced31b96f28ca2
Closes-Bug: #1540254


** Changed in: murano
   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/1540254

Title:
  "#flake8: noqa" is using incorrectly

Status in Designate:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Murano:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-novaclient:
  Fix Released

Bug description:
  "# flake8: noqa" option disables all checks for the whole file. To
  disable one line we should use "# noqa".

  Refer to: https://pypi.python.org/pypi/flake8
  
https://github.com/openstack/python-keystoneclient/commit/3b766c51438396a0ab0032de309c9d56e275e0cb

To manage notifications about this bug go to:
https://bugs.launchpad.net/designate/+bug/1540254/+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 1546742] Re: Unable to create an instance

[Rossella Sblendido]

It doesn't look like a bug in Neutron but it seems that something is
misconfigured/not working properly in your cloud

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

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

Title:
  Unable to create an instance

Status in neutron:
  Invalid

Bug description:
  I am trying to create an instance from command line.

  System requirements:
  OS: CentOS 7
  Openstack Liberty

  Reproduce a bug:
  openstack server create --debug --flavor m1.tiny --image 
97836f02-2059-40a8-99ba-1730e97aa101 --nic 
net-id=256eea0b-06fe-49a0-880d-6ecc8afeff5a --security-group default --key-name 
vladf public-instance

  Program output:
  Instantiating network client: 
  Instantiating network api: 
  REQ: curl -g -i -X GET 
http://controller:9696/v2.0/networks.json?fields=id=256eea0b-06fe-49a0-880d-6ecc8afeff5a
 -H "User-Agent: python-neutronclient" -H "Accept: application/json" -H 
"X-Auth-Token: {SHA1}c153a4df19fb8e5fb095ea656a8dabbe26d88e13"
  RESP: [503] date: Wed, 17 Feb 2016 22:04:50 GMT connection: keep-alive 
content-type: text/plain; charset=UTF-8 content-length: 100 
x-openstack-request-id: req-72933065-8db0-4dd4-af82-4a529cd08e90
  RESP BODY: 503 Service Unavailable

  The server is currently unavailable. Please try again at a later time.


  Error message: 503 Service Unavailable

  The server is currently unavailable. Please try again at a later time.

  
  503 Service Unavailable

  The server is currently unavailable. Please try again at a later time.

  
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 374, in 
run_subcommand
  result = cmd.run(parsed_args)
File "/usr/lib/python2.7/site-packages/cliff/display.py", line 92, in run
  column_names, data = self.take_action(parsed_args)
File "/usr/lib/python2.7/site-packages/openstackclient/common/utils.py", 
line 45, in wrapper
  return func(self, *args, **kwargs)
File 
"/usr/lib/python2.7/site-packages/openstackclient/compute/v2/server.py", line 
452, in take_action
  nic_info["net-id"])
File "/usr/lib/python2.7/site-packages/openstackclient/network/common.py", 
line 32, in find
  data = list_method(**kwargs)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
102, in with_params
  ret = self.function(instance, *args, **kwargs)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
574, in list_networks
  **_params)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
307, in list
  for r in self._pagination(collection, path, **params):
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
320, in _pagination
  res = self.get(path, params=params)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
293, in get
  headers=headers, params=params)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
270, in retry_request
  headers=headers, params=params)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
211, in do_request
  self._handle_fault_response(status_code, replybody)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
185, in _handle_fault_response
  exception_handler_v20(status_code, des_error_body)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
83, in exception_handler_v20
  message=message)
  NeutronClientException: 503 Service Unavailable

  The server is currently unavailable. Please try again at a later time.

  
  clean_up CreateServer: 503 Service Unavailable

  The server is currently unavailable. Please try again at a later time.

  
  Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/openstackclient/shell.py", line 112, 
in run
  ret_val = super(OpenStackShell, self).run(argv)
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 255, in run
  result = self.run_subcommand(remainder)
File "/usr/lib/python2.7/site-packages/cliff/app.py", line 374, in 
run_subcommand
  result = cmd.run(parsed_args)
File "/usr/lib/python2.7/site-packages/cliff/display.py", line 92, in run
  column_names, data = self.take_action(parsed_args)
File "/usr/lib/python2.7/site-packages/openstackclient/common/utils.py", 
line 45, in wrapper
  return func(self, *args, **kwargs)
File 
"/usr/lib/python2.7/site-packages/openstackclient/compute/v2/server.py", line 
452, in take_action
  nic_info["net-id"])
File "/usr/lib/python2.7/site-packages/openstackclient/network/common.py", 
line 32, in find
  data = list_method(**kwargs)
File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
102, in with_params
  ret = self.function(instance, *args, 

[Yahoo-eng-team] [Bug 1547055] [NEW] libvirt: make live_migration_uri flag dependent on virt_type

[OpenStack Infra]

Public bug reported:

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

commit 3159c8fd5bea80c820e58bd38d96f5f8fe8f4503
Author: Alvaro Lopez Garcia 
Date:   Tue Apr 21 10:39:30 2015 +0200

libvirt: make live_migration_uri flag dependent on virt_type

The default value for the "live_migration_uri" flag should be
dependent on the "virt_type" flag, as the "connection_uri" flag is. This
way, an operator can set the "virt_type" flag without the need to check
for each individual uri.

DocImpact: Changed the default value of the "live_migration_uri" flag,
that now is dependent on the "virt_type".
Closes-Bug: #1298242
Change-Id: Id54f7bdfa14a19da41da554b13ba9496ee525c71

** Affects: nova
 Importance: Undecided
 Status: New


** Tags: doc nova

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

Title:
  libvirt: make live_migration_uri flag dependent on virt_type

Status in OpenStack Compute (nova):
  New

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

  commit 3159c8fd5bea80c820e58bd38d96f5f8fe8f4503
  Author: Alvaro Lopez Garcia 
  Date:   Tue Apr 21 10:39:30 2015 +0200

  libvirt: make live_migration_uri flag dependent on virt_type
  
  The default value for the "live_migration_uri" flag should be
  dependent on the "virt_type" flag, as the "connection_uri" flag is. This
  way, an operator can set the "virt_type" flag without the need to check
  for each individual uri.
  
  DocImpact: Changed the default value of the "live_migration_uri" flag,
  that now is dependent on the "virt_type".
  Closes-Bug: #1298242
  Change-Id: Id54f7bdfa14a19da41da554b13ba9496ee525c71

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547055/+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 1379581] Re: live migration (block migration) fails at post_live_migration_at_destination function, but the status of this instance is still "migrating".

[OpenStack Infra]

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

commit 89b1fecce116bc44f558e76cbb5dc43497ea67cc
Author: Pawel Koniszewski 
Date:   Mon Feb 1 11:56:59 2016 +0100

Update instance host in post live migration even when exception occurs

Currently when, e.g., port binding fails on destination host nova
loses track of running VM. Operator needs to change record in DB
manually in order to recover VM in nova and then perform operations
on destination host to repair such VM. Because VM is on destination
host already it should be updated regardless of post live migration
at destination result.

Change-Id: Ibb5158f453abd9717e6d2ab501295351ca9d0dcf
Closes-Bug: #1379581


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

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

Title:
  live migration (block migration) fails at
  post_live_migration_at_destination function, but the status of this
  instance is still "migrating".

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  I have two compute node, host opencos114-93 and host opencos179-24.
  A migration failed at function of " post_live_migration_at_destination", but 
the status of this instance is still migrating.
  Log is as follows:
  http://paste.openstack.org/show/121143/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1379581/+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 1538204] Re: Failed to stop nova-api in grenade tests

[Davanum Srinivas (DIMS)]

16 hits in last week for message:"dictionary changed size during
iteration" logstash query. Only one of them is a FAILURE though
unrelated to this bug.

-- Dims

** Changed in: oslo.service
   Status: Confirmed => Invalid

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

Title:
  Failed to stop nova-api in grenade tests

Status in OpenStack Compute (nova):
  Invalid
Status in oslo.service:
  Invalid

Bug description:
  Saw this during a grenade run:

  2016-01-26 16:12:58.553 22016 ERROR oslo_service.threadgroup   File 
"/usr/local/lib/python2.7/dist-packages/oslo_service/service.py", line 143, in 
clear
  2016-01-26 16:12:58.553 22016 ERROR oslo_service.threadgroup for sig in 
self._signal_handlers:
  2016-01-26 16:12:58.553 22016 ERROR oslo_service.threadgroup RuntimeError: 
dictionary changed size during iteration

  (From http://logs.openstack.org/25/272425/1/gate/gate-grenade-dsvm-
  heat/b32eda2/).

  May be due to a change in oslo, but it's in the old process so I'm not
  sure it ought to use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1538204/+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 1546731] Re: 1df244e556f5_add_unique_ha_router_agent_port_bindings revision is not postgres compliant

[OpenStack Infra]

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

commit 77a9c1c0d49faf9f799d78437f5f1c4863629af2
Author: Cedric Brandily 
Date:   Wed Feb 17 21:25:46 2016 +0100

Fix GROUP BY usage for PostgreSQL in migrations

Currently get_duplicate_l3_ha_port_bindings[1] is not postgres-compliant
because it's GROUP BY usage is not postgres-compliant: everything in the
SELECT list must be aggregated or in GROUP BY.

This change updates get_duplicate_l3_ha_port_bindings to respect
previous PostgreSQL rule.

[1] neutron.db.migration.alembic_migrations.versions.mitaka.expand\
 .1df244e556f5_add_unique_ha_router_agent_port_bindings

Change-Id: Ie99dd31d695ab89814a86e50d45ababe53bd56fd
Closes-Bug: #1546731


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

Title:
  1df244e556f5_add_unique_ha_router_agent_port_bindings revision is not
  postgres compliant

Status in neutron:
  Fix Released

Bug description:
  1df244e556f5_add_unique_ha_router_agent_port_bindings.py[1] is not
  postgres-compliant[2] because it uses GROUP BY incorrectly:

  column "ha_router_agent_port_bindings.port_id" must appear in the
  GROUP BY clause or be used in an aggregate function

  
  [1] in package neutron.db.migration.alembic_migrations.versions.mitaka.expand
  [2]
  # Starting with a liberty neutron db
  #$ neutron-db-manage upgrade head

  
  INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
  INFO  [alembic.runtime.migration] Will assume transactional DDL.
  Traceback (most recent call last):
File "/home/user/projects/os/neutron/.tox/py27/bin/neutron-db-manage", line 
10, in 
  sys.exit(main())
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
744, in main
  return_val |= bool(CONF.command.func(config, CONF.command.name))
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
218, in do_upgrade
  run_sanity_checks(config, revision)
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
726, in run_sanity_checks
  script_dir.run_env()
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/script/base.py",
 line 397, in run_env
  util.load_python_file(self.dir, 'env.py')
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/pyfiles.py",
 line 81, in load_python_file
  module = load_module_py(module_id, path)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/util/compat.py",
 line 79, in load_module_py
  mod = imp.load_source(module_id, path, fp)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/env.py",
 line 126, in 
  run_migrations_online()
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/env.py",
 line 120, in run_migrations_online
  context.run_migrations()
File "", line 8, in run_migrations
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/environment.py",
 line 797, in run_migrations
  self.get_context().run_migrations(**kw)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/alembic/runtime/migration.py",
 line 303, in run_migrations
  for step in self._migrations_fn(heads, self):
File "/home/user/projects/os/neutron/neutron/db/migration/cli.py", line 
719, in check_sanity
  script.module.check_sanity(context.connection)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/versions/mitaka/expand/1df244e556f5_add_unique_ha_router_agent_port_bindings.py",
 line 57, in check_sanity
  res = get_duplicate_l3_ha_port_bindings(connection)
File 
"/home/user/projects/os/neutron/neutron/db/migration/alembic_migrations/versions/mitaka/expand/1df244e556f5_add_unique_ha_router_agent_port_bindings.py",
 line 70, in get_duplicate_l3_ha_port_bindings
  .having(sa.func.count() > 1)).all()
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
 line 2588, in all
  return list(self)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
 line 2736, in __iter__
  return self._execute_and_instances(context)
File 
"/home/user/projects/os/neutron/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/orm/query.py",
 line 2751, in _execute_and_instances
  result = conn.execute(querycontext.statement, self._params)
File 

[Yahoo-eng-team] [Bug 1482171] Re: cinder ceph volume cannot attach to instance in Kilo

[Sean Dague]

Original reported said they could no longer reproduce the bug.

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

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

Title:
  cinder ceph volume cannot attach to instance in Kilo

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Kilo release on Centos 7.

  when nova  attach a ceph based volume to an existing instance, do not
  notify cinder(?) about the attaching so I cannot detach and/or delete
  the volume later. The volume actualy attached to the instance

  ## Cinder volume and nova instance

  $ cinder list
  
+--+---+-+--+--+--+-+-+
  |  ID  |   Status  | Name| Size | 
Volume Type  | Bootable | Multiattach | Attached to |
  
+--+---+-+--+--+--+-+-+
  | 736ead1d-2c59-4415-a0a3-8a1e8379872d | available | test volume |  10  | 
ceph_cluster |  false   |False| |
  
+--+---+-+--+--+--+-+-+

  $ nova list
  
+--+---+++-+-+
  | ID   | Name  | Status | Task State | Power 
State | Networks|
  
+--+---+++-+-+
  | 890cce5e-8e5c-4871-ba80-6fd5a4045c2f | ubu 1 | ACTIVE | -  | 
Running | daddy-net=10.0.0.19 |
  
+--+---+++-+-+


  ## attach volume to instance
  $ nova volume-attach 890cce5e-8e5c-4871-ba80-6fd5a4045c2f 
736ead1d-2c59-4415-a0a3-8a1e8379872d
  +--+--+
  | Property | Value|
  +--+--+
  | device   | /dev/vdb |
  | id   | 736ead1d-2c59-4415-a0a3-8a1e8379872d |
  | serverId | 890cce5e-8e5c-4871-ba80-6fd5a4045c2f |
  | volumeId | 736ead1d-2c59-4415-a0a3-8a1e8379872d |
  +--+--+


  ## cinder (and nova) do not know anything about attaching ('attached
  to' field is empty):

  $ cinder list
  
+--+---+-+--+--+--+-+-+
  |  ID  |   Status  | Name| Size | 
Volume Type  | Bootable | Multiattach | Attached to |
  
+--+---+-+--+--+--+-+-+
  | 736ead1d-2c59-4415-a0a3-8a1e8379872d | available | test volume |  10  | 
ceph_cluster |  false   |False| |
  
+--+---+-+--+--+--+-+-+


  ## while  the instance can use the new volume:

  root@ubu-1:~# mkfs.ext4 /dev/vdb 
  mke2fs 1.42.12 (29-Aug-2014)
  Creating filesystem with 2621440 4k blocks and 655360 inodes
  Filesystem UUID: 450b9169-087e-4dba-aac6-4a23593a5a97
  Superblock backups stored on blocks: 
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (32768 blocks): done
  Writing superblocks and filesystem accounting information: done 

  root@ubu-1:~# mount /dev/vdb /mnt/
  root@ubu-1:~# df -h
  Filesystem  Size  Used Avail Use% Mounted on
  udev997M 0  997M   0% /dev
  tmpfs   201M  4.6M  196M   3% /run
  /dev/disk/by-label/cloudimg-rootfs   20G  858M   19G   5% /
  tmpfs  1001M 0 1001M   0% /dev/shm
  tmpfs   5.0M 0  5.0M   0% /run/lock
  tmpfs  1001M 0 1001M   0% /sys/fs/cgroup
  tmpfs   201M 0  201M   0% /run/user/1000
  /dev/vdb9.8G   23M  9.2G   1% /mnt


  
  ## finally I cannot delete the volume,  cinder stuck "deleting'  state and do 
not delete it from ceph  pool
  $ cinder list
  
+--+--+-+--+--+--+-+-+
  |  ID  |  Status  | Name| Size | 
Volume Type  | Bootable | Multiattach | Attached to |
  

[Yahoo-eng-team] [Bug 1523425] Re: Nova timesout when "Boot from image (create new volume )" operation is tried using image> 10 GB

[Sean Dague]

These are user configurable options in nova.

block_device_allocate_retries = 60
block_device_allocate_retries_interval = 3

That means that out of the box we wait about 3 minutes for volumes.
That's a pretty reasonable default. If you need a longer time in your
environment due to it being slow, you should bump these values to be
appropriate to your environment.

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

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

Title:
  Nova timesout when "Boot from image (create new volume )" operation is
  tried using image> 10 GB

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

Bug description:
  Nova boot from image (Create new volume) fails when image size is
  greater then 10 GB.

  Steps to reproduce-

  1- Upload a 10 GB image 
  2- Try launching an instance using option "boot from image (Create new 
volume)"

  
  Actual Behaviour-

  Instance will fail to launch at block device mapping with error   -
  "VolumeNotCreated: Volume 1ea1406f-5c84-4042-b8d7-93ec48666912 did not
  finish being created even after we waited 194 seconds or 61 attempts"

  During this process boot volume is created successfully.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1523425/+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 1508442] Re: LOG.warn is deprecated

[OpenStack Infra]

Reviewed:  https://review.openstack.org/281565
Committed: 
https://git.openstack.org/cgit/openstack/networking-powervm/commit/?id=16af89ab925bae246efd52123739aa9f73b2bb19
Submitter: Jenkins
Branch:master

commit 16af89ab925bae246efd52123739aa9f73b2bb19
Author: kairoaraujo 
Date:   Wed Feb 17 20:44:13 2016 -0200

Initial seed of hacking rules

It is an initial seed of hacking rules based on neutron and
nova-powervm.

Closes-Bug: 1508442

Change-Id: Ie700e86e6bf881ca4174abf56a7ec36e99fcc68e


** Changed in: networking-powervm
   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/1508442

Title:
  LOG.warn is deprecated

Status in anvil:
  In Progress
Status in Aodh:
  In Progress
Status in Astara:
  Fix Released
Status in Barbican:
  Fix Released
Status in bilean:
  Fix Released
Status in Blazar:
  In Progress
Status in Ceilometer:
  Fix Released
Status in cloud-init:
  In Progress
Status in cloudkitty:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in django-openstack-auth:
  Fix Released
Status in django-openstack-auth-kerberos:
  In Progress
Status in DragonFlow:
  Fix Released
Status in ec2-api:
  Fix Released
Status in Evoque:
  In Progress
Status in gce-api:
  In Progress
Status in Glance:
  In Progress
Status in glance_store:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in KloudBuster:
  Fix Released
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in Mistral:
  In Progress
Status in networking-arista:
  In Progress
Status in networking-calico:
  In Progress
Status in networking-cisco:
  In Progress
Status in networking-fujitsu:
  Fix Released
Status in networking-odl:
  In Progress
Status in networking-ofagent:
  In Progress
Status in networking-plumgrid:
  In Progress
Status in networking-powervm:
  Fix Released
Status in networking-vsphere:
  In Progress
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in nova-powervm:
  Fix Released
Status in nova-solver-scheduler:
  In Progress
Status in octavia:
  In Progress
Status in openstack-ansible:
  In Progress
Status in oslo.cache:
  Fix Released
Status in oslo.privsep:
  In Progress
Status in Packstack:
  Fix Released
Status in python-dracclient:
  In Progress
Status in python-magnumclient:
  Fix Released
Status in RACK:
  In Progress
Status in python-watcherclient:
  In Progress
Status in shaker:
  In Progress
Status in Solum:
  Fix Released
Status in tempest:
  In Progress
Status in tripleo:
  In Progress
Status in trove-dashboard:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated in Python 3 [1] . But it still used in a few
  places, non-deprecated LOG.warning should be used instead.

  Note: If we are using logger from oslo.log, warn is still valid [2],
  but I agree we can switch to LOG.warning.

  [1]https://docs.python.org/3/library/logging.html#logging.warning
  [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85

To manage notifications about this bug go to:
https://bugs.launchpad.net/anvil/+bug/1508442/+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 1546433] Re: nova.service.Service.kill() is unused and orphaned

[Sean Dague]

I'm not really convinced this is a bug, it's an interface we've got
which is fine, even if it's only used by testing. If you want to
annotate it as such, that's fine as well.

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

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

Title:
  nova.service.Service.kill() is unused and orphaned

Status in OpenStack Compute (nova):
  Opinion

Bug description:
  oslo.service.Service doesn't provide kill method in it's interface [1].
  Nova is implementing it (it removes service record from the DB), but
  obviously it isn't actually ever called. This was probably orphaned long
  time ago (last changes in 2011).

  I think the method should go away.

  [1]
  
https://github.com/openstack/oslo.service/blob/master/oslo_service/service.py#L88-L109

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1546433/+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 1546883] Re: poll_rebooting_instances in nova libvirt driver is not implemented

[Sean Dague]

I'm not really sure why this would be implemented. libvirt has an event
mechanism so I don't think polling like this isn't required.

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

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

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

** Tags added: libvirt

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

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

Title:
  poll_rebooting_instances in nova libvirt driver is not implemented

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

Bug description:
  In nova.virt.libvirt.driver poll_rebooting_instance has no
  implementation

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1546883/+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 1547032] [NEW] Enhance API tests for neutron-vpnaas

[Paul Michali]

Public bug reported:

Once VPN API tests are operational again (bug 1483417), they should be
enhanced to exercise the new endpoint group APIs and the modifications
to other APIs resulting from the new endpoint groups (e.g. no local
subnet specified for vpnservice, and no peer subnets specified for ipsec
site connection API - instead these are in endpoint groups).

This will require mappings in the tempest, as is being restored by
1546786.

This will improve the coverage of the API.

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: vpnaas

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

Title:
  Enhance API tests for neutron-vpnaas

Status in neutron:
  New

Bug description:
  Once VPN API tests are operational again (bug 1483417), they should be
  enhanced to exercise the new endpoint group APIs and the modifications
  to other APIs resulting from the new endpoint groups (e.g. no local
  subnet specified for vpnservice, and no peer subnets specified for
  ipsec site connection API - instead these are in endpoint groups).

  This will require mappings in the tempest, as is being restored by
  1546786.

  This will improve the coverage of the API.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1547032/+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 1547031] [NEW] Can't distinguish users through openid login

[yechengkun]

Public bug reported:

Accrounding to the doc 
(http://docs.openstack.org/developer/keystone/configure_federation.html), I 
parse openid login in my devstack. and i have success login with google account.
  but there is a program, how can i distinguish users? I know all the 
federation users are in one group, and the group is relate with a project. In 
my devstack, all of users login through openid have the same project , and have 
the same resource, when i create a resource and orther user login through 
openid can also see the resource
  I don't know whether somewhere i parsed is wrong, this is my mapping:
{
"local": [
{
"user": {
"name": "{3}",
"realname": "{2}",
"email": "{3}"
},
"group": {
"name": "demo",
"domain": {
"name": "Default"
}
}
}
],
"remote": [
{
"type": "HTTP_OIDC_SUB"
},
{
"type": "HTTP_OIDC_ISS"
},
{
"type": "HTTP_OIDC_NAME"
},
{
"type": "HTTP_OIDC_EMAIL"
}
]
}

devstack address: www.scorpio.ml

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: federation

** Description changed:

-   Accrounding to the doc 
(http://docs.openstack.org/developer/keystone/configure_federation.html), I 
parse openid login in my devstack. and i have success login with google account.
-   but there is a program, how can i distinguish users? I know all the 
federation users are in one group, and the group is relate with a project. In 
my devstack, all of users login through openid have the same project , and have 
the same resource, when i create a resource and orther user login through 
openid can also see the resource
-   I don't know whether somewhere i parsed is wrong, this is my mapping(see 
the Attachment)
+ Accrounding to the doc 
(http://docs.openstack.org/developer/keystone/configure_federation.html), I 
parse openid login in my devstack. and i have success login with google account.
+   but there is a program, how can i distinguish users? I know all the 
federation users are in one group, and the group is relate with a project. In 
my devstack, all of users login through openid have the same project , and have 
the same resource, when i create a resource and orther user login through 
openid can also see the resource
+   I don't know whether somewhere i parsed is wrong, this is my mapping(see 
the Attachment)
  
  devstack address: www.scorpio.ml

** Description changed:

  Accrounding to the doc 
(http://docs.openstack.org/developer/keystone/configure_federation.html), I 
parse openid login in my devstack. and i have success login with google account.
    but there is a program, how can i distinguish users? I know all the 
federation users are in one group, and the group is relate with a project. In 
my devstack, all of users login through openid have the same project , and have 
the same resource, when i create a resource and orther user login through 
openid can also see the resource
-   I don't know whether somewhere i parsed is wrong, this is my mapping(see 
the Attachment)
+   I don't know whether somewhere i parsed is wrong, this is my mapping:
+ {
+ "local": [
+ {
+ "user": {
+ "name": "{3}",
+ "realname": "{2}",
+ "email": "{3}"
+ },
+ "group": {
+ "name": "demo",
+ "domain": {
+ "name": "Default"
+ }
+ }
+ }
+ ],
+ "remote": [
+ {
+ "type": "HTTP_OIDC_SUB"
+ },
+ {
+ "type": "HTTP_OIDC_ISS"
+ },
+ {
+ "type": "HTTP_OIDC_NAME"
+ },
+ {
+ "type": "HTTP_OIDC_EMAIL"
+ }
+ ]
+ }
  
  devstack address: www.scorpio.ml

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

Title:
  Can't distinguish users through openid login

Status in OpenStack Identity (keystone):
  New

Bug description:
  Accrounding to the doc 
(http://docs.openstack.org/developer/keystone/configure_federation.html), I 
parse openid login in my devstack. and i have success login with google account.
    but there is a program, how can i distinguish users? I know all the 
federation users are in one group, and the group is relate with a project. In 
my devstack, all of users login through openid have the same project , and have 

[Yahoo-eng-team] [Bug 1525739] Re: Hyper-V: stable/liberty, mismatched requirements causes CI jobs to fail.

[Claudiu Belu]

** Changed in: networking-hyperv
   Status: In Progress => Fix Committed

** Changed in: networking-hyperv
   Importance: Undecided => High

** Changed in: networking-hyperv
 Assignee: (unassigned) => Tony Breeds (o-tony)

** No longer affects: nova

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

Title:
  Hyper-V: stable/liberty, mismatched requirements causes CI jobs to
  fail.

Status in networking-hyperv:
  Fix Committed

Bug description:
  CI JObs in (at least) stable/liberty nova are failing with "Can not
  start the nova-compute service. The manual run failed as well."

   . 
http://64.119.130.115/nova/256180/1/Hyper-V_logs/create-environment-c2-r2-u22.openstack.tld.log.gz
 indicates that nova-compute didn't start
   . 
http://64.119.130.115/nova/256180/1/Hyper-V_logs/c2-r2-u22/process_error.txt.gz
 Shows an issue with oslo.log semver
   . 
http://64.119.130.115/nova/256180/1/Hyper-V_logs/create-environment-c2-r2-u22.openstack.tld.log.gz
 Indicates that it's comming from networking-hyperv 
(oslo.log<1.12.0,>=1.8.0)

  Looking a little deeper it seems that we have some mitaka libraries
  installed which are incompatible with the liberty versions.

  Opening this bug as a focal point for fixes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-hyperv/+bug/1525739/+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 1540254] Re: "#flake8: noqa" is using incorrectly

[Wang Bo]

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

** Changed in: murano
 Assignee: (unassigned) => Wang Bo (chestack)

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

Title:
  "#flake8: noqa" is using incorrectly

Status in Designate:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Murano:
  In Progress
Status in python-heatclient:
  Fix Released
Status in python-novaclient:
  Fix Released

Bug description:
  "# flake8: noqa" option disables all checks for the whole file. To
  disable one line we should use "# noqa".

  Refer to: https://pypi.python.org/pypi/flake8
  
https://github.com/openstack/python-keystoneclient/commit/3b766c51438396a0ab0032de309c9d56e275e0cb

To manage notifications about this bug go to:
https://bugs.launchpad.net/designate/+bug/1540254/+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 1495669] Re: domain-specific drivers does not honor the list_limit set in domain-specific conf file

[OpenStack Infra]

Reviewed:  https://review.openstack.org/266989
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=7b6364a4f85e93ac77f740e654b681dfbd47e1f8
Submitter: Jenkins
Branch:master

commit 7b6364a4f85e93ac77f740e654b681dfbd47e1f8
Author: Boris Bobrov 
Date:   Wed Jan 13 18:26:51 2016 +0300

Use the driver to get limits

@response_truncated was used to set the limit of returned entries. It
asked the driver about the limit and set it to hints. With
domain-specific configs, there are multiple driver instances and each of
them carries domain-specific config.

However, with domain-specific configs, the driver is not yet configured
at that point, because sometimes the manager needs to perform additional
actions in order to understand what domain it works with. Because of
that, @response_truncated always got the limit from the default driver,
not from the one actually used for the domain.

Move the logic of setting the limit from the decorator to a private
method, call it after determining the domain and driver.

Change-Id: I1748d491b047e33712380da731c272f9d471ec0a
Closes-Bug: 1495669


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

Title:
  domain-specific drivers does not honor the list_limit set in domain-
  specific conf file

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Step to reproduce:

  1. enable domain_specific drivers in keystone.conf

domain_specific_drivers_enabled = true
domain_configurations_from_database = false
domain_config_dir = /etc/keystone/domains

  2. set the global list_limit to 2 in keystone.conf

[default]
list_limit = 2

  3. create a new domain, along with the corresponding domain-specific
  conf in /etc/keystone/domains/ and set the list_limit to 3 at the
  driver level

  [identity]
  driver = ldap
  list_limit = 5

  [ldap]

  url = ldap://localhost
  ...

  4. restart Keystone and do user list for the specific domain and
  notice that only 2 users are returned

  
  Interestingly, the list_limit set in the [identity] section in keystone.conf 
works.  i.e.

[default]
list_limit = 2

[identity]
list_limit = 5

  We just can't override it in the domain-specific conf file.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1495669/+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 1538387] Re: fdb_chg_ip_tun throwing exception because fdb_entries not in correct format

[OpenStack Infra]

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

commit 8dcf39aae7a099e01bd322891526c134e87e6b1b
Author: Kevin Benton 
Date:   Wed Jan 27 02:17:01 2016 -0800

Unmarshall portinfo on update_fdb_entries calls

The unmarshalling function was not aware of the data
structure used by update_fdb_entries, so it would not
setup PortInfo named tuples in the 'before' and 'after'
fields. This would break the fdb_chg_ip_tun function
which expected to be able to use named attributes.

This patch adjusts the unmarshalling function to be aware
of this datastrucure.

This has likely been broken since the change that added
named tuples here: I7f8c93b0e12ee0179bb23dfbb3a3d814615b1c2e
It probably went undetected for so long because the exception
will only be observed when the updated entry does not have
an agent IP that matches the local agent's (i.e. not single-node).
Even in a multi-node environment, this would only trigger an
error when the fixed_ips of a port changed so it wouldn't show
up in a normal port wiring life-cycle.

Closes-Bug: #1538387
Change-Id: I0aacb3af9ebd160ebfb801f77b186075303c3df5


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

Title:
  fdb_chg_ip_tun throwing exception because fdb_entries not in correct
  format

Status in neutron:
  Fix Released

Bug description:
  I've been trying to track down failures in the DVR multinode job.  I'm
  now tripping over this one.

  For context I've been focusing on a single change, but if you see a
  failure in the gate-tempest-dsvm-neutron-dvr-multinode-full job you'll
  probably be able to find similar info.  This is the change:

  http://logs.openstack.org/77/17/4/check/gate-tempest-dsvm-neutron-
  dvr-multinode-full/5abca7b/logs/

  The screen-q-agt log shows a traceback here:

  http://logs.openstack.org/77/17/4/check/gate-tempest-dsvm-neutron-
  dvr-multinode-
  full/5abca7b/logs/screen-q-agt.txt.gz#_2016-01-18_10_11_29_715

  
  2016-01-18 10:11:29.724 12932 ERROR oslo_messaging.rpc.dispatcher   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/l2pop/rpc_manager/l2population_rpc.py",
 line 312, in fdb_chg_ip_tun
  2016-01-18 10:11:29.724 12932 ERROR oslo_messaging.rpc.dispatcher 
mac_ip.mac_address,
  2016-01-18 10:11:29.724 12932 ERROR oslo_messaging.rpc.dispatcher 
AttributeError: 'list' object has no attribute 'mac_address'
  2016-01-18 10:11:29.724 12932 ERROR oslo_messaging.rpc.dispatcher

  The info passed to fdb_chg_ip_tun() should have a "PortInfo"
  namedtuple as data, but from the line before we can see it doesn't:

  DEBUG neutron.plugins.ml2.drivers.l2pop.rpc_manager.l2population_rpc
  [req-671e8634-c753-4002-acfd-68515dd44f29 None None]
  
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent
  method fdb_chg_ip_tun called with arguments (,
  
, {u'c4ae0757-e3e5-419c-b2ba-4d7817964237':
  {u'10.209.192.28': {u'before': [[u'fa:16:3e:8d:2e:48',
  u'2003:0:0:1::1']]}}}, '10.208.193.94', {u'7ca0dcf2-fb63-4959-92ee-
  cc757da8d120':

  So from this it's clear that _unmarshall_fdb_entries() either hasn't
  been called, or didn't do anything.

  Looking over in screen-q-svc.log for the info before the RPC call
  finds:

  DEBUG neutron.plugins.ml2.drivers.l2pop.rpc [req-
  f32790a5-0160-47b9-89b4-763b9c23bc08 tempest-
  TestGettingAddress-2071048693 tempest-TestGettingAddress-1817548879]
  Fanout notify l2population agents at q-agent-notifier the message
  update_fdb_entries with {'chg_ip': {u'c4ae0757-e3e5-419c-b2ba-
  4d7817964237': {u'10.208.193.94': {'before':
  [PortInfo(mac_address=u'fa:16:3e:8d:2e:48',
  ip_address=u'2003:0:0:1::1')] _notification_fanout
  /opt/stack/new/neutron/neutron/plugins/ml2/drivers/l2pop/rpc.py:47

  This is the message right before _marshall_fdb_entries() was called to
  convert the PortInfo into [, ] pairs, and from the above it
  looks like it did.

  I'm just starting to look at this now, but maybe someone more familiar
  with l2pop has a guess at what's broken.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1538387/+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 1480212] Re: Log warning: 'takes at most 1 positional argument'

[javeme]

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

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

Title:
  Log warning: 'takes at most 1 positional argument'

Status in OpenStack Dashboard (Horizon):
  New
Status in python-keystoneclient:
  Invalid

Bug description:
  Log warning: 'create takes at most 1 positional argument (2 given)'
  when I create[1] a user with V3.

  The reason is that we have not accounted for `self`.

  [1]: https://github.com/openstack/python-
  keystoneclient/blob/master/keystoneclient/v3/users.py#L49

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1480212/+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 1546910] [NEW] args pass to precommit event should include the complete info

[yalei wang]

Public bug reported:

We introduced the PRECOMMIT_XXX event, but the kwargs passed to it do
not include the complete info of neutron db like AFTER_XXX event. For
example, the id of the new created sg/rule.

** Affects: neutron
 Importance: Undecided
 Assignee: yalei wang (yalei-wang)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => yalei wang (yalei-wang)

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

Title:
  args pass to precommit event should include the complete info

Status in neutron:
  New

Bug description:
  We introduced the PRECOMMIT_XXX event, but the kwargs passed to it do
  not include the complete info of neutron db like AFTER_XXX event. For
  example, the id of the new created sg/rule.

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