date:20160913

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

commit 5b7c71a327d735134fa0eeb4427d0e1bd1f7d1e5
Author: gaozhengwei 
Date:   Wed Aug 31 23:11:10 2016 +0800

Preventing iptables rule to be thrashed

When update meter label or rule, iptables_manager will update iptables
rule in router's namespace. In order to, it will clean traffic counter
number collected in interval time, the other iptables always trashing
that will clean old iptalbes rule and generate new same significance
iptables rule.

Change-Id: Ide2b26c98587258175234acded38ce481b7e7f76
Closes-Bug: #1618879


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

Title:
  iptables rule always be thrashed when update a little rule

Status in neutron:
  Fix Released
Status in OpenStack Security Advisory:
  Incomplete

Bug description:
  When update meter label or rule, iptables_manager will update iptables
  rule in router's namespace. In order to, it will clean traffic counter
  number collected in interval time, the other iptables always trashing
  that will clean old iptalbes rule and generate new same significance
  iptables rule.

  the example from update meter label:
   
  Generated by iptables_manager
  *filter
  :neutron-meter-neutron-met - [0:0]
  :neutron-meter-r-00599199-632 - [0:0]
  -I FORWARD 2 -j neutron-meter-FORWARD
  -D FORWARD 4
  -I INPUT 1 -j neutron-meter-INPUT
  -D INPUT 3
  -I OUTPUT 2 -j neutron-meter-OUTPUT
  -D OUTPUT 4
  -I neutron-filter-top 1 -j neutron-meter-local
  -D neutron-filter-top 3
  -D neutron-meter-l-00e4e019-099 1
  -I neutron-meter-l-00e4e019-099 1
  -D neutron-meter-l-01e4e019-099 1
  -I neutron-meter-l-01e4e019-099 1
  -I neutron-meter-r-00599199-632 1 -i qg-f0732f6f-8e -d 192.168.10.0/24 -j 
neutron-meter-l-00599199-632
  COMMIT
  # Completed by iptables_manager
  # Generated by iptables_manager
  *raw
  -I OUTPUT 1 -j neutron-meter-OUTPUT
  -D OUTPUT 3
  -I PREROUTING 1 -j neutron-meter-PREROUTING
  -D PREROUTING 3
  COMMIT
  # Completed by iptables_manager

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618879/+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 1622010] Re: MySQL rounds timestamps

Reviewed:  https://review.openstack.org/368244
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=301b6a7bc770830485937f0b9927a26e2e5ec8c8
Submitter: Jenkins
Branch:master

commit 301b6a7bc770830485937f0b9927a26e2e5ec8c8
Author: Lance Bragstad 
Date:   Fri Sep 9 22:10:02 2016 +

Consistently round down timestamps

This is one of the ways we can prevent race conditions with backends that 
round
datetime objects or strings before persisting them.

Change-Id: Iaee0ec8c7acd512b9d93096ce8306a2952061c7a
Closes-Bug: 1622010


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

Title:
  MySQL rounds timestamps

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  It was known that MySQL would *truncate* datetimes before inserting
  them. In the process of debugging issues with making fernet the
  default, I found that MySQL will actually *round* in some cases.

  To create I did the following:

  1.) Stand up a fresh devstack
  2.) Switch `CONF [token] provider = fernet` in /etc/keystone/keystone.conf
  3.) Litter keystone with timing debug statements - 
http://cdn.pasteraw.com/57im8ttixkootaf7xc6t3gjr79wirz6
  4.) Run ./run_tempest.sh 
tempest.api.identity.admin.v3.test_users.UsersV3TestJSON.test_update_user_password
 repeatedly.

  The tests creates a new user, changes their password, authenticates
  for a fresh token, and expects the new token to be valid. When the
  test fails, keystone returns a 404 saying the token isn't found even
  though the token was created more than one second after the password
  was changed...

  Here is the output from tempest: 
http://cdn.pasteraw.com/srnx0722bfpgzx39sd9tapd0686c4yl
  Here is the output from keystone with additional logging: 
http://cdn.pasteraw.com/k75ivklu77ffz8eh2yqjpkb8a4b51iq

  We can see that the revocation event is being persisted at
  2016-09-09T19:54:49.664802Z. When the retrieve the revocation event
  later we can see that value has been rounded to
  2016-09-09T19:54:50.00Z. The same is true for the event's
  issued_before key.

  What I think is happening here is that when revocation events are
  created during the last half of a second - the timestamps are getting
  rounded to the next second. This naturally works against the Fernet
  implementation because the Fernet implementation will *always*
  truncate it's issued_at time [0].

  In the worst case, if a revocation event is created at
  2016-09-09T19:54:49.664802Z it will be stored with an issued_before
  time of 2016-09-09T19:54:50.00Z. If a Fernet token is created
  right after 2016-09-09T19:54:49.664802Z, it will have an issued_at
  time of 2016-09-09T19:54:49.00Z, resulting in a 404 instead of a
  200.

  I did this on a devstack install on Ubuntu 16.04 and MySQL Server
  version: 5.7.13-0ubuntu0.16.04.2 (Ubuntu)

  [0]
  
https://github.com/pyca/cryptography/blob/ee9710fad662616454cbf99f3b47d547ccd9/src/cryptography/fernet.py#L49

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1622010/+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 1528758] Re: SIGUSR1 is deprecated in Guru mediation

2016-09-13 Thread lilintan

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

** Changed in: neutron
 Assignee: (unassigned) => lilintan (lilintan)

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

Title:
  SIGUSR1 is deprecated in Guru mediation

Status in Magnum:
  Fix Released
Status in neutron:
  New

Bug description:
  Guru mediation now registers SIGUSR1 and SIGUSR2 by default for
  backward compatibility. SIGUSR1 will no longer be registered in a
  future release, so please use SIGUSR2 to generate reports[1].

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/magnum/+bug/1528758/+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 1570465] Re: [Pluggable IPAM] AutomaticAddressRequest is created manually instead of using factory

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

commit 2e23ed32978697400a2b3d324f0878f3539836c3
Author: Aliaksandr Dziarkach 
Date:   Fri Jul 15 21:00:18 2016 +0300

fix port address allocation for auto-addr subnet

AutomaticAddressRequest is created manually in
add_auto_addr_on_network_ports.
But expected workkflow is to use address request factory, that can be
overriden by ipam driver to deliver custom AddressRequest classes.
Added code to follow expected workflow.
Now factory method called for SLAAC allocations, so third party ipam
driver can deliver custom AddressRequest for these allocations.

Change-Id: I95d6097a6bc30107e2819c484e9718f6a5ee619e
Closes-Bug: 1570465


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

Title:
  [Pluggable IPAM] AutomaticAddressRequest is created manually instead
  of using factory

Status in neutron:
  Fix Released

Bug description:
  AutomaticAddressRequest is created manually in 
add_auto_addrs_on_network_ports [1]. But expcected workflow is to use address 
request factory, that can be overriden by ipam driver to deliver custom 
AddressRequest classes.
  Address request factory generates ip request based on input.

  Expected way of preparing address request can be seen in [2]:

factory = ipam_driver.get_address_request_factory()
ip_request = factory.get_request(context, port, ip_dict)

  Factory method is currently not called for SLAAC allocations, so third
  party ipam driver can not deliver custom AddressRequest for this kind
  of allocations.

  [1] 
https://github.com/openstack/neutron/blob/2a305c563073a3066aac3f07aab3c895ec2cd2fb/neutron/db/ipam_pluggable_backend.py#L372
  [2] 
https://github.com/openstack/neutron/blob/2a305c563073a3066aac3f07aab3c895ec2cd2fb/neutron/db/ipam_pluggable_backend.py#L80

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1570465/+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 1620746] Re: Dead code and model remain for availability ranges

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

commit 774792681de922c4f1c4788894da8c10da47f67c
Author: Carl Baldwin 
Date:   Mon Aug 1 15:04:23 2016 -0600

Remove availability range code and model

These models are effectively obsolete [1] and should've been removed
in a previous patch [2] but some of it was left behind.

[1] https://review.openstack.org/#/c/292207
[2] https://review.openstack.org/#/c/303638

Change-Id: Ib381c24f37e787b4912e28d98ec77473c0448c2b
Related-Bug: #1543094
Closes-Bug: #1620746


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

Title:
  Dead code and model remain for availability ranges

Status in neutron:
  Fix Released

Bug description:
  Availability range models and code are effectively obsolete [1] and should've 
been removed
  in a previous patch [2] but some of it was left behind.

  [1] https://review.openstack.org/#/c/292207
  [2] https://review.openstack.org/#/c/303638

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1620746/+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 1623199] Re: nova.virt.block_device: Driver failed to attach volume (RBD backed Cinder)

I'd suggest looking at how the devstack-plugin-ceph repo configures ceph
and the openstack services:

https://github.com/openstack/devstack-plugin-ceph

But I'm going to close this as invalid since it's a support request, not
a bug per se, since we have ceph CI jobs running on xenial without
issues.

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

Title:
  nova.virt.block_device: Driver failed to attach volume (RBD backed
  Cinder)

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Hello, I have working Mitaka deployment on Ubuntu 16.04. I am using
  Ceph RBD backed Nova Ephemeral storage, Cinder volumes, and Glance
  Images. Neutron is configured for provider network using linux bridge
  agent. Everything is working correctly, except I am unable to attach
  Cinder volume to Nova instance. I have googled several similar bugs,
  but all of them are old and give inconclusive solutions. Upon
  attempting nova volume attach, it gives a response, but logs show an
  internal error, and the attach is failed.

  
  arcuser@arccloud01:~$ nova --debug volume-attach 
fd3620de-6c48-4019-a0c6-d6bcc084f095 009579fd-52b7-46e3-8a51-c09bef28852d
  DEBUG (extension:157) found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
  DEBUG (extension:157) found extension EntryPoint.parse('v3oauth1 = 
keystoneauth1.extras.oauth1._loading:V3OAuth1')
  DEBUG (extension:157) found extension EntryPoint.parse('admin_token = 
keystoneauth1.loading._plugins.admin_token:AdminToken')
  DEBUG (extension:157) found extension EntryPoint.parse('v3oidcauthcode = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAuthorizationCode')
  DEBUG (extension:157) found extension EntryPoint.parse('v2password = 
keystoneauth1.loading._plugins.identity.v2:Password')
  DEBUG (extension:157) found extension EntryPoint.parse('v3samlpassword = 
keystoneauth1.extras._saml2._loading:Saml2Password')
  DEBUG (extension:157) found extension EntryPoint.parse('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
  DEBUG (extension:157) found extension EntryPoint.parse('v3oidcaccesstoken = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAccessToken')
  DEBUG (extension:157) found extension EntryPoint.parse('v3oidcpassword = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectPassword')
  DEBUG (extension:157) found extension EntryPoint.parse('v3kerberos = 
keystoneauth1.extras.kerberos._loading:Kerberos')
  DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token')
  DEBUG (extension:157) found extension 
EntryPoint.parse('v3oidcclientcredentials = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectClientCredentials')
  DEBUG (extension:157) found extension EntryPoint.parse('v3tokenlessauth = 
keystoneauth1.loading._plugins.identity.v3:TokenlessAuth')
  DEBUG (extension:157) found extension EntryPoint.parse('v3token = 
keystoneauth1.loading._plugins.identity.v3:Token')
  DEBUG (extension:157) found extension EntryPoint.parse('v3totp = 
keystoneauth1.loading._plugins.identity.v3:TOTP')
  DEBUG (extension:157) found extension EntryPoint.parse('password = 
keystoneauth1.loading._plugins.identity.generic:Password')
  DEBUG (extension:157) found extension EntryPoint.parse('v3fedkerb = 
keystoneauth1.extras.kerberos._loading:MappedKerberos')
  DEBUG (extension:157) found extension EntryPoint.parse('password-aodh-legacy 
= aodh.keystone_client:LegacyAodhKeystoneLoader')
  DEBUG (extension:157) found extension 
EntryPoint.parse('password-ceilometer-legacy = 
ceilometer.keystone_client:LegacyCeilometerKeystoneLoader')
  DEBUG (extension:157) found extension EntryPoint.parse('aodh-noauth = 
aodhclient.noauth:AodhNoAuthLoader')
  DEBUG (extension:157) found extension EntryPoint.parse('gnocchi-noauth = 
gnocchiclient.noauth:GnocchiNoAuthLoader')
  DEBUG (session:337) REQ: curl -g -i -X GET http://controller:35357/v3 -H 
"Accept: application/json" -H "User-Agent: novakeystoneauth1/2.12.1 python-

  requests/2.11.1 CPython/2.7.12"
  INFO (connectionpool:214) Starting new HTTP connection (1): controller
  DEBUG (connectionpool:401) "GET /v3 HTTP/1.1" 200 250
  DEBUG (session:366) RESP: [200] Date: Tue, 13 Sep 2016 21:02:10 GMT Server: 
Apache/2.4.18 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-

  request-id: req-06a57b71-c6f0-4119-99ad-c60396408a98 Content-Length: 250 
Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: 
application/json
  RESP BODY: {"version": {"status": "stable", "updated": 
"2016-04-04T00:00:00Z", "media-types": [{"base": "application/json", "type": 

  "application/vnd.openstack.identity-v3+json"}], "id": "v3.6", "links":
  [{"href": "http://controller:35357/v3/;, "rel": "self"}]}}

[Yahoo-eng-team] [Bug 1622616] Re: delete_subnet update_port appears racey with ipam

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

commit f07c07b16fb0858c45f6cef135a8d8c07a16c505
Author: Carl Baldwin 
Date:   Mon Sep 12 15:31:08 2016 -0600

Don't allocate IP on port update when existing subnet specified

If a port update specifies only a subnet_id for a fixed_ip then we
want to look at existing fixed_ips to see if that subnet_id is already
there. This avoids allocating a new IP address on the subnet and
deallocating the old one.

Without some special care, this breaks the code path for prefix
delegation. One could argue that PD needs reworking. However, as a
stop-gap measure, we still run the old code path if the address is an
EUI-64 address. This allows PD to continue to work as it was
originally written and it doesn't do any harm because allocating
EUI-64 addresses is repeatable.

This commit removes a test case from the DNS integration tests. The
test was specifically testing that DNS records we updated in the case
where a subnet id was passed to re-allocate a fixed_ip. Since the use
case no longer works, the test doesn't make sense.

Change-Id: I887cd23cf65a1df9bd1d59ab897a1ecd005a588c
Closes-Bug: #1622616


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

Title:
  delete_subnet update_port appears racey with ipam

Status in neutron:
  Fix Released

Bug description:
  failure spotted in a patch on a delete_subnet call:

  
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource 
[req-746d769c-2388-48e0-8e09-38e4190e5364 tempest-PortsTestJSON-432635984 -] 
delete failed: Exception deleting fixed_ip from port 
862b5dea-dca2-4669-b280-867175f5f351
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 526, in delete
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource return 
self._delete(request, id, **kwargs)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 87, in wrapped
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource setattr(e, 
'_RETRY_EXCEEDED', True)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 83, in wrapped
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource ectxt.value = 
e.inner_exc
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 123, in wrapped
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource 
traceback.format_exc())
  2016-09-10 01:04:43.452 13725 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220,

[Yahoo-eng-team] [Bug 1623252] Re: LBaaS gate broken by project_id in API calls

Reviewed:  https://review.openstack.org/369743
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lbaas/commit/?id=c46100fca3f677ca5f30101c7f6976d78661505b
Submitter: Jenkins
Branch:master

commit c46100fca3f677ca5f30101c7f6976d78661505b
Author: Stephen Balukoff 
Date:   Tue Sep 13 15:47:06 2016 -0700

Expect project_id in API calls

Change I8775aa8a477191ef21e7c3c6da31d098befefc3c in the Neutron code
tree recently updated API commands to include objects' project_id in
the call. This broke the neutron-lbaas gate. This commit updates the
neutron-lbaas API tests to expect the project_id as a paramenter as
appropriate.

Change-Id: Ib9661bc36372c182b814b17f94740a2a21b63874
Closes-Bug: #1623252


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

Title:
  LBaaS gate broken by project_id in API calls

Status in neutron:
  Fix Released

Bug description:
  Change I8775aa8a477191ef21e7c3c6da31d098befefc3c in the neutron code
  tree recently started adding project_id to appropriate API calls. This
  has broken several neutron-lbaas unit tests (thus breaking the n-lbaas
  gate). These unit tests need to be updated to expect this new
  parameter as appropriate.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623252/+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 1623176] Re: TypeError in neutron.cmd.checks._vf_management_support

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

commit c231bfb6c4743baaa1429487621d3bf18e4f1c6a
Author: Matt Riedemann 
Date:   Tue Sep 13 15:56:50 2016 -0400

Fix TypeError in sanity check logging format

The logger needs 'cap' in a replacement dict else you
get a TypeError when formatting.

Change-Id: I0bc9c8fe8f0f4e5fc44030fcc3217ccd1b485d51
Closes-Bug: #1623176


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

Title:
  TypeError in neutron.cmd.checks._vf_management_support

Status in neutron:
  Fix Released

Bug description:
  Seen here:

  2016-09-13 19:39:39.079596 | 2016-09-13 19:39:39.079 | {3} 
neutron.tests.functional.sanity.test_sanity.SanityTestCaseRoot.test_vf_extended_management_runs
 [0.086337s] ... ok
  2016-09-13 19:39:39.081288 | 2016-09-13 19:39:39.080 | 
  2016-09-13 19:39:39.083105 | 2016-09-13 19:39:39.082 | Captured stderr:
  2016-09-13 19:39:39.084958 | 2016-09-13 19:39:39.084 | 
  2016-09-13 19:39:39.095929 | 2016-09-13 19:39:39.088 | Traceback (most 
recent call last):
  2016-09-13 19:39:39.100121 | 2016-09-13 19:39:39.099 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 851, in emit
  2016-09-13 19:39:39.101455 | 2016-09-13 19:39:39.101 | msg = 
self.format(record)
  2016-09-13 19:39:39.103616 | 2016-09-13 19:39:39.103 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 724, in format
  2016-09-13 19:39:39.106691 | 2016-09-13 19:39:39.106 | return 
fmt.format(record)
  2016-09-13 19:39:39.110263 | 2016-09-13 19:39:39.109 |   File 
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_log/formatters.py",
 line 297, in format
  2016-09-13 19:39:39.112274 | 2016-09-13 19:39:39.111 | return 
logging.Formatter.format(self, record)
  2016-09-13 19:39:39.113743 | 2016-09-13 19:39:39.113 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 464, in format
  2016-09-13 19:39:39.115538 | 2016-09-13 19:39:39.115 | record.message 
= record.getMessage()
  2016-09-13 19:39:39.120019 | 2016-09-13 19:39:39.118 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
  2016-09-13 19:39:39.123320 | 2016-09-13 19:39:39.122 | msg = msg % 
self.args
  2016-09-13 19:39:39.125517 | 2016-09-13 19:39:39.125 | TypeError: format 
requires a mapping
  2016-09-13 19:39:39.127435 | 2016-09-13 19:39:39.127 | Logged from file 
checks.py, line 157

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623176/+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 1623183] Re: [FWaaS] project_id being returned instead of tenant_id by neutron, breaking some FWaaS unit tests

Reviewed:  https://review.openstack.org/369537
Committed: 
https://git.openstack.org/cgit/openstack/neutron-fwaas/commit/?id=1da6c2fd1af57046edf45d9c65d5885a116131e4
Submitter: Jenkins
Branch:master

commit 1da6c2fd1af57046edf45d9c65d5885a116131e4
Author: Nate Johnston 
Date:   Tue Sep 13 15:32:38 2016 +

Fix neutron-fwaas tests after project_id addition

All dicts being returned from API calls that included tenant_id now also
include project_id.  In places where the entire response dict was
constructed for construction, add project_id in addition to tenant_id.

Closes-Bug: #1623183

Change-Id: I2dda5960c6212150f0e5427678e39e5604830718


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

Title:
  [FWaaS] project_id being returned instead of tenant_id by neutron,
  breaking some FWaaS unit tests

Status in neutron:
  Fix Released

Bug description:
  With project_id now being accepted and returned systematically in
  Neutron[1], some of the FWaaS unit tests have broken.  This has broken
  the FWaaS gate.  There are a couple of reasons why they have broken:

  1. They are giving a bad tenant_id and are looking for an exception to
  be thrown with error text 'Invalid input for tenant_id', but now this
  is coming back as 'Invalid input for project_id'.

  2. In some cases dicts are being constructed to represent the expected
  response to the API call, and these include 'tenant_id'.  These are
  then compared to the response, and the response includes both
  'tenant_id' and 'project_id'.

  [1]
  
http://git.openstack.org/cgit/openstack/neutron/commit/?id=ba788da398b31d5433a91bdc72ff2695b475fa41

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623183/+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 1616066] Re: neutron error when trying to update a bgp peer

Reviewed:  https://review.openstack.org/367460
Committed: 
https://git.openstack.org/cgit/openstack/neutron-dynamic-routing/commit/?id=89ed530fecf4b41aa331c7594496d2a048f4d682
Submitter: Jenkins
Branch:master

commit 89ed530fecf4b41aa331c7594496d2a048f4d682
Author: Sreekumar S 
Date:   Thu Sep 8 20:44:42 2016 +0530

Fixes KeyError while updating bgp peer

This will fix the issue of KeyError being thrown when
'password' is not supplied while updating bgp peer.
The dict get() method is used to return None when
'password' key is not available.

Two unit tests are also added which will test the cases
1) Exception thrown if the auth type is 'none', and a
password is supplied when updating
2) When the password is not supplied

Change-Id: Ief9e88ca12b04eb08b0cc4e60f9d883f1e282ae9
Closes-Bug: #1616066


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

Title:
  neutron error when trying to update a bgp peer

Status in neutron:
  Fix Released

Bug description:
  Trying to update a bgp peer in Mitaka with midonet-plugin installed
  neutron throws an error.

  root@controller:~# neutron bgp-peer-update --name BGP-Peer22 
46b91ae4-990c-4d23-9dab-905eae0ec364; tail -f 
/var/log/neutron/neutron-server.log
  Request Failed: internal server error while processing your request.
  Neutron server returns request_ids: 
['req-4bd46532-1bd5-464c-8f3b-56321c3404fb']
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource obj = 
obj_updater(request.context, id, **kwargs)
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/oslo_log/helpers.py", line 46, in wrapper
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource return 
method(*args, **kwargs)
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/midonet/neutron/services/bgp/plugin.py", line 
183, in update_bgp_peer
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource context, 
bgp_peer_id, bgp_peer)
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/neutron/db/bgp_db.py", line 269, in 
update_bgp_peer
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource if 
((bp['password'] is not None) and
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource KeyError: 
'password'
  2016-08-23 09:33:27.040 18778 ERROR neutron.api.v2.resource
  2016-08-23 09:33:27.052 18778 INFO neutron.wsgi 
[req-4bd46532-1bd5-464c-8f3b-56321c3404fb 51a6b639fa6d4205a82c11fafb5e5033 
d3d205605c8d4d97808e6ab50a17b26a - - -] 10.99.99.20 - - [23/Aug/2016 09:33:27] 
"PUT /v2.0/bgp-peers/46b91ae4-990c-4d23-9dab-905eae0ec364.json HTTP/1.1" 500 
383 0.022151

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616066/+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 1584922] Re: Add OSprofiler support

It would be nice to document how to get a profiler report out of neutron
services that have support for this feature.

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

Title:
  Add OSprofiler support

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

Bug description:
  https://review.openstack.org/273951
  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 9a43f58f4df85adc2029c33ba000ca17b746a6eb
  Author: Dina Belova 
  Date:   Fri Jan 29 11:54:14 2016 +0300

  Add OSprofiler support
  
  * Add osprofiler wsgi middleware. This middleware is used for 2 things:
1) It checks that person who wants to trace is trusted and knows
   secret HMAC key.
2) It starts tracing in case of proper trace headers
   and adds first wsgi trace point, with info about HTTP request
  
  * Add initialization of osprofiler at start of service
Currently that includes oslo.messaging notifer instance creation
to send Ceilometer backend notifications.
  
  Neutron client change: Ic11796889075b2a0e589b70398fc4d4ed6f3ef7c
  
  Co-authored-by: Ryan Moats 
  Depends-On: I5102eb46a7a377eca31375a0d64951ba1fdd035d
  Closes-Bug: #1335640
  DocImpact Add devref and operator documentation on how to use this
  APIImpact
  Change-Id: I7fa2ad57dc5763ce72cba6945ebcadef2188e8bd

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1584922/+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 1580780] Re: Associate subnets to segments through subnet API

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

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

** Changed in: openstack-manuals
   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/1580780

Title:
  Associate subnets to segments through subnet API

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

Bug description:
  https://review.openstack.org/288774
  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 f494de47fcef7776f7d29d5ceb2cc4db96bd1efd
  Author: Carl Baldwin 
  Date:   Tue Feb 9 16:39:01 2016 -0700

  Associate subnets to segments through subnet API
  
  Change-Id: Ia1084a94ac659332c126eb9d4787b04a89a4ba90
  DocImpact: Need to add segment_id to API docs
  Partially-Implements: blueprint routed-networks

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1580780/+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 1605793] Re: Calculate MTU on every network fetch instead of on create

How do you intend to document this? Would the release note suffice
alone?

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

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

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

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

Title:
  Calculate MTU on every network fetch instead of on create

Status in neutron:
  Incomplete
Status in openstack-manuals:
  Incomplete

Bug description:
  https://review.openstack.org/336805
  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 a984f9554cdcbe93c840a1d8f5c04302e9331e79
  Author: Ihar Hrachyshka 
  Date:   Sat Jul 2 17:30:21 2016 +0200

  Calculate MTU on every network fetch instead of on create
  
  Today, existing networks may not reflect MTU configured for
  neutron-server, if they were created when neutron-server was using
  different MTU setup for its infrastructure, or when it was using bad
  default values for network MTUs (specifically, before Mitaka, all networks
  were getting MTU = 0 by default, disabling both advertisement and data
  path MTU size enforcement).
  
  This patch stops persisting MTU in the database on network create and
  instead calculate it on every network resource fetch.
  
  DocImpact Now changes to MTU configuration options immediately affect
existing network MTUs, not just new networks.
  
  UpgradeImpact Existing networks with invalid MTU persisted in database
may change their MTU values to reflect configuration.
  
  Change-Id: Iee4f5037bf10b73ba98464143b183aacb59c22f2
  Closes-Bug: #1556182

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1605793/+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 1401895] Re: Ensure a smooth upgrade path after adv svc split

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

Title:
  Ensure a smooth upgrade path after adv svc split

Status in grenade:
  Fix Released
Status in neutron:
  Fix Released

Bug description:
  check-grenade-dsvm-neutron is failing after the services split. An
  example of a traceback is [1].

  This is because no thin shims have been provided for the drivers, as
  done for plugins in [2]. Thin shims should be temporary just to
  provide a bw compat upgrade path, but they should be replaced by a
  more effective mechanism like 1) make load_drivers() use stevedore,
  and 2) add entry points for bw compatibility.

  [1] 
http://logs.openstack.org/51/140851/19/check/check-grenade-dsvm-neutron/da95f11/logs/new/screen-q-svc.txt.gz?level=TRACE
  [2] https://review.openstack.org/#/c/140515/

To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1401895/+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 1494281] Re: neutron-openvswitch-agent is crashing with "invalid literal for int() with base 10" error

** Changed in: neutron/liberty
   Status: Fix Committed => 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/1494281

Title:
  neutron-openvswitch-agent is crashing  with "invalid literal for int()
  with base 10" error

Status in neutron:
  Fix Released
Status in neutron liberty series:
  Fix Released

Bug description:
  neutron-openvswitch-agent is crashing with below error

  2015-09-10 04:39:36.675 DEBUG neutron.agent.linux.utils 
[req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None]
  Command: ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'--columns=name,other_config,tag', 'list', 'Port', u'tap8e259da4-e8']
  Exit code: 0
   from (pid=26026) execute /opt/stack/neutron/neutron/agent/linux/utils.py:157
  2015-09-10 04:39:36.675 ERROR 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None] invalid literal for int() 
with base 10: 'None' Agent terminated!
  2015-09-10 04:39:36.677 INFO oslo_rootwrap.client 
[req-a6c70c4e-aa40-44e4-bd09-493e82bfe43c None None] Stopping rootwrap daemon 
process with pid=26080
   
  I suspect commit "Implement external physical bridge mapping in linuxbridge"  
causing the breakage. [commit-id: bd734811753a99d61e30998c734e465a8d507b8f]

  When i set the branch back to b6d780a83cd9a811e8a91db77eb24bb65fa0b075
  commit , issue is not seen.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1494281/+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 1444112] Re: ML2 security groups only work with agent drivers

** Changed in: neutron/kilo
   Status: Fix Committed => 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/1444112

Title:
  ML2 security groups only work with agent drivers

Status in networking-odl:
  Fix Released
Status in networking-ovn:
  Fix Released
Status in neutron:
  Fix Released
Status in neutron kilo series:
  Fix Released

Bug description:
  The current ML2 integration with security groups makes a bunch of
  assumptions which don't work for controller based architectures like
  OpenDaylight and OVN. This bug will track the fixing of these issues.

  The main issues include the fact it assumes an agent-based approach
  and will send SG updates via RPC calls to the agents. This isn't true
  for ODL or OVN.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-odl/+bug/1444112/+subscriptions

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

[Yahoo-eng-team] [Bug 1614872] Re: delete method on auto-allocate extension returns 500

** Changed in: python-neutronclient
   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/1614872

Title:
  delete method on auto-allocate extension returns 500

Status in neutron:
  Fix Released
Status in python-neutronclient:
  Fix Released

Bug description:
  The method is not implemented correctly.

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

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

[Yahoo-eng-team] [Bug 1607724] Re: OVS Mech: Set hybrid plug based on agent config

** Also affects: openstack-manuals
   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/1607724

Title:
  OVS Mech: Set hybrid plug based on agent config

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

Bug description:
  https://review.openstack.org/327996
  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 7a969d4b0a5ae902695b3204a858305b5122c5ff
  Author: Kevin Benton 
  Date:   Fri Apr 29 18:01:51 2016 -0700

  OVS Mech: Set hybrid plug based on agent config
  
  This adjusts the logic in the OVS mechanism driver to determine
  what the ovs_hybrid_plug value should be set to in the VIF details.
  Previously it was based purely on the firewall driver configured on
  the server side. This prevented a mixed environment where some agents
  might be running a native OVS firewall driver while others are still
  based on the IPTables hybrid driver.
  
  This patch has the OVS agents report back whether they want hybrid
  plugging in their configuration dictionary sent during report_state.
  The OVS agent sets this based on an explicit attribute on the firewall
  driver requesting OVS hybrid plugging.
  
  To maintain backward compat, if an agent doesn't report this, the old
  logic of basing it off of the server-side config is applied.
  
  DocImpact: The server no longer needs to be configured with a firewall
 driver for OVS. It will read config from agent state reports.
  Closes-Bug: #1560957
  Change-Id: Ie554c2d37ce036e7b51818048153b466eee02913
  (cherry picked from commit 2f17a30ba04082889f3a703aca1884b031767942)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1607724/+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 1618762] Re: Add QoS minimum bandwidth rule for instance egress traffic

I can't see any Neutron's own documentation required, but additions to
[1] would be nice.

[1] http://docs.openstack.org/draft/networking-guide/config-qos.html

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

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

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

Title:
  Add QoS minimum bandwidth rule for instance egress traffic

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

Bug description:
  https://review.openstack.org/344145
  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 60325f4ae9ec53734d792d111cbcf24270d57417
  Author: Rodolfo Alonso Hernandez 
  Date:   Mon Jul 18 11:52:12 2016 +0100

  Add QoS minimum bandwidth rule for instance egress traffic
  
  This patch introduces the front end implementation for QoS
  minimum bandwidth rule.
  
  APIImpact: New type of parameter for QoS rule in neutron API
  DocImpact
  
  Change-Id: I6b619a96a2bfde164646c71409b671352bc6ce7d
  Partial-Bug: #1560963

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618762/+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 1618766] Re: Add new configuration test in sanity check: vf_extended_management

Documentation [1] should be refreshed to contain the latest options.

[1] http://docs.openstack.org/cli-reference/neutron-sanity-check.html

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

** Also affects: openstack-manuals
   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/1618766

Title:
  Add new configuration test in sanity check: vf_extended_management

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

Bug description:
  https://review.openstack.org/351833
  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 a2dc3c35e3d35c6a5f2099fee819e87b4fa216e9
  Author: Rodolfo Alonso Hernandez 
  Date:   Mon Jul 18 11:52:12 2016 +0100

  Add new configuration test in sanity check: vf_extended_management
  
  This test will check if 'ip link' version installed in this server
  supports extended VF management parameter 'min_tx_rate'. This
  parameter set the minimum egress rate for an interface.
  
  This test is executed when SR-IOV back-end and QoS extension
  are enabled.
  
  DocImpact
  Partial-Bug: #1560963
  
  Change-Id: Ie9334f4ad2f6b047bf56689edfa8a612364a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618766/+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 1620835] Re: Add timestamp fields for neutron ext resources

This requires user-facing documentation only.

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

Title:
  Add timestamp fields for neutron ext resources

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

Bug description:
  https://review.openstack.org/312873
  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 17b88cd4539cd5fa096115b76fd4a21036395360
  Author: ZhaoBo 
  Date:   Thu May 5 17:16:23 2016 +0800

  Add timestamp fields for neutron ext resources
  
  Propose a new extension named "timestamp_ext" to add timestamp to
  neutron ext resources like 
router/floatingip/security_group/security_group_rule.
  
  APIImpact
  DocImpact: Neutron ext resources now contain 'timestamp' fields like
 'created_at' and 'updated_at'
  Implements: blueprint add-neutron-extension-resource-timestamp
  
  Change-Id: I78b00516e31ce83376d37f57299b2229b6fb8fcf

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1620835/+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 1618769] Re: SR-IOV: add agent QoS driver to support egress minimum bandwidth

I can't see any Neutron's own documentation required, but additions to
[1] would be nice.

[1] http://docs.openstack.org/draft/networking-guide/config-qos.html

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

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

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

Title:
  SR-IOV: add agent QoS driver to support egress minimum bandwidth

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

Bug description:
  https://review.openstack.org/347302
  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 46de63c42e7c229529c0f101c9db8c84d73f6860
  Author: Rodolfo Alonso Hernandez 
  Date:   Mon Jul 18 11:52:12 2016 +0100

  SR-IOV: add agent QoS driver to support egress minimum bandwidth
  
  This patch adds SR-IOV agent driver, which uses eswitch manager, to set
  VF min_tx_rate parameter. This parameter defines the guaranteed minimum
  bandwidth for egress traffic.
  
  DocImpact
  Partial-Bug: #1560963
  
  Change-Id: Iefe5e698e99d186202d6ef170f84e93bfbba46dd

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1618769/+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 1623252] [NEW] LBaaS gate broken by project_id in API calls

2016-09-13 Thread Stephen Balukoff

Public bug reported:

Change I8775aa8a477191ef21e7c3c6da31d098befefc3c in the neutron code
tree recently started adding project_id to appropriate API calls. This
has broken several neutron-lbaas unit tests (thus breaking the n-lbaas
gate). These unit tests need to be updated to expect this new parameter
as appropriate.

** Affects: neutron
 Importance: Undecided
 Assignee: Stephen Balukoff (sbalukoff)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Stephen Balukoff (sbalukoff)

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

Title:
  LBaaS gate broken by project_id in API calls

Status in neutron:
  In Progress

Bug description:
  Change I8775aa8a477191ef21e7c3c6da31d098befefc3c in the neutron code
  tree recently started adding project_id to appropriate API calls. This
  has broken several neutron-lbaas unit tests (thus breaking the n-lbaas
  gate). These unit tests need to be updated to expect this new
  parameter as appropriate.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623252/+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 1622850] Re: The use_veth_interconnection config doesn't work fine

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

commit 951cd80c341fdc2783c8e3042a9e93becab58e36
Author: Hirofumi Ichihara 
Date:   Tue Sep 13 15:04:52 2016 +0900

Pass not IPDevice but port_name into OVSBridge's add_port()

The use_veth_interconnection config doesn't work fine because
IPDevice is passed into OVSBridge's add_port() although the method
expects port_name. This patch fixes the wrong argument.

Change-Id: I6ea3e37d857f34228c41118709b91f4407555a33
Closes-Bug: #1622850


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

Title:
  The use_veth_interconnection config doesn't work fine

Status in neutron:
  Fix Released

Bug description:
  The use_veth_interconnection config doesn't work fine because IPDevice
  is passed into OVSBridge's add_port() although the method expects
  port_name.

  * current wrong codes
  int_ofport = self.int_br.add_port(int_veth)
  phys_ofport = br.add_port(phys_veth)

  * expecting codes
  int_ofport = self.int_br.add_port(int_if_name)
  phys_ofport = br.add_port(phys_if_name)

  
  This issue doesn't happen in a case using ovs-vsctl because IPDevice has 
__str__() overridden (returns device name). However, In a case using native(ryu 
app), the issue happens.

  * log
  Timed out retrieving ofport on port phy-br-eth1.
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib Traceback (most 
recent call last):
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib   File 
"/opt/stack/neutron/neutron/agent/common/ovs_lib.py", line 286, in 
get_port_ofport
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib ofport = 
self._get_port_ofport(port_name)
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib   File 
"/opt/stack/neutron/neutron/agent/common/ovs_lib.py", line 92, in wrapped
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib return 
new_fn(*args, **kwargs)
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib   File 
"/usr/local/lib/python2.7/dist-packages/retrying.py", line 49, in wrapped_f
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib return 
Retrying(*dargs, **dkw).call(f, *args, **kw)
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib   File 
"/usr/local/lib/python2.7/dist-packages/retrying.py", line 214, in call
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib raise 
RetryError(attempt)
  2016-09-13 08:54:16.854 TRACE neutron.agent.common.ovs_lib RetryError: 
RetryError[Attempts: 16, Value: None]

  Actually I saw there is no phy-br-eth1 device in my env and then the
  interface is created after I have fixed above.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1622850/+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 1623199] [NEW] nova.virt.block_device: Driver failed to attach volume (RBD backed Cinder)

2016-09-13 Thread Shorton

Public bug reported:

Hello, I have working Mitaka deployment on Ubuntu 16.04. I am using Ceph
RBD backed Nova Ephemeral storage, Cinder volumes, and Glance Images.
Neutron is configured for provider network using linux bridge agent.
Everything is working correctly, except I am unable to attach Cinder
volume to Nova instance. I have googled several similar bugs, but all of
them are old and give inconclusive solutions. Upon attempting nova
volume attach, it gives a response, but logs show an internal error, and
the attach is failed.


arcuser@arccloud01:~$ nova --debug volume-attach 
fd3620de-6c48-4019-a0c6-d6bcc084f095 009579fd-52b7-46e3-8a51-c09bef28852d
DEBUG (extension:157) found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
DEBUG (extension:157) found extension EntryPoint.parse('v3oauth1 = 
keystoneauth1.extras.oauth1._loading:V3OAuth1')
DEBUG (extension:157) found extension EntryPoint.parse('admin_token = 
keystoneauth1.loading._plugins.admin_token:AdminToken')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcauthcode = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAuthorizationCode')
DEBUG (extension:157) found extension EntryPoint.parse('v2password = 
keystoneauth1.loading._plugins.identity.v2:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3samlpassword = 
keystoneauth1.extras._saml2._loading:Saml2Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcaccesstoken = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAccessToken')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcpassword = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectPassword')
DEBUG (extension:157) found extension EntryPoint.parse('v3kerberos = 
keystoneauth1.extras.kerberos._loading:Kerberos')
DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcclientcredentials 
= keystoneauth1.loading._plugins.identity.v3:OpenIDConnectClientCredentials')
DEBUG (extension:157) found extension EntryPoint.parse('v3tokenlessauth = 
keystoneauth1.loading._plugins.identity.v3:TokenlessAuth')
DEBUG (extension:157) found extension EntryPoint.parse('v3token = 
keystoneauth1.loading._plugins.identity.v3:Token')
DEBUG (extension:157) found extension EntryPoint.parse('v3totp = 
keystoneauth1.loading._plugins.identity.v3:TOTP')
DEBUG (extension:157) found extension EntryPoint.parse('password = 
keystoneauth1.loading._plugins.identity.generic:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3fedkerb = 
keystoneauth1.extras.kerberos._loading:MappedKerberos')
DEBUG (extension:157) found extension EntryPoint.parse('password-aodh-legacy = 
aodh.keystone_client:LegacyAodhKeystoneLoader')
DEBUG (extension:157) found extension 
EntryPoint.parse('password-ceilometer-legacy = 
ceilometer.keystone_client:LegacyCeilometerKeystoneLoader')
DEBUG (extension:157) found extension EntryPoint.parse('aodh-noauth = 
aodhclient.noauth:AodhNoAuthLoader')
DEBUG (extension:157) found extension EntryPoint.parse('gnocchi-noauth = 
gnocchiclient.noauth:GnocchiNoAuthLoader')
DEBUG (session:337) REQ: curl -g -i -X GET http://controller:35357/v3 -H 
"Accept: application/json" -H "User-Agent: novakeystoneauth1/2.12.1 python-

requests/2.11.1 CPython/2.7.12"
INFO (connectionpool:214) Starting new HTTP connection (1): controller
DEBUG (connectionpool:401) "GET /v3 HTTP/1.1" 200 250
DEBUG (session:366) RESP: [200] Date: Tue, 13 Sep 2016 21:02:10 GMT Server: 
Apache/2.4.18 (Ubuntu) Vary: X-Auth-Token X-Distribution: Ubuntu x-openstack-

request-id: req-06a57b71-c6f0-4119-99ad-c60396408a98 Content-Length: 250 
Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: 
application/json
RESP BODY: {"version": {"status": "stable", "updated": "2016-04-04T00:00:00Z", 
"media-types": [{"base": "application/json", "type": 

"application/vnd.openstack.identity-v3+json"}], "id": "v3.6", "links":
[{"href": "http://controller:35357/v3/;, "rel": "self"}]}}

DEBUG (base:165) Making authentication request to 
http://controller:35357/v3/auth/tokens
DEBUG (connectionpool:401) "POST /v3/auth/tokens HTTP/1.1" 201 8331
DEBUG (base:170) {"token": {"methods": ["password"], "roles": [{"id": 
"2911c6c7981d4572b777456c4c032236", "name": "admin"}], "expires_at": "2016-09-

15T03:02:10.883899Z", "project": {"domain": {"id":
"c91a4fc8d1244e71b274882386c74138", "name": "default"}, "id":
"47a164e5de59452987ee2fc215169e49", "name":

"admin"}, "catalog": [{"endpoints": [{"url":
"http://controller:8776/v1/47a164e5de59452987ee2fc215169e49;,
"interface": "public", "region": "RegionOne",

"region_id": "RegionOne", "id": "5a48e964052f454689322705b15e4034"},
{"url":

[Yahoo-eng-team] [Bug 1204956] Re: Read-only API for default quotas

Reviewed:  https://review.openstack.org/343616
Committed: 
https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=6f326acd260d035cb024f0c5e3ef2237277d8b37
Submitter: Jenkins
Branch:master

commit 6f326acd260d035cb024f0c5e3ef2237277d8b37
Author: Rui Chen 
Date:   Mon Jul 11 09:55:22 2016 +0800

Support fetching network project default quota

Neutron server and openstacksdk had supported to fetch
network project default quota, this patch add the CLI
support in openstackclient.

Change-Id: If0ef74c268c41a866c62156da0603a40ae4e6e31
Closes-Bug: #1204956
Depends-On: I6a4e2a146351dd1e7d652442511f1ef2c279da42


** Changed in: python-openstackclient
   Status: In Progress => Fix Released

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

Title:
  Read-only API for default quotas

Status in neutron:
  Fix Released
Status in python-neutronclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released

Bug description:
  Having a read-only API to access the default quotas, similar to `nova
  quota-defaults` would be helpful to API consumers like Horizon (see
  e.g. bug 1109140). As far as I can tell, there is no way to get to
  this information at the moment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1204956/+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 1279611] Re: urlparse is incompatible for python 3

2016-09-13 Thread Ken'ichi Ohmichi

This bug report has been solved on Tempest side since
https://review.openstack.org/#/c/176784/

** No longer affects: tempest

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

Title:
   urlparse is incompatible for python 3

Status in Astara:
  Fix Committed
Status in Ceilometer:
  Fix Released
Status in Cinder:
  Fix Released
Status in gce-api:
  In Progress
Status in Glance:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in openstack-ansible:
  Fix Committed
Status in openstack-doc-tools:
  Fix Released
Status in python-barbicanclient:
  Fix Released
Status in python-cinderclient:
  Fix Committed
Status in python-neutronclient:
  Fix Released
Status in RACK:
  Fix Committed
Status in Sahara:
  Fix Released
Status in Solar:
  Invalid
Status in storyboard:
  Fix Committed
Status in surveil:
  In Progress
Status in OpenStack Object Storage (swift):
  Fix Released
Status in swift-bench:
  Fix Committed
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in tuskar:
  Fix Released
Status in vmware-nsx:
  Fix Committed
Status in zaqar:
  Fix Released
Status in Zuul:
  Fix Committed

Bug description:
  import urlparse

  should be changed to :
  import six.moves.urllib.parse as urlparse

  for python3 compatible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/astara/+bug/1279611/+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 1596075] Re: Neutron confused about overlapping subnet creation

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

commit 12420c1585abadc741440dcd48a5540ef85357db
Author: Kevin Benton 
Date:   Wed Sep 7 18:51:58 2016 -0700

Mark quota operations as retriable

This decorates the quota system operations with
the retry decorators. This will help significantly
with the bug this marks as closed since operations
in the quota engine after commit should no longer
trigger retries of the full API operation.

The logic to find the args in the decorator had
to be adjusted to deal with functions already decorated.
This just uses the getargspec function from pecan that
deals with decorated functions.

Partial-Bug: #1612798
Closes-Bug: #1596075
Change-Id: Ib786117dcea08af75551770ea4c30d460382b829


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

Title:
  Neutron confused about overlapping subnet creation

Status in neutron:
  Fix Released

Bug description:
  If I use heat to create a set of networks, each with its own subnet,
  sometimes I will get an error from Neutron that there is an overlap.

  There is an example heat template attached. In my environment, this
  will fail about 1 or 2 times in 10.

  The heat template does:

  for X in seq 0 10
create network X
assign subnet 172.16.X.0/24 to network X

  One of the stacks will get an error on one of the subnets, indicating:

  Requested Subnet With Cidr: 172.16.7.0/24 For Network: 73f99807-0b2a-
  49d3-8d11-B7bd74d02f4d Overlaps With Another Subnet.

  This is in turn coming from _validate_subnet_cidr() in 
db/ipam_backend_mixin.py.
  What is happening is that the 'new_subnet_cidr' passed in is matching against 
itself.

  Since I have 'allow_overlapping_ips=true', it does:
  subnet_list = network.subnets

  but, in the failure case, this subnet is already there. In the 'no
  failure case' it is not yet there.

  I have 3 heat API servers, and 72 heat workers (3 servers). The api
  servers are round-robin load balanced

  I just (2016-06-24) reproduced this against the master/head from
  github (so midway between mitaka and newton).

  I'm not sure if there is some missing locking, but for sure this is a
  race condition.

  I have ipam_driver unset

  If i comment out the exception in _validate_subnet_cidr() then it
  works OK.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1596075/+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 1620248] Re: Can't rename instance right after creation (regression)

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

commit 723ee0195f11a2df819613728f12148290a100b4
Author: Sylvain Bauza 
Date:   Mon Sep 5 18:16:24 2016 +0200

Update BuildRequest if instance currently being scheduled

There are some cases where the instance is still waiting to be scheduled and
consequently there is still a BuildRequest object where we would also like 
to
update the instance attributes, like the display name.

In that case, we need to update the nested instance field from the 
BuildRequest
instead of trying to update the instance object itself, which could be 
located
in a child cell.

Change-Id: I97cd6dbae10ca1a29f646b0b25bc08edd699edca
Closes-Bug: #1620248


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

Title:
  Can't rename instance right after creation (regression)

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  environment: latest devstack
  bug come from gating job: 
http://logs.openstack.org/66/357766/4/check/gate-functional-neutron-dsvm-ec2api/bd0d68d/logs/

  
  1) instance creation was successful:
  2016-09-05 08:46:53.165 995 DEBUG novaclient.v2.client 
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019 
584db43c0b344f628f0c5ec565896f7b - - -] REQ: curl -g -i -X POST 
http://127.0.0.1:8774/v2.1/servers -H "User-Agent: python-novaclient" -H 
"Content-Type: application/json" -H "Accept: application/json" -H 
"X-OpenStack-Nova-API-Version: 2.10" -H "X-Auth-Token: 
{SHA1}265ec9d6a4e7c7aa9e817ea0e94a601153eaa6f9" -d '{"server": {"name": 
"r-arw7epu0-0", "imageRef": "3adede2d-bcc5-4aba-9cad-759ca6a03bd0", 
"availability_zone": "nova", "flavorRef": "16", "max_count": 1, "min_count": 1, 
"networks": [{"uuid": "532db1fe-13e1-44b1-8958-1ba64e250580"}]}}' 
_http_log_request 
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:206

  2016-09-05 08:46:53.613 995 DEBUG novaclient.v2.client 
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019 
584db43c0b344f628f0c5ec565896f7b - - -] RESP: [202] Content-Length: 370 
Location: 
http://127.0.0.1:8774/v2.1/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc 
Content-Type: application/json Openstack-Api-Version: compute 2.10 
X-Openstack-Nova-Api-Version: 2.10 Vary: OpenStack-API-Version, 
X-OpenStack-Nova-API-Version X-Compute-Request-Id: 
req-287852b6-b247-4466-b0c3-2a740c0361e9 Date: Mon, 05 Sep 2016 08:46:53 GMT 
Connection: keep-alive 
  RESP BODY: {"server": {"security_groups": [{"name": "default"}], 
"OS-DCF:diskConfig": "MANUAL", "id": "6229c916-7cde-4c76-b26c-a9c13c36a1fc", 
"links": [{"href": 
"http://127.0.0.1:8774/v2.1/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc;, 
"rel": "self"}, {"href": 
"http://127.0.0.1:8774/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc;, "rel": 
"bookmark"}], "adminPass": "***"}}
   _http_log_response 
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:231

  
  2) but next call to update server has failed.
  2016-09-05 08:46:53.614 995 DEBUG novaclient.v2.client 
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019 
584db43c0b344f628f0c5ec565896f7b - - -] POST call to compute for 
http://127.0.0.1:8774/v2.1/servers used request id 
req-287852b6-b247-4466-b0c3-2a740c0361e9 _log_request_id 
/usr/local/lib/python2.7/dist-packages/novaclient/client.py:85
  2016-09-05 08:46:53.619 995 DEBUG novaclient.v2.client 
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019 
584db43c0b344f628f0c5ec565896f7b - - -] REQ: curl -g -i -X PUT 
http://127.0.0.1:8774/v2.1/servers/6229c916-7cde-4c76-b26c-a9c13c36a1fc -H 
"User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: 
application/json" -H "X-OpenStack-Nova-API-Version: 2.10" -H "X-Auth-Token: 
{SHA1}265ec9d6a4e7c7aa9e817ea0e94a601153eaa6f9" -d '{"server": {"name": 
"i-aca22cdc"}}' _http_log_request 
/usr/local/lib/python2.7/dist-packages/keystoneclient/session.py:206

  2016-09-05 08:46:53.647 995 DEBUG novaclient.v2.client 
[req-6bb4aca0-6181-49da-88b7-aa417cae68ba b24eb09f471a4a23910aac1e43b31019 
584db43c0b344f628f0c5ec565896f7b - - -] RESP: [500] Openstack-Api-Version: 
compute 2.10 X-Openstack-Nova-Api-Version: 2.10 Vary: OpenStack-API-Version, 
X-OpenStack-Nova-API-Version Content-Type: application/json; charset=UTF-8 
Content-Length: 225 X-Compute-Request-Id: 
req-39cece3c-1787-4226-a661-61adbf34eec1 Date: Mon, 05 Sep 2016 08:46:53 GMT 
Connection: keep-alive 
  RESP BODY: {"computeFault": {"message": "Unexpected API Error. Please report 
this at http://bugs.launchpad.net/nova/ and attach the Nova API log if

[Yahoo-eng-team] [Bug 1623183] [NEW] [FWaaS] project_id being returned instead of tenant_id by neutron, breaking some FWaaS unit tests

2016-09-13 Thread Nate Johnston

Public bug reported:

With project_id now being accepted and returned systematically in
Neutron[1], some of the FWaaS unit tests have broken. This has broken
the FWaaS gate. There are a couple of reasons why they have broken:

1. They are giving a bad tenant_id and are looking for an exception to
be thrown with error text 'Invalid input for tenant_id', but now this is
coming back as 'Invalid input for project_id'.

2. In some cases dicts are being constructed to represent the expected
response to the API call, and these include 'tenant_id'. These are then
compared to the response, and the response includes both 'tenant_id' and
'project_id'.

[1]
http://git.openstack.org/cgit/openstack/neutron/commit/?id=ba788da398b31d5433a91bdc72ff2695b475fa41

** Affects: neutron
Importance: High
Assignee: Nate Johnston (nate-johnston)
Status: In Progress

** Tags: fwaas gate-failure

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

Title:
[FWaaS] project_id being returned instead of tenant_id by neutron,
breaking some FWaaS unit tests

Status in neutron:
In Progress

Bug description:
With project_id now being accepted and returned systematically in
Neutron[1], some of the FWaaS unit tests have broken. This has broken
the FWaaS gate. There are a couple of reasons why they have broken:

1. They are giving a bad tenant_id and are looking for an exception to
be thrown with error text 'Invalid input for tenant_id', but now this
is coming back as 'Invalid input for project_id'.

2. In some cases dicts are being constructed to represent the expected
response to the API call, and these include 'tenant_id'. These are
then compared to the response, and the response includes both
'tenant_id' and 'project_id'.

[1]

http://git.openstack.org/cgit/openstack/neutron/commit/?id=ba788da398b31d5433a91bdc72ff2695b475fa41

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623183/+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 1467589] Re: Remove Cinder V1 support

2016-09-13 Thread Ken'ichi Ohmichi

On tempest side, the v2 api is enabled on the default and QA team still
needs to verify the v1 api behaviors even if that is deprecated. So I
think this bug is already fixed on tempest side.

** Changed in: tempest
   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/1467589

Title:
  Remove Cinder V1 support

Status in Cinder:
  Won't Fix
Status in devstack:
  Fix Released
Status in grenade:
  In Progress
Status in heat:
  Confirmed
Status in OpenStack Compute (nova):
  Opinion
Status in os-client-config:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in Rally:
  Fix Released
Status in tempest:
  Fix Released

Bug description:
  Cinder created v2 support in the Grizzly release. This is to track
  progress in removing v1 support in other projects.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1467589/+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 1623176] [NEW] TypeError in neutron.cmd.checks._vf_management_support

Public bug reported:

Seen here:

2016-09-13 19:39:39.079596 | 2016-09-13 19:39:39.079 | {3} 
neutron.tests.functional.sanity.test_sanity.SanityTestCaseRoot.test_vf_extended_management_runs
 [0.086337s] ... ok
2016-09-13 19:39:39.081288 | 2016-09-13 19:39:39.080 | 
2016-09-13 19:39:39.083105 | 2016-09-13 19:39:39.082 | Captured stderr:
2016-09-13 19:39:39.084958 | 2016-09-13 19:39:39.084 | 
2016-09-13 19:39:39.095929 | 2016-09-13 19:39:39.088 | Traceback (most 
recent call last):
2016-09-13 19:39:39.100121 | 2016-09-13 19:39:39.099 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 851, in emit
2016-09-13 19:39:39.101455 | 2016-09-13 19:39:39.101 | msg = 
self.format(record)
2016-09-13 19:39:39.103616 | 2016-09-13 19:39:39.103 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 724, in format
2016-09-13 19:39:39.106691 | 2016-09-13 19:39:39.106 | return 
fmt.format(record)
2016-09-13 19:39:39.110263 | 2016-09-13 19:39:39.109 |   File 
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_log/formatters.py",
 line 297, in format
2016-09-13 19:39:39.112274 | 2016-09-13 19:39:39.111 | return 
logging.Formatter.format(self, record)
2016-09-13 19:39:39.113743 | 2016-09-13 19:39:39.113 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 464, in format
2016-09-13 19:39:39.115538 | 2016-09-13 19:39:39.115 | record.message = 
record.getMessage()
2016-09-13 19:39:39.120019 | 2016-09-13 19:39:39.118 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
2016-09-13 19:39:39.123320 | 2016-09-13 19:39:39.122 | msg = msg % 
self.args
2016-09-13 19:39:39.125517 | 2016-09-13 19:39:39.125 | TypeError: format 
requires a mapping
2016-09-13 19:39:39.127435 | 2016-09-13 19:39:39.127 | Logged from file 
checks.py, line 157

** Affects: neutron
 Importance: Medium
 Assignee: Matt Riedemann (mriedem)
 Status: In Progress

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

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

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

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

Title:
  TypeError in neutron.cmd.checks._vf_management_support

Status in neutron:
  In Progress

Bug description:
  Seen here:

  2016-09-13 19:39:39.079596 | 2016-09-13 19:39:39.079 | {3} 
neutron.tests.functional.sanity.test_sanity.SanityTestCaseRoot.test_vf_extended_management_runs
 [0.086337s] ... ok
  2016-09-13 19:39:39.081288 | 2016-09-13 19:39:39.080 | 
  2016-09-13 19:39:39.083105 | 2016-09-13 19:39:39.082 | Captured stderr:
  2016-09-13 19:39:39.084958 | 2016-09-13 19:39:39.084 | 
  2016-09-13 19:39:39.095929 | 2016-09-13 19:39:39.088 | Traceback (most 
recent call last):
  2016-09-13 19:39:39.100121 | 2016-09-13 19:39:39.099 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 851, in emit
  2016-09-13 19:39:39.101455 | 2016-09-13 19:39:39.101 | msg = 
self.format(record)
  2016-09-13 19:39:39.103616 | 2016-09-13 19:39:39.103 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 724, in format
  2016-09-13 19:39:39.106691 | 2016-09-13 19:39:39.106 | return 
fmt.format(record)
  2016-09-13 19:39:39.110263 | 2016-09-13 19:39:39.109 |   File 
"/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/oslo_log/formatters.py",
 line 297, in format
  2016-09-13 19:39:39.112274 | 2016-09-13 19:39:39.111 | return 
logging.Formatter.format(self, record)
  2016-09-13 19:39:39.113743 | 2016-09-13 19:39:39.113 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 464, in format
  2016-09-13 19:39:39.115538 | 2016-09-13 19:39:39.115 | record.message 
= record.getMessage()
  2016-09-13 19:39:39.120019 | 2016-09-13 19:39:39.118 |   File 
"/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
  2016-09-13 19:39:39.123320 | 2016-09-13 19:39:39.122 | msg = msg % 
self.args
  2016-09-13 19:39:39.125517 | 2016-09-13 19:39:39.125 | TypeError: format 
requires a mapping
  2016-09-13 19:39:39.127435 | 2016-09-13 19:39:39.127 | Logged from file 
checks.py, line 157

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623176/+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 1548142] Re: Created two dns-nameservers on one subnet by running two commands update "dns-nameserver" parameter in case of neutron server active-active

2016-09-13 Thread Assaf Muller

I believe this was fixed by https://review.openstack.org/#/c/303966/.

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

Title:
  Created two dns-nameservers on one subnet by running two commands
  update "dns-nameserver" parameter in case of neutron server active-
  active

Status in neutron:
  Fix Released

Bug description:
  I had three controllers, I found a bug. I can create two dns-
  nameserver on one subnet by I run two commands update dns-nameserver
  parameter AT THE SAME TIME

  How to reproduce:

  Topology: http://codepad.org/ff0debPB

  Step1: Create one subnet with dns-nameserver is 8.8.8.8

  $ neutron subnet-create --name sub-int-net --dns-nameserver 8.8.8.8
  int-net 172.16.69.0/24

  Step 2: Update dns-nameserver parameter of "sub-int-net" 
  Please running commands AT THE SAME TIME

  - On Controller1
  $ neutron subnet-update --dns-nameserver 172.1.1.10 sub-int-net

  - On Controller2
  $ neutron subnet-update --dns-nameserver 172.1.1.20 sub-int-net

  The result:

  - Before update:
  $ neutron subnet-show sub-int-net
  This is the result: http://codepad.org/QLRnNebj

  - After update
  $ neutron subnet-show sub-int-net
  This is the result: http://codepad.org/y94cKrGV
  (Please note line 7&8)

  Check in database:
  This is the result: http://codepad.org/tOoWGVs8

  In originally, When we update dns-nameserver parameter, the system will 
remove the existing dns-nameserver and write a new dns-nameserver, which have 
value in command update 
  That mean: after update this subnet has only one dns-nameserver.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1548142/+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 1623168] Re: keymgr Deprecation Warning requires newer oslo.log

2016-09-13 Thread Sean McGinnis

Additionally, looks like it should actually be
versionutils.deprecated.NEWTON in the latest code.

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

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

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

Title:
  keymgr Deprecation Warning requires newer oslo.log

Status in Cinder:
  Confirmed
Status in OpenStack Identity (keystone):
  New

Bug description:
  cinder/keymgr/__init__.py contains:

  versionutils.deprecation_warning(deprecated, versionutils.NEWTON,
   in_favor_of=castellan, logger=LOG)

  versionutils.NEWTON does not exist until oslo.log 3.4.0, but Cinder
  Newton only requires oslo.log>=1.14.0.

  It is too late in Newton to bump the global requirements for a newer
  oslo.log.   ( https://review.openstack.org/#/c/366418/ )

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1623168/+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 1615613] Re: Live migration always fails when VNC/SPICE is listening at non-local, non-catch-all address

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

** Changed in: nova
 Assignee: Paulo Matias (paulo-matias) => John Garbutt (johngarbutt)

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

Title:
  Live migration always fails when VNC/SPICE is listening at non-local,
  non-catch-all address

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When VNC or SPICE is configured to listen only at a specific IP
  address (e.g. on the management network in an OpenStack-Ansible
  deploy), the check performed by check_can_live_migrate_source always
  fails, because check_can_live_migrate_destination does not return the
  attributes needed to retrieve listen_addrs using
  libvirt_migrate.graphics_listen_addrs.

  
  Steps to reproduce:

   * Deploy OpenStack-Ansible from master.

   * Create an instance.

   * Try to live migrate the instance to another host.

  
  Expected result: live migration should be carried.

  Actual result (nova-compute.log):

  ERROR oslo_messaging.rpc.server MigrationError: Migration error: Your
  libvirt version does not support the VIR_DOMAIN_XML_MIGRATABLE flag or
  your destination node does not support retrieving listen addresses.
  In order for live migration to work properly, you must configure the
  graphics (VNC and/or SPICE) listen addresses to be either the catch-
  all address (0.0.0.0 or ::) or the local address (127.0.0.1 or ::1).

  
  Environment:

  * Multi-node OpenStack-Ansible deploy.

  * Nova from git (commit 32b7526b3cf40f40c5430034f75444fc64ac0e04).

  * Libvirt + KVM

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1615613/+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 1580728] Re: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 386: ordinal not in range(128) in nova.virt.libvirt.vif:unplug with unicode instance.display_nam

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

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

Title:
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
  386: ordinal not in range(128) in nova.virt.libvirt.vif:unplug with
  unicode instance.display_name

Status in OpenStack Compute (nova):
  Triaged
Status in oslo.versionedobjects:
  New

Bug description:
  I saw this in the n-cpu logs for a xenproject CI run:

  http://logs.openstack.xenproject.org/00/315100/1/check/dsvm-tempest-
  xen/9649dc5/logs/screen-n-cpu.txt.gz

  2016-05-11 16:19:09.457 27252 INFO nova.virt.libvirt.driver [-] [instance: 
76c4ad96-87dd-4300-acdc-cbe65d3aa0a6] Instance destroyed successfully.
  Traceback (most recent call last):
File "/usr/lib/python2.7/logging/__init__.py", line 851, in emit
  msg = self.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/handlers.py", line 
73, in format
  return logging.StreamHandler.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 724, in format
  return fmt.format(record)
File "/usr/local/lib/python2.7/dist-packages/oslo_log/formatters.py", line 
265, in format
  return logging.Formatter.format(self, record)
File "/usr/lib/python2.7/logging/__init__.py", line 464, in format
  record.message = record.getMessage()
File "/usr/lib/python2.7/logging/__init__.py", line 328, in getMessage
  msg = msg % self.args
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 386: 
ordinal not in range(128)
  Logged from file vif.py, line 966

  That would be logging the vif object in unplug:

  
https://github.com/openstack/nova/blob/15abb39ef20ae76d602d50e67e43c3500a00cd3e/nova/virt/libvirt/vif.py#L966

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1580728/+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 1226250] Re: periodic checking is needed to stabilize DB state

2016-09-13 Thread Nikhil Komawar

I have moved it to Opinion. As per the discussion on the spec
https://review.openstack.org/#/c/242682/ , we've come to an agreement
that such clean up doesn't belong in Glance.

You are welcome to open a new lite-spec with link to this bug to get
wider input.

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

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

Title:
  periodic checking is needed to stabilize DB state

Status in Glance:
  Opinion

Bug description:
  We found that glance's DB state may remain inconsistent/confusing
  without proper periodic checking, in case faults occur.

  Below are two examples:

  1. When "glance image-create" is issued with "copy-from=http://...;
  option, the image state transits from "queued" to "saving," before the
  image is copied from http backend to the glance host. If the exeuction
  is interrupted at this time, then the image will stay in "saving"
  state.

  While in such case, glance does return an error code to the external
  user who issued the command, we believe that keeping the image in the
  "saving" state may confuse other external users. It would be better to
  differentiate a failed image uploading with the case where an image is
  being uploaded. A periodic check may help in this case. Alternatively,
  one can trigger the state transition at the time when the image upload
  is believed to have failed.

  2. If the execution related to a "glance image-delete" request is
  interrupted, then it is possible that the "status" in DB table
  "glance.images" has transited to "deleted" but the "deleted" field
  remains to be False. Since this case clearly indicates the occurance
  of an error, we think it may be better to periodically check the
  existence of such inconsistent states, transit "deleted" to True
  accordingly, and mark the occurance of error probably in a dedicated
  error DB table.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1226250/+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 1622996] Re: l2pop delete_port_postcommit spam

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

commit 6e0b8c176cfc68a9e034019a0893c8c8fbf50015
Author: Kevin Benton 
Date:   Tue Sep 13 02:06:28 2016 -0700

Ensure there are fdb_entries before iterating

_get_agent_fdb may return None so we need to check for
that before we try to iterate over a key inside of it
in delete_port_postcommit.

Closes-Bug: #1622996
Change-Id: I2256df0e08380e550f32248fb9589ee43b0923ff


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

Title:
  l2pop delete_port_postcommit spam

Status in neutron:
  Fix Released

Bug description:
  Gate multinode runs filled with this:

  'l2population' failed in delete_port_postcommit
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers Traceback 
(most recent call last):
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/managers.py", line 433, in 
_call_on_drivers
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
getattr(driver.obj, method_name)(context)
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 
80, in delete_port_postcommit
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
fdb_entries[network_id]['ports'] = other_fdb_ports
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers TypeError: 
'NoneType' object has no attribute '__getitem__'
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
  2016-09-13 10:13:34.083 16443 ERROR neutron.plugins.ml2.plugin 
[req-6b8a08b6-76ae-42fd-a8fb-0c2ac4b

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1622996/+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 1623094] Re: cloud-init in xenial crashes on "null" vif type in network_data.json

2016-09-13 Thread Scott Moser

** Description changed:

- NOTE: this was originally reported in cpc-rax bug 1621968.  Re-reporting
- here for tracking purposes as requested.  Please see that issue for log
- files and more details.
+  Begin SRU Template 
+ [Impact] 
+ Instances of ubuntu launched on Rackspace public cloud would have broken 
networking and WARN messages in /var/log/cloud-init.log.
+ 
+ With this new cloud-init in place, any vms launched with a config drive
+ would not work properly.
+ 
+ [Test Case]
+ Show failure
+  * create a vm on rackspace. using image ba8782e1-ec35-4bdc-b8f7-2f28e343094a
+openstack server create --config-drive=1 --key-name=brickies --flavor=2 
--image=ba8782e1-ec35-4bdc-b8f7-2f28e343094a  my-xenial-cfgdrv
+ 
+  * ssh will fail to system. go to rackspace cloud console, view the
+ servers' console and log in as root via password provided.
+ 
+ Now, to fix:
+  * log into system on console
+  * get the proposed package:
+echo "http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main" | 
tee /etc/apt/sources.list/proposed.list
+apt-get update
+apt-get install cloud-init
+  * reboot
+ 
+ You should now be able to ssh into the system.
+ 
+ [Regression Potential] 
+ Low regression potential, as this is a fix for a regression.
+ It could potentially have fallout on other openstack cloud guests, but only 
in cases where there was already failure.
+  End SRU Template 
+ 
+ 
+ NOTE: this was originally reported in cpc-rax bug 1621968.  Re-reporting here 
for tracking purposes as requested.  Please see that issue for log files and 
more details.
  
  In recent versions of cloud-init[1], we've found that when we attach a
  configdrive to a cloud server cloud-init crashes before it has a chance
  to complete its tasks - most critically, generating the SSH keys.
  
  The root of this issue seems to be that cloud-init wants to parse the
  included network config on the configdrive.. Our network config uses a
  "null" vif type, which causes cloud-init to bomb out with an error like
  this:
  
  Sep 09 14:48:40 shtest2 cloud-init[2910]: ValueError: Unknown
  network_data link type: None
  
  [1]# dpkg -s cloud-init | grep ^Version
  Version: 0.7.7~bzr1256-0ubuntu1~16.04.1

** Changed in: cloud-init
   Status: New => Fix Released

** Changed in: cloud-init
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

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

Title:
  cloud-init in xenial crashes on "null" vif type in network_data.json

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
   Begin SRU Template 
  [Impact] 
  Instances of ubuntu launched on Rackspace public cloud would have broken 
networking and WARN messages in /var/log/cloud-init.log.

  With this new cloud-init in place, any vms launched with a config
  drive would not work properly.

  [Test Case]
  Show failure
   * create a vm on rackspace. using image ba8782e1-ec35-4bdc-b8f7-2f28e343094a
 openstack server create --config-drive=1 --key-name=brickies --flavor=2 
--image=ba8782e1-ec35-4bdc-b8f7-2f28e343094a  my-xenial-cfgdrv

   * ssh will fail to system. go to rackspace cloud console, view the
  servers' console and log in as root via password provided.

  Now, to fix:
   * log into system on console
   * get the proposed package:
 echo "http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-proposed main" | 
tee /etc/apt/sources.list/proposed.list
 apt-get update
 apt-get install cloud-init
   * reboot

  You should now be able to ssh into the system.

  [Regression Potential] 
  Low regression potential, as this is a fix for a regression.
  It could potentially have fallout on other openstack cloud guests, but only 
in cases where there was already failure.
   End SRU Template 

  
  NOTE: this was originally reported in cpc-rax bug 1621968.  Re-reporting here 
for tracking purposes as requested.  Please see that issue for log files and 
more details.

  In recent versions of cloud-init[1], we've found that when we attach a
  configdrive to a cloud server cloud-init crashes before it has a
  chance to complete its tasks - most critically, generating the SSH
  keys.

  The root of this issue seems to be that cloud-init wants to parse the
  included network config on the configdrive.. Our network config

[Yahoo-eng-team] [Bug 1623117] [NEW] Prevent keystone from serving requests when schema or data migrations are not up to date

2016-09-13 Thread Dolph Mathews

Public bug reported:

There are three scenarios during a rolling upgrade process where we
could prevent operators from doing the "wrong thing" (doing things out
of order):

1) Operators running code from the next release before `keystone-manage
db_sync --expand` has been run: If you run the next release before
--expand is run, then you'll surely end up with fatal query errors as
columns and tables won't exist that the app thinks should exist.

2) (the scary one) Operators running code from the next release before
`keystone-manage db_sync --migrate` has been run: If you run the next
release before --migrate is run, then any number of different types of
failures are possible due to unpopulated columns & tables, including a
risk of data loss as the new release tries to update records that it
perceives to be unpopulated, which might propagate to the legacy schema
during UPDATE operations, for example.

3) Operators running code from the previous release after `keystone-
manage db_sync --contract` has been run: As in case (1), this may result
in fatal query errors, but also presents a risk of introducing data
inconsistency, as the legacy schema might not have a "full
understanding" of the new schema, as would be the case with additive
schema changes. The legacy application would no longer have triggers to
rely on, so consequences would mostly be dependent on the default values
of columns, constraints, etc.

The second case worries me, as it's the most likely scenario where
operators might not realize what's going on until it's too late.

To prevent all of these scenarios, I think the application should check
at startup to ensure that the expand and data migration repositories
both match a minimum value (specifically, the most recent migration in
the application's respective repositories).

Doing the same sort of check at startup for the contract repo would be
more difficult, as it'd be entirely dependent on when you last upgraded
(whether it be last stable/* release or master at any point), so I'd
like to leave that out of scope here.

** Affects: keystone
 Importance: Medium
 Status: New


** Tags: upgrades

** Summary changed:

- Prevent keystone from serving requests when schema is not up to date
+ Prevent keystone from serving requests when schema or data migrations are not 
up to date

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

Title:
  Prevent keystone from serving requests when schema or data migrations
  are not up to date

Status in OpenStack Identity (keystone):
  New

Bug description:
  There are three scenarios during a rolling upgrade process where we
  could prevent operators from doing the "wrong thing" (doing things out
  of order):

  1) Operators running code from the next release before `keystone-
  manage db_sync --expand` has been run: If you run the next release
  before --expand is run, then you'll surely end up with fatal query
  errors as columns and tables won't exist that the app thinks should
  exist.

  2) (the scary one) Operators running code from the next release before
  `keystone-manage db_sync --migrate` has been run: If you run the next
  release before --migrate is run, then any number of different types of
  failures are possible due to unpopulated columns & tables, including a
  risk of data loss as the new release tries to update records that it
  perceives to be unpopulated, which might propagate to the legacy
  schema during UPDATE operations, for example.

  3) Operators running code from the previous release after `keystone-
  manage db_sync --contract` has been run: As in case (1), this may
  result in fatal query errors, but also presents a risk of introducing
  data inconsistency, as the legacy schema might not have a "full
  understanding" of the new schema, as would be the case with additive
  schema changes. The legacy application would no longer have triggers
  to rely on, so consequences would mostly be dependent on the default
  values of columns, constraints, etc.

  The second case worries me, as it's the most likely scenario where
  operators might not realize what's going on until it's too late.

  To prevent all of these scenarios, I think the application should
  check at startup to ensure that the expand and data migration
  repositories both match a minimum value (specifically, the most recent
  migration in the application's respective repositories).

  Doing the same sort of check at startup for the contract repo would be
  more difficult, as it'd be entirely dependent on when you last
  upgraded (whether it be last stable/* release or master at any point),
  so I'd like to leave that out of scope here.

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

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

[Yahoo-eng-team] [Bug 1623108] [NEW] Add 'newton' milestone tag to alembic branches

2016-09-13 Thread Henry Gessau

Public bug reported:

We do this for every release.

Add a tag with the name of the milestone to the heads of all the alembic
branches.

** Affects: neutron
 Importance: High
 Assignee: Henry Gessau (gessau)
 Status: New


** Tags: db

** Tags added: db

** Changed in: neutron
 Assignee: (unassigned) => Henry Gessau (gessau)

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

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

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

Title:
  Add 'newton' milestone tag to alembic branches

Status in neutron:
  New

Bug description:
  We do this for every release.

  Add a tag with the name of the milestone to the heads of all the
  alembic branches.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623108/+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 1623102] [NEW] FWaaSv2 - Error message about 'Rule association' is wrong

2016-09-13 Thread Yushiro FURUKAWA

Public bug reported:

When try to firewall_policy insert_rule or remove_rule with invalid
request, following error message is displayed:

[Error message]
{
  "NeutronError": {
"message": "Operation cannot be performed since Firewall Rule 
19230148-740b-4546-9d9a-ab0c50178369 is already associated with FirewallPolicy 
",
"type": "FirewallRuleAlreadyAssociated",
"detail": ""
  }
}

or

{
  "NeutronError": {
"message": "Firewall Rule 19230148-740b-4546-9d9a-ab0c50178369 is not 
associated  with Firewall Policy .",
"type": "FirewallRuleNotAssociatedWithPolicy",
"detail": ""
  }
}

In fact,  should be ID or name for
firewall_policy.

[How to reproduce]
$ source devstack/openrc admin admin
$ export TOKEN=`openstack token issue| grep ' id '| get_field 2`
$ curl -s -X PUT -H "content-type:application/json" -d '{"firewall_rule_id": 
"19230148-740b-4546-9d9a-ab0c50178369"}' -H "x-auth-token:$TOKEN" 
localhost:9696/v2.0/fwaas/firewall_policies/e84a79af-b16d-4e2d-a36e-ad3cff41dbd3/insert_rule

or

$ curl -s -X PUT -H "content-type:application/json" -d
'{"firewall_rule_id": "19230148-740b-4546-9d9a-ab0c50178369"}' -H "x
-auth-token:$TOKEN" localhost:9696/v2.0/fwaas/firewall_policies
/e84a79af-b16d-4e2d-a36e-ad3cff41dbd3/remove_rule

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

** Summary changed:

- FWaaSv2 - Error message in FirewallRuleAlreadyAssociated is wrong
+ FWaaSv2 - Error message about 'Rule association' is wrong

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

Title:
  FWaaSv2 - Error message about 'Rule association' is wrong

Status in neutron:
  New

Bug description:
  When try to firewall_policy insert_rule or remove_rule with invalid
  request, following error message is displayed:

  [Error message]
  {
"NeutronError": {
  "message": "Operation cannot be performed since Firewall Rule 
19230148-740b-4546-9d9a-ab0c50178369 is already associated with FirewallPolicy 
",
  "type": "FirewallRuleAlreadyAssociated",
  "detail": ""
}
  }

  or

  {
"NeutronError": {
  "message": "Firewall Rule 19230148-740b-4546-9d9a-ab0c50178369 is not 
associated  with Firewall Policy .",
  "type": "FirewallRuleNotAssociatedWithPolicy",
  "detail": ""
}
  }

  In fact,  should be ID or name for
  firewall_policy.

  [How to reproduce]
  $ source devstack/openrc admin admin
  $ export TOKEN=`openstack token issue| grep ' id '| get_field 2`
  $ curl -s -X PUT -H "content-type:application/json" -d '{"firewall_rule_id": 
"19230148-740b-4546-9d9a-ab0c50178369"}' -H "x-auth-token:$TOKEN" 
localhost:9696/v2.0/fwaas/firewall_policies/e84a79af-b16d-4e2d-a36e-ad3cff41dbd3/insert_rule

  or

  $ curl -s -X PUT -H "content-type:application/json" -d
  '{"firewall_rule_id": "19230148-740b-4546-9d9a-ab0c50178369"}' -H "x
  -auth-token:$TOKEN" localhost:9696/v2.0/fwaas/firewall_policies
  /e84a79af-b16d-4e2d-a36e-ad3cff41dbd3/remove_rule

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

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

[Yahoo-eng-team] [Bug 1623099] [NEW] 'firewall_policy_id' is missing in firewall_rule response body

2016-09-13 Thread Yushiro FURUKAWA

Public bug reported:

This is FWaaS v2.

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

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

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

** Description changed:

+ This is FWaaS v2.
+ 
  [How to reproduce]
  $ source devstack/openrc admin admin
  $ export TOKEN=`openstack token issue | grep ' id ' | get_field 2`
  $  curl -s -X GET -H "x-auth-token:$TOKEN" 
localhost:9696/v2.0/fwaas/firewall_rules/19230148-740b-4546-9d9a-ab0c50178369 | 
jq "."
  
  {
-   "firewall_rule": {
- "protocol": null,
- "description": "",
- "source_ip_address": null,
- "destination_ip_address": null,
- "source_port": null,
- "destination_port": null,
- "id": "19230148-740b-4546-9d9a-ab0c50178369",
- "name": "rule3",
- "tenant_id": "aa8dcde3d61747b48f699dca6832af62",
- "enabled": true,
- "action": "deny",
- "ip_version": 4,
- "public": false
-   }
+   "firewall_rule": {
+ "protocol": null,
+ "description": "",
+ "source_ip_address": null,
+ "destination_ip_address": null,
+ "source_port": null,
+ "destination_port": null,
+ "id": "19230148-740b-4546-9d9a-ab0c50178369",
+ "name": "rule3",
+ "tenant_id": "aa8dcde3d61747b48f699dca6832af62",
+ "enabled": true,
+ "action": "deny",
+ "ip_version": 4,
+ "public": false
+   }
  }

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

Title:
  'firewall_policy_id' is missing in firewall_rule response body

Status in neutron:
  New

Bug description:
  This is FWaaS v2.

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

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

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

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

[Yahoo-eng-team] [Bug 1623089] [NEW] Fail to suspend guest with direct-physical ports

2016-09-13 Thread Ludovic Beliveau

Public bug reported:

Description
===

Suspending a guest with direct-physical ports (PCI passthrough) is
failing and the guest is set in error.

Steps to reproduce
==

1) NETID=`neutron net-list | grep private | awk '{print $2}'`
2) PORTID=`neutron port-create $NETID --name sriov_port --binding:vnic_type 
direct-physical | grep "\ id\ " | awk '{ print $4 }'`
3) nova boot test --image=cirros-0.3.4-x86_64-uec  --nic port-id=$PORTID 
--flavor=m1.small
4) nova suspend test

Expected result
===

Instance is successfully suspended.

Actual result
=

Instance is put in error.

Stack trace:

2016-09-13 09:23:22.724 ERROR nova.compute.manager 
[req-ca82e24d-fc99-42c8-8bea-18e1c7185282 demo demo] [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] Setting instance vm_state to ERROR
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] Traceback (most recent call last):
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/opt/stack/nova/nova/compute/manager.py", line 6571, in 
_error_out_instance_on_exception
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] yield
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/opt/stack/nova/nova/compute/manager.py", line 4113, in suspend_instance
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] self.driver.suspend(context, instance)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 2435, in suspend
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] guest.save_memory_state()
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/opt/stack/nova/nova/virt/libvirt/guest.py", line 426, in save_memory_state
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] self._domain.managedSave(0)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] result = proxy_call(self._autowrap, 
f, *args, **kwargs)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] rv = execute(f, *args, **kwargs)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] six.reraise(c, e, tb)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] rv = meth(*args, **kwargs)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]   File 
"/usr/lib64/python2.7/site-packages/libvirt.py", line 1397, in managedSave
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] if ret == -1: raise libvirtError 
('virDomainManagedSave() failed', dom=self)
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1] libvirtError: Requested operation is not 
valid: domain has assigned non-USB host devices
2016-09-13 09:23:22.724 TRACE nova.compute.manager [instance: 
6b069ca8-4bb8-4781-93a7-7d58cf8122a1]

Environment
===

commit 5b207f9a1376b5edda9d4900ccadc4980d26dd1f
Merge: ba718e3 f5b7a33
Author: Jenkins 
Date:   Tue Sep 13 01:46:47 2016 +

Merge "Example & Parameter verification of os-security-group-
default-rules.inc"

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  Fail to suspend guest with direct-physical ports

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===

  Suspending a guest with direct-physical ports (PCI passthrough) is
  failing and the guest is set in error.

  Steps to reproduce

[Yahoo-eng-team] [Bug 1623094] [NEW] cloud-init in xenial crashes on "null" vif type in network_data.json

2016-09-13 Thread Shayne Hardesty

Public bug reported:

NOTE: this was originally reported in cpc-rax bug 1621968.  Re-reporting
here for tracking purposes as requested.  Please see that issue for log
files and more details.

In recent versions of cloud-init[1], we've found that when we attach a
configdrive to a cloud server cloud-init crashes before it has a chance
to complete its tasks - most critically, generating the SSH keys.

The root of this issue seems to be that cloud-init wants to parse the
included network config on the configdrive.. Our network config uses a
"null" vif type, which causes cloud-init to bomb out with an error like
this:

Sep 09 14:48:40 shtest2 cloud-init[2910]: ValueError: Unknown
network_data link type: None

[1]# dpkg -s cloud-init | grep ^Version
Version: 0.7.7~bzr1256-0ubuntu1~16.04.1

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

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

Title:
  cloud-init in xenial crashes on "null" vif type in network_data.json

Status in cloud-init:
  New

Bug description:
  NOTE: this was originally reported in cpc-rax bug 1621968.  Re-
  reporting here for tracking purposes as requested.  Please see that
  issue for log files and more details.

  In recent versions of cloud-init[1], we've found that when we attach a
  configdrive to a cloud server cloud-init crashes before it has a
  chance to complete its tasks - most critically, generating the SSH
  keys.

  The root of this issue seems to be that cloud-init wants to parse the
  included network config on the configdrive.. Our network config uses a
  "null" vif type, which causes cloud-init to bomb out with an error
  like this:

  Sep 09 14:48:40 shtest2 cloud-init[2910]: ValueError: Unknown
  network_data link type: None

  [1]# dpkg -s cloud-init | grep ^Version
  Version: 0.7.7~bzr1256-0ubuntu1~16.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1623094/+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 1619554] Re: [KVM] VM console throwing error atkbd serio0: Unknown key pressed

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

** This bug has been marked a duplicate of bug 1621257
   VNC console keeps reporting "setkeycodes 00" exception

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

Title:
  [KVM] VM console throwing error atkbd serio0: Unknown key pressed

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

Bug description:
  With master latest code console of cirros images on KVM is throwing
  error.

  root@runner:~/tools# glance image-show e63f91c4-3326-4a88-ad3a-aea819d64df9
  +--+--+
  | Property | Value|
  +--+--+
  | checksum | eb9139e4942121f22bbc2afc0400b2a4 |
  | container_format | ami  |
  | created_at   | 2016-08-31T09:29:20Z |
  | disk_format  | ami  |
  | hypervisor_type  | qemu |
  | id   | e63f91c4-3326-4a88-ad3a-aea819d64df9 |
  | kernel_id| e5f5bafd-a998-463a-9a29-03c9812ec948 |
  | min_disk | 0|
  | min_ram  | 0|
  | name | cirros-0.3.4-x86_64-uec   |
  | owner| 1b64a0ec2d8e481abc938bd44197c40c |
  | protected| False|
  | ramdisk_id   | 643e5ddb-bd94-4ddb-9656-84987a2ef917 |
  | size | 25165824 |
  | status   | active   |
  | tags | []   |
  | updated_at   | 2016-09-02T06:38:01Z |
  | virtual_size | None |
  | visibility   | public   |
  +--+--+
  root@runner:~/tools# glance image-list | grep 
e63f91c4-3326-4a88-ad3a-aea819d64df9
  | e63f91c4-3326-4a88-ad3a-aea819d64df9 | cirros-0.3.4-x86_64-uec  
  |
  root@runner:~/tools# 

  stack@controller:~/nsbu_cqe_openstack/devstack$ git log -2
  commit e6b7e7ff3f5c1b1afdae1c3f9c35754d11c0a6aa
  Author: Gary Kotton 
  Date:   Sun Aug 14 06:55:42 2016 -0700

  Enable neutron to work in a multi node setup
  
  On the controller node where devstack is being run should create
  the neutron network. The compute node should not.
  
  The the case that we want to run a multi-node neutron setup we need
  to configure the following (in the case that a plugin does not
  have any agents running on the compute node):
  ENABLED_SERVICES=n-cpu,neutron
  
  In addition to this the code did not enable decomposed plugins to
  configure their nova configurations if necessary.
  
  This patch ensure that the multi-node support works.
  
  Change-Id: I8e80edd453a1106ca666d6c531b2433be631bce4
  Closes-bug: #1613069

  commit 79722563a67d941a808b02aeccb3c6d4f1af0c41
  Merge: 434035e 4d60175
  Author: Jenkins 
  Date:   Tue Aug 30 19:52:15 2016 +

  Merge "Add support for placement API to devstack"
  stack@controller:~/nsbu_cqe_openstack/devstack$ 


  Console logs:

  
  [0.00] Initializing cgroup subsys cpuset
  [0.00] Initializing cgroup subsys cpu
  [0.00] Linux version 3.2.0-80-virtual (buildd@batsu) (gcc version 
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #116-Ubuntu SMP Mon Mar 23 17:28:52 UTC 
2015 (Ubuntu 3.2.0-80.116-virtual 3.2.68)
  [0.00] Command line: root=/dev/vda console=tty0 console=ttyS0 
no_timer_check
  [0.00] KERNEL supported cpus:
  [0.00]   Intel GenuineIntel
  [0.00]   AMD AuthenticAMD
  [0.00]   Centaur CentaurHauls
  [0.00] BIOS-provided physical RAM map:
  [0.00]  BIOS-e820:  - 0009fc00 (usable)
  [0.00]  BIOS-e820: 0009fc00 - 000a (reserved)
  [0.00]  BIOS-e820: 000f - 0010 (reserved)
  [0.00]  BIOS-e820: 0010 - 1fffe000 (usable)
  [0.00]  BIOS-e820: 1fffe000 - 2000 (reserved)
  [0.00]  BIOS-e820: fffc - 0001 (reserved)
  [0.00] NX (Execute Disable) protection: active
  [0.00] SMBIOS 2.4 present.
  [0.00] No AGP bridge found
  [0.00] last_pfn = 0x1fffe max_arch_pfn = 0x4
  [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 
0x7010600070106
  [0.00] found SMP MP-table at [880f0b00] f0b00
  [0.00] init_memory_mapping:

[Yahoo-eng-team] [Bug 1623041] Re: cisco plugin db migration fails due to unknown constraint

2016-09-13 Thread Ihar Hrachyshka

It's not neutron issue, it's cisco issue. Changed the project affected.

** Project changed: neutron => networking-cisco

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

Title:
  cisco plugin db migration fails due to unknown constraint

Status in networking-cisco:
  In Progress

Bug description:
  when using cisco networking plugin in liberty and later versions
  neutron-db-manage fails for non-innodb engines. This happens due to
  relying on autogenerated name for foreign key in cisco_router_mappings
  table. In InnoDB it is 'cisco_router_mappings_ibfk_2' - the same name
  is used in plugin upgrade() to delete this constraint. Corresponding
  file in Cisco plugin is
  
networking_cisco/db/migration/alembic_migrations/versions/liberty/contract/53f08de0523f_neutron_routers_in_cisco_devices.py

  To fix the issue the key must be explicitly named for all other
  database backends.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-cisco/+bug/1623041/+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 1622824] Re: l3 dvr code passing ip allocation objects to update_port

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

commit d223bef22449db3752d57a9eb6b4915074004e32
Author: Kevin Benton 
Date:   Mon Sep 12 18:59:30 2016 -0700

Don't work with native DB port objects in DVR code

Passing around native DB records into core plugin operations
as part of the call arguments can result in detached session
errors. It's also just bad practice since the core plugin API
is expected to take regular dictionaries containing strings.

Closes-Bug: #1622824
Change-Id: I0d33c6ac9a9ceeebbd5c1179eb41aec6c991a2bf


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

Title:
  l3 dvr code passing ip allocation objects to update_port

Status in neutron:
  Fix Released

Bug description:
  The l3 dvr code is passing IP allocation objects to update_port, which
  is not supported by the retry decorator protecting update_port. This
  results in the following exception:

  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
[req-347d1015-bdce-4e58-8179-68ff758b62f4 tempest-TestGettingAddress-1311327307 
-] add_router_interface failed: No details.
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 87, in wrapped
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource setattr(e, 
'_RETRY_EXCEEDED', True)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 83, in wrapped
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource ectxt.value = 
e.inner_exc
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 123, in wrapped
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
traceback.format_exc())
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 118, in wrapped
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource return 
f(*dup_args, **dup_kwargs)
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 221, in _handle_action
  2016-09-13 00:26:29.206 13801 ERROR neutron.api.v2.resource

[Yahoo-eng-team] [Bug 1623091] [NEW] keystonemidleware dependency should be > 4.0.0

2016-09-13 Thread Itxaka Serrano

Public bug reported:

Right now keystonemiddleware requirement is as follows:

keystonemiddleware!=4.1.0,!=4.5.0,>=4.0.0 # Apache-2.0


Unfortunately, 4.0.0 (which is the minimum) wont work due to a breaking change 
that changes the _BaseAuthProtocol class to BaseAuthProtocol[0] and that class 
is used at keystone/middleware/auth.py [1]

This was done in the change from 4.0.0 to 4.1.0 but the requirements
were never bumped. Thus using latest keystone from master and
keystonemiddleware == 4.0.0 results in failure:


2016-09-13 17:06:05.465591 Traceback (most recent call last):
2016-09-13 17:06:05.465603   File "/usr/bin/keystone-wsgi-admin", line 51, in 

2016-09-13 17:06:05.465619 application = initialize_admin_application()
2016-09-13 17:06:05.465624   File 
"/usr/lib/python2.7/site-packages/keystone/server/wsgi.py", line 132, in 
initialize_admin_application
2016-09-13 17:06:05.465632 config_files=_get_config_files())
2016-09-13 17:06:05.465636   File 
"/usr/lib/python2.7/site-packages/keystone/server/wsgi.py", line 69, in 
initialize_application
2016-09-13 17:06:05.465641 startup_application_fn=loadapp)
2016-09-13 17:06:05.465645   File 
"/usr/lib/python2.7/site-packages/keystone/server/common.py", line 50, in 
setup_backends
2016-09-13 17:06:05.465651 res = startup_application_fn()
2016-09-13 17:06:05.465654   File 
"/usr/lib/python2.7/site-packages/keystone/server/wsgi.py", line 66, in loadapp
2016-09-13 17:06:05.465659 'config:%s' % find_paste_config(), name)
2016-09-13 17:06:05.465663   File 
"/usr/lib/python2.7/site-packages/keystone/version/service.py", line 53, in 
loadapp
2016-09-13 17:06:05.465702 controllers.latest_app = deploy.loadapp(conf, 
name=name)
2016-09-13 17:06:05.465709   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 247, in 
loadapp
2016-09-13 17:06:05.465841 return loadobj(APP, uri, name=name, **kw)
2016-09-13 17:06:05.465853   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 272, in 
loadobj
2016-09-13 17:06:05.465868 return context.create()
2016-09-13 17:06:05.465876   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 710, in create
2016-09-13 17:06:05.465897 return self.object_type.invoke(self)
2016-09-13 17:06:05.465903   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 144, in invoke
2016-09-13 17:06:05.465909 **context.local_conf)
2016-09-13 17:06:05.465921   File 
"/usr/lib/python2.7/site-packages/paste/deploy/util.py", line 55, in fix_call
2016-09-13 17:06:05.465969 val = callable(*args, **kw)
2016-09-13 17:06:05.465980   File 
"/usr/lib/python2.7/site-packages/paste/urlmap.py", line 31, in urlmap_factory
2016-09-13 17:06:05.466084 app = loader.get_app(app_name, 
global_conf=global_conf)
2016-09-13 17:06:05.466101   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 350, in 
get_app
2016-09-13 17:06:05.466124 name=name, global_conf=global_conf).create()
2016-09-13 17:06:05.466138   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 362, in 
app_context
2016-09-13 17:06:05.466146 APP, name=name, global_conf=global_conf)
2016-09-13 17:06:05.466152   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 450, in 
get_context
2016-09-13 17:06:05.466171 global_additions=global_additions)
2016-09-13 17:06:05.466177   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 562, in 
_pipeline_app_context
2016-09-13 17:06:05.466192 for name in pipeline[:-1]]
2016-09-13 17:06:05.466197   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 454, in 
get_context
2016-09-13 17:06:05.466217 section)
2016-09-13 17:06:05.466243   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 476, in 
_context_from_use
2016-09-13 17:06:05.466265 object_type, name=use, global_conf=global_conf)
2016-09-13 17:06:05.466272   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 406, in 
get_context
2016-09-13 17:06:05.466289 global_conf=global_conf)
2016-09-13 17:06:05.466294   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 296, in 
loadcontext
2016-09-13 17:06:05.466320 global_conf=global_conf)
2016-09-13 17:06:05.466337   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 328, in 
_loadegg
2016-09-13 17:06:05.466344 return loader.get_context(object_type, name, 
global_conf)
2016-09-13 17:06:05.466350   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 620, in 
get_context
2016-09-13 17:06:05.466369 object_type, name=name)
2016-09-13 17:06:05.466375   File 
"/usr/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 646, in 
find_egg_entry_point
2016-09-13 17:06:05.466393 possible.append((entry.load(), protocol, 
entry.name))
2016-09-13 17:06:05.466404   File

[Yahoo-eng-team] [Bug 1612313] Re: maas datasource needs support for vendor-data

2016-09-13 Thread Scott Moser

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Changed in: cloud-init (Ubuntu)
   Importance: Undecided => Medium

** Also affects: cloud-init (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cloud-init (Ubuntu Xenial)
   Status: New => In Progress

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

Title:
  maas datasource needs support for vendor-data

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress

Bug description:
  maas datasource does not support vendor-data.
  We would like to take advantage of vendordata in maas, and thus cloud-init 
needs it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1612313/+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 1623041] [NEW] cisco plugin db migration fails due to unknown constraint

2016-09-13 Thread Vladislav Belogrudov

Public bug reported:

when using cisco networking plugin in liberty and later versions
neutron-db-manage fails for non-innodb engines. This happens due to
relying on autogenerated name for foreign key in cisco_router_mappings
table. In InnoDB it is 'cisco_router_mappings_ibfk_2' - the same name is
used in plugin upgrade() to delete this constraint. To fix the issue the
key must be explicitly named for all other database backends.

** Affects: neutron
 Importance: Undecided
 Assignee: Vladislav Belogrudov (vlad-belogrudov)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Vladislav Belogrudov (vlad-belogrudov)

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

Title:
  cisco plugin db migration fails due to unknown constraint

Status in neutron:
  New

Bug description:
  when using cisco networking plugin in liberty and later versions
  neutron-db-manage fails for non-innodb engines. This happens due to
  relying on autogenerated name for foreign key in cisco_router_mappings
  table. In InnoDB it is 'cisco_router_mappings_ibfk_2' - the same name
  is used in plugin upgrade() to delete this constraint. To fix the
  issue the key must be explicitly named for all other database
  backends.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623041/+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 1623026] [NEW] Glance api service crashes but restarts infinitely

2016-09-13 Thread Qwest

Public bug reported:

Openstack release in which defect is being reported for: Mitaka

OS: CentOS7

Component: Glance

Specific: Glance-api

# rpm -qa | grep glance
python-glanceclient-2.0.0-1.el7.noarch
python-glance-store-0.13.1-1.el7.noarch
python-glance-12.0.0-1.el7.noarch
openstack-glance-12.0.0-1.el7.noarch


Glance store settings in /etc/glance/glance-api.conf

[glance_store]
# From glance.store

stores = vmware
default_store = vmware
vmware_server_host = 10.10.1.10
vmware_server_username = administrator
vmware_server_password = admin
vmware_store_image_dir = /openstack_glance
vmware_insecure = true
vmware_datastores = DC:DS01:200
vmware_datastores = DC:DS01:100

/var/log/glance/api.log (with above settings)

2016-09-13 17:50:08.636 27351 WARNING glance_store.backend [-] Failed to load 
driver [, NoMatches("No 
'glance_store.drivers' driver found, looking for 'vsphere'",)]. The driver will 
be disabled
2016-09-13 17:52:08.779 27526 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 6d8cf.
2016-09-13 17:52:16.370 27552 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is e4c65.
2016-09-13 17:52:24.118 27566 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 41c30.
2016-09-13 17:52:31.947 27580 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 80b67.
2016-09-13 17:52:39.598 27592 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is c5356.
2016-09-13 17:52:47.107 27630 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 5d183.
2016-09-13 17:52:54.912 27644 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is d0a10.
2016-09-13 17:53:02.620 27658 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is f4f7f.
2016-09-13 17:53:10.404 27670 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 9ba5a.
2016-09-13 17:53:18.106 27708 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 46e93.
2016-09-13 17:53:25.602 27725 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 6bad2.
2016-09-13 17:53:33.135 27748 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 81b90.
2016-09-13 17:53:40.905 27760 INFO oslo_vmware.api [-] Successfully established 
new session; session ID is 04754.

Two observations from above log:

1. After changing the default_store and stores value to 'vmware' from 
'vsphere', started seeing the 'Successfully established new session' messages 
in api.log
2. Tried investigating as to why there are multiple 'new session' in api.log. 
After looking into /var/log/messages witnessed the below mentioned log:

Sep 13 18:09:06 controller01 glance-api: 
/usr/lib/python2.7/site-packages/requests/packages/urllib3/connectionpool.py:821:
 InsecureRequestWarning: Unverified HTTPS request is being made. Adding 
certificate verification is strongly advised. See: 
https://urllib3.readthedocs.org/en/latest/security.html
Sep 13 18:09:06 controller01 glance-api: InsecureRequestWarning)
Sep 13 18:09:06 controller01 glance-api: ERROR: Store for scheme vmware not 
found
Sep 13 18:09:06 controller01 systemd: openstack-glance-api.service: main 
process exited, code=exited, status=1/FAILURE
Sep 13 18:09:06 controller01 systemd: Unit openstack-glance-api.service entered 
failed state.
Sep 13 18:09:06 controller01 systemd: openstack-glance-api.service failed.
Sep 13 18:09:06 controller01 systemd: openstack-glance-api.service holdoff time 
over, scheduling restart.
Sep 13 18:09:06 controller01 systemd: Started OpenStack Image Service 
(code-named Glance) API server.
Sep 13 18:09:06 controller01 systemd: Starting OpenStack Image Service 
(code-named Glance) API server...
Sep 13 18:09:06 controller01 glance-api: 
/usr/lib/python2.7/site-packages/oslo_middleware/ssl.py:28: DeprecationWarning: 
The 'oslo_middleware.ssl' module usage is deprecated, please use 
oslo_middleware.http_proxy_to_wsgi instead

1. Remove/comment stores and retain only default_store with the value 'vmware', 
glance api service would crash instantly and stay in that state forever.
2. Retain both stores and default_store with the value 'vsphere', glance api 
service would crash instantly and stay in that state forever
3. Remove/comment stores and retain only default_store with the value 
'vsphere', glance api service would crash instantly and stay in that state 
forever
4. Retain both stores and default_store with the value 'vmware', glance api 
service would crash in about 8 seconds and restart automatically, but would 
loop between crash and restart forever, which is the reason we keep seeing, 
multiple new session established messages in api.log

Please let know if this is known issue in Mitaka or I'm having wrong
config

** Affects: glance
 Importance: Undecided
 Status: New


** Tags: glance glance-api image

-- 
You received this bug

[Yahoo-eng-team] [Bug 1622420] Re: chinese translations error in nova-log-warning.po

Like I said on the review, you should rather modify the translation like
it's described in https://wiki.openstack.org/wiki/I18nTeam

No need to submit a bug report for this, register yourself on the Zanata
tool and just go straight using it.

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

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

Title:
  chinese translations error in nova-log-warning.po

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  IN /nova/nova/locale/zh_CN/LC_MESSAGES/nova-log-warning.po, "不再"
  should be "不在" in msgstr "不再用户命名空间运行libvirt-lxc是非常危险。"

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1622420/+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 1623009] [NEW] Performance degradation of scenario "create and delete subnets"

2016-09-13 Thread Andrey Kurilin

Public bug reported:

Rally has a scenario NeutronNetworks.create_and_delete_subnets .
Logic of setUp method of scenario:
 - create network

Logic of scenario:
 - create 2 subnets in network
 - delete subnets

We configured this scenario to be launched with concurrency 10.
Yesturday, we got first failure(like [1]). Results of jenkins was posted
at Sep 12 8:08 PM (UTC +3).

Recheck did not help.
Reducing concurrency to 5 helps.

[1] - http://logs.openstack.org/24/362924/2/check/gate-rally-dsvm-
neutron-rally/39d985b/rally-
plot/results.html.gz#/NeutronNetworks.create_and_delete_subnets/overview

** Affects: neutron
 Importance: High
 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/1623009

Title:
  Performance degradation of scenario "create and delete subnets"

Status in neutron:
  New

Bug description:
  Rally has a scenario NeutronNetworks.create_and_delete_subnets .
  Logic of setUp method of scenario:
   - create network

  Logic of scenario:
   - create 2 subnets in network
   - delete subnets

  We configured this scenario to be launched with concurrency 10.
  Yesturday, we got first failure(like [1]). Results of jenkins was
  posted at Sep 12 8:08 PM (UTC +3).

  Recheck did not help.
  Reducing concurrency to 5 helps.

  [1] - http://logs.openstack.org/24/362924/2/check/gate-rally-dsvm-
  neutron-rally/39d985b/rally-
  plot/results.html.gz#/NeutronNetworks.create_and_delete_subnets/overview

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1623009/+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 1622578] Re: cloud init metadata injection failed while booting VM

So, I'm suspecting some bad configuration on the Nova side for Keystone
admin authentication from neutronclient called in the metadata API
service.

Since Nova recreates a new auth token for the metadata calls, we need to
have the right opts in nova.conf for using the keystone strategy.

Check out nova.conf on your nova-metadata-api service and look at
[keystone_authtoken] section.

Marking the bug as Invalid as I'm suspecting some configuration issue.

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

Title:
  cloud init metadata injection failed while booting VM

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Hello,

  when we start a VM the process of cloud init failed with:

  Inside the VM
  url_helper.py[WARNING]: Calling 
'http://169.254.169.254/2009-04-04/meta-data/instance-id' failed [62/120s]: bad 
status code [500]

  The VM is reachable and you can curl http://169.254.169.254 and get a
  valid result but when you curl http://169.254.169.254/latest we get:
  Remote metadata server experienced an internal server error.

  In nova-api log I see: Unauthorized: The request you have made
  requires authentication. (HTTP 401)

  
  Environment

  OS:
  Ubuntu 16.04.1 LTS

  packages on nova:
  ii  nova-api   2:13.1.0-0ubuntu1 
all  OpenStack Compute - API frontend
  ii  nova-common2:13.1.0-0ubuntu1 
all  OpenStack Compute - common files
  ii  nova-conductor 2:13.1.0-0ubuntu1 
all  OpenStack Compute - conductor service
  ii  nova-consoleauth   2:13.1.0-0ubuntu1 
all  OpenStack Compute - Console Authenticator
  ii  nova-novncproxy2:13.1.0-0ubuntu1 
all  OpenStack Compute - NoVNC proxy
  ii  nova-scheduler 2:13.1.0-0ubuntu1 
all  OpenStack Compute - virtual machine scheduler
  ii  nova-spiceproxy2:13.1.0-0ubuntu1 
all  OpenStack Compute - spice html5 proxy
  ii  python-nova2:13.1.0-0ubuntu1 
all  OpenStack Compute Python libraries
  ii  python-novaclient  2:3.3.1-2 
all  client library for OpenStack Compute API - Python 2.7
  ii  python-neutronclient   1:4.1.1-2 
all  client API library for Neutron - Python 2.7

  
  packages on neutron:

  ii  neutron-common 2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - common
  ii  neutron-dhcp-agent 2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - DHCP agent
  ii  neutron-l3-agent   2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - l3 agent
  ii  neutron-metadata-agent 2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - metadata agent
  ii  neutron-openvswitch-agent  2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - Open vSwitch plugin 
agent
  ii  neutron-plugin-ml2 2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - ML2 plugin
  ii  neutron-plugin-openvswitch-agent   2:8.1.2-0ubuntu1all
  Transitional package for neutron-openvswitch-agent
  ii  neutron-server 2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - server
  ii  python-neutron 2:8.1.2-0ubuntu1all
  Neutron is a virtual network service for Openstack - Python library
  ii  python-neutron-fwaas   1:8.0.0-0ubuntu1all
  Firewall-as-a-Service driver for OpenStack Neutron
  ii  python-neutron-lib 0.0.2-2 all
  Neutron shared routines and utilities - Python 2.7
  ii  python-neutronclient   1:4.1.1-2   all
  client API library for Neutron - Python 2.7

  Hypervisor is KVM

  ii  nova-compute-kvm 2:13.1.0-0ubuntu1   
all  OpenStack Compute - compute node (KVM)
  ii  libvirt-bin  1.3.1-1ubuntu10.1   
amd64programs for the libvirt library
  ii  libvirt0:amd64   1.3.1-1ubuntu10.1   
amd64library for interfacing with different virtualization systems
  ii

[Yahoo-eng-team] [Bug 1622974] Re: nova.api throws 500 for 'nova availability-zone-list'

2016-09-13 Thread Sean Dague

2016-09-13 15:52:14.983 TRACE nova.api.openstack.extensions IOError:
[Errno 2] No such file or directory: '/usr/local/lib/python2.7/dist-
packages/pyparsing-2.1.6.dist-info/METADATA'

This looks like a bad install that pyparsing isn't installed correctly.

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

Title:
  nova.api throws 500 for 'nova availability-zone-list'

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  $ nova availability-zone-list
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-d7fd01f2-24ae-4f95-a607-8a72ada21fee)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1622974/+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 1622996] [NEW] l2pop delete_port_postcommit spam

2016-09-13 Thread Kevin Benton

Public bug reported:

Gate multinode runs filled with this:

'l2population' failed in delete_port_postcommit
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers Traceback 
(most recent call last):
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/managers.py", line 433, in 
_call_on_drivers
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
getattr(driver.obj, method_name)(context)
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 
80, in delete_port_postcommit
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
fdb_entries[network_id]['ports'] = other_fdb_ports
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers TypeError: 
'NoneType' object has no attribute '__getitem__'
2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
2016-09-13 10:13:34.083 16443 ERROR neutron.plugins.ml2.plugin 
[req-6b8a08b6-76ae-42fd-a8fb-0c2ac4b

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

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

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

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

Title:
  l2pop delete_port_postcommit spam

Status in neutron:
  In Progress

Bug description:
  Gate multinode runs filled with this:

  'l2population' failed in delete_port_postcommit
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers Traceback 
(most recent call last):
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/managers.py", line 433, in 
_call_on_drivers
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
getattr(driver.obj, method_name)(context)
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 
80, in delete_port_postcommit
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
fdb_entries[network_id]['ports'] = other_fdb_ports
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers TypeError: 
'NoneType' object has no attribute '__getitem__'
  2016-09-13 10:13:34.066 16443 ERROR neutron.plugins.ml2.managers 
  2016-09-13 10:13:34.083 16443 ERROR neutron.plugins.ml2.plugin 
[req-6b8a08b6-76ae-42fd-a8fb-0c2ac4b

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1622996/+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 1412454] Re: node with multi-port have unexpected behavior

2016-09-13 Thread Sam Betts

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

** This bug is no longer a duplicate of bug 1405131
   Ports cannot be mapped to networks
** This bug has been marked a duplicate of bug 1544169
   [RFE] Advanced network configuration in ironic

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

Title:
  node with multi-port have unexpected behavior

Status in Ironic:
  Confirmed
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Create a node with multiple ports.
  Deployment create multiple config under pxelinux.cfg and update ports' opts 
to neutron dhcp opts. But neutron only generate opts for only one port.
  Because neutron only create one port for one instance, which only has one mac 
address.
  This is may caused by Nova.
  So we should disable multiple ports or enable neutron have multiple ports 
with one instance smoothly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic/+bug/1412454/+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 1622980] [NEW] Data Too Long for configurations column of neutron agents table

2016-09-13 Thread Esha Seth

Public bug reported:

When deploying with several networks the configurations column in table
neutron_agents can run out of space causing the below error.

09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters 
[req-817b01ad-1b7c-47bc-b3c9-81ad798a6eda - - - - -] DBAPIError exception 
wrapped from (_mysql_exceptions.DataError) (1406, "Data too long for column 
'configurations' at row 1") [SQL: u'UPDATE agents SET started_at=%s, 
heartbeat_timestamp=%s, configurations=%s WHERE agents.id = %s'] [parameters: 
(datetime.datetime(2016, 9, 6, 14, 3, 43, 663671), datetime.datetime(2016, 9, 
6, 14, 3, 43, 663671), '{"bridge_mappings": {"ETHERNET0-VLAN488": 
"9425b666-6e94-3783-ba02-0bdbd0a5175a", "ETHERNET0-VLAN489": 
"9425b666-6e94-3783-ba02-0bdbd0a5175a", ..., "ETHERNET0-VLAN533": 
"9425b666-6e94-3783-ba02-0bdbd0a5175a"}, "devices": 0}', 
'44d71991-b258-4b23-8cdb-f65e5273dbd9')]
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters Traceback 
(most recent call last):
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1139, in 
_execute_context
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters context)
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py", line 450, in 
do_execute
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters 
cursor.execute(statement, parameters)
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib64/python2.7/site-packages/MySQLdb/cursors.py", line 174, in execute
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters 
self.errorhandler(self, exc, value)
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters   File 
"/usr/lib64/python2.7/site-packages/MySQLdb/connections.py", line 36, in 
defaulterrorhandler
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters raise 
errorclass, errorvalue
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters DataError: 
(1406, "Data too long for column 'configurations' at row 1")
2016-09-06 09:03:43.791 970 ERROR oslo_db.sqlalchemy.exc_filters

2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher Traceback (most 
recent call last):
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 138, 
in _dispatch_and_reply
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher 
incoming.message))
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 183, 
in _dispatch
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher return 
self._do_dispatch(endpoint, method, ctxt, args)
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 127, 
in _do_dispatch
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 147, in wrapper
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher ectxt.value 
= e.inner_exc
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher 
self.force_reraise()
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher 
six.reraise(self.type_, self.value, self.tb)
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 137, in wrapper
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher return 
f(*args, **kwargs)
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/neutron/db/agents_db.py", line 472, in 
report_state
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher 
agent_status = self.plugin.create_or_update_agent(context, agent_state)
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/neutron/db/agents_db.py", line 386, in 
create_or_update_agent
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher return 
self._create_or_update_agent(context, agent)
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/neutron/db/agents_db.py", line 380, in 
_create_or_update_agent
2016-09-06 09:03:43.935 970 ERROR oslo_messaging.rpc.dispatcher 
greenthread.sleep(0)

[Yahoo-eng-team] [Bug 1622974] [NEW] nova.api throws 500 for 'nova availability-zone-list'

2016-09-13 Thread Ukesh

Public bug reported:

$ nova availability-zone-list
ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
 (HTTP 500) (Request-ID: 
req-d7fd01f2-24ae-4f95-a607-8a72ada21fee)

** Affects: nova
 Importance: Undecided
 Status: New

** Attachment added: "nova api log"
   https://bugs.launchpad.net/bugs/1622974/+attachment/4739943/+files/n-api.log

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

Title:
  nova.api throws 500 for 'nova availability-zone-list'

Status in OpenStack Compute (nova):
  New

Bug description:
  $ nova availability-zone-list
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-d7fd01f2-24ae-4f95-a607-8a72ada21fee)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1622974/+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 1622758] Re: Doc fix in Nova API Guide: faults.rst, insert missing word "call"

You don't need to write a bug report for that. Rather, you should just
provide a change and discuss with the API subteam about your change,
that's it.

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

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

Title:
  Doc fix in Nova API Guide: faults.rst, insert missing word "call"

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Description
  ===

  Doc fix: Insert missing word "call" on line 7 of /nova/api-
  guide/source/faults.rst. The text currently reads:

Every HTTP request has a status code. 2xx codes signify the API was
  a success.

  Suggest inserting the word "call" to improve readability:

Every HTTP request has a status code. 2xx codes signify the API call
  was a success.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1622758/+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 1622002] Re: dhcp_release6 can be called when it is not present

2016-09-13 Thread Ihar Hrachyshka

I added Ubuntu dnsmasq package to affected projects to raise visibility
around missing dependency for OpenStack Neutron in Xenial dnsmasq
package.

** Also affects: dnsmasq (Ubuntu)
   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/1622002

Title:
  dhcp_release6 can be called when it is not present

Status in neutron:
  In Progress
Status in dnsmasq package in Ubuntu:
  New

Bug description:
  If someone enables dhcpv6-stateful addressing on a subnet, but they
  are running an old version of dnsmasq (<2.76), then the dhcp agent
  could try and run dhcp_release6 even though it isn't present.  An
  example:

  http://logs.openstack.org/53/365653/5/check/gate-tempest-dsvm-neutron-
  multinode-full-ubuntu-
  xenial/813d16d/logs/screen-q-dhcp.txt.gz#_2016-09-06_11_40_02_272

  Checking it's present first would fix this problem.

  Since the change to call dhcp_release6 was just added in
  https://review.openstack.org/#/c/301747/ we should fix this before
  Newton ships and people complain.

  There is also an effort to get Cirros to support DHCPv6 so that we can test 
this in the gate,
  https://bugs.launchpad.net/cirros/+bug/1487041 - hopefully that gets done so 
we can add a functional test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1622002/+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 1622946] [NEW] lbaas with haproxy backend creates the lbaas namespace without the members' subnet

2016-09-13 Thread György Szombathelyi

Public bug reported:

When creating a new loadbalancer with haproxy, and the VIP and member
subnets are different, the created lbaas namespace contains only the VIP
subnet, so the members are unreachable.

E.g.:
neutron lbaas-loadbalancer-show 8e1c193a-ab63-4a1a-bc39-c663f2f9a0ee
.
.
.
| vip_subnet_id   | 23655977-d29f-4917-a519-de27951fde89   |

neutron lbaas-member-list d3ebda43-53f8-4118-b4db-999c021c9680

| 4fe79d5e-a517-4e4f-a145-3c80b414be08 |  | 192.168.168.8 |
22 |  1 | 0a4a1f3e-43cb-4f9c-9d51-c71f0c231a3e | True   |

Note that the two subnets are different.
The created haproxy config is OK:
.
.
.
frontend 6821edd8-54ab-4fba-90e5-94831fcd0ec0
option tcplog
bind 10.97.37.1:22
mode tcp

backend d3ebda43-53f8-4118-b4db-999c021c9680
mode tcp
balance source
timeout check 20
server 4fe79d5e-a517-4e4f-a145-3c80b414be08 192.168.168.8:22 weight 1 check 
inter 10s fall 3

But the namespace is not:
ip netns exec qlbaas-8e1c193a-ab63-4a1a-bc39-c663f2f9a0ee ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: ns-f56b5f8d-ef@if11:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
link/ether fa:16:3e:82:9d:9a brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.97.37.1/25 brd 10.97.37.127 scope global ns-f56b5f8d-ef
   valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe82:9d9a/64 scope link 
   valid_lft forever preferred_lft forever


The member subnet is missing.

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  lbaas with haproxy backend creates the lbaas namespace without the
  members' subnet

Status in neutron:
  New

Bug description:
  When creating a new loadbalancer with haproxy, and the VIP and member
  subnets are different, the created lbaas namespace contains only the
  VIP subnet, so the members are unreachable.

  E.g.:
  neutron lbaas-loadbalancer-show 8e1c193a-ab63-4a1a-bc39-c663f2f9a0ee
  .
  .
  .
  | vip_subnet_id   | 23655977-d29f-4917-a519-de27951fde89   |

  neutron lbaas-member-list d3ebda43-53f8-4118-b4db-999c021c9680

  | 4fe79d5e-a517-4e4f-a145-3c80b414be08 |  | 192.168.168.8 |
  22 |  1 | 0a4a1f3e-43cb-4f9c-9d51-c71f0c231a3e | True   |

  Note that the two subnets are different.
  The created haproxy config is OK:
  .
  .
  .
  frontend 6821edd8-54ab-4fba-90e5-94831fcd0ec0
  option tcplog
  bind 10.97.37.1:22
  mode tcp

  backend d3ebda43-53f8-4118-b4db-999c021c9680
  mode tcp
  balance source
  timeout check 20
  server 4fe79d5e-a517-4e4f-a145-3c80b414be08 192.168.168.8:22 weight 1 
check inter 10s fall 3

  But the namespace is not:
  ip netns exec qlbaas-8e1c193a-ab63-4a1a-bc39-c663f2f9a0ee ip addr
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
  2: ns-f56b5f8d-ef@if11:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether fa:16:3e:82:9d:9a brd ff:ff:ff:ff:ff:ff link-netnsid 0
  inet 10.97.37.1/25 brd 10.97.37.127 scope global ns-f56b5f8d-ef
 valid_lft forever preferred_lft forever
  inet6 fe80::f816:3eff:fe82:9d9a/64 scope link 
 valid_lft forever preferred_lft forever

  
  The member subnet is missing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1622946/+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 1622938] [NEW] generating duplicate LLA iptables rules

2016-09-13 Thread Kevin Benton

Public bug reported:

Spotted in gate. Looks like we are generating duplicate iptables rules
for LLA v6 entries.

2016-09-13 08:10:15.769 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:41.844 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sd39667db-b -s fe80::f816:3eff:fe30:7756/128 -m mac 
--mac-source FA:16:3E:30:77:56 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:41.844 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:55.708 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sd39667db-b -s fe80::f816:3eff:fe30:7756/128 -m mac 
--mac-source FA:16:3E:30:77:56 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:55.708 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:55.798 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sd39667db-b -s fe80::f816:3eff:fe30:7756/128 -m mac 
--mac-source FA:16:3E:30:77:56 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:55.798 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:59.713 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sd39667db-b -s fe80::f816:3eff:fe30:7756/128 -m mac 
--mac-source FA:16:3E:30:77:56 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:10:59.713 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:11:03.825 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sd39667db-b -s fe80::f816:3eff:fe30:7756/128 -m mac 
--mac-source FA:16:3E:30:77:56 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:11:03.825 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic from defined 
IP/MAC pairs." -j RETURN
2016-09-13 08:11:09.679 13401 WARNING neutron.agent.linux.iptables_manager 
[req-4534b4a3-484e-4fc5-8b44-0e91d70feb88 - -] Duplicate iptables rule 
detected. This may indicate a bug in the the iptables rule generation code. 
Line: -A neutron-linuxbri-sa16bbb04-2 -s fe80::f816:3eff:fecd:f5b1/128 -m mac 
--mac-source FA:16:3E:CD:F5:B1 -m comment --comment "Allow traffic

[Yahoo-eng-team] [Bug 1622917] [NEW] Failed to update router to ha mode when overlapping is disabled

2016-09-13 Thread Jacolex

Public bug reported:

I tried to move users routers from non-ha to ha mode. I made neutron
router-update  $rid  --ha true; It works but only few times. When I try
to do it on fourth of fifth router - it fails with error:

Invalid input for operation: Requested subnet with cidr:
169.254.192.0/18 for network: 313e3e5e-79a8-42cd-bdf3-5d385682197a
overlaps with another subnet.

Unfortunately I did it in a loop with all routers, so all of remaining
non-ha routers became unusable. Network node with l3 agent was unable to
create virtual router giving error:

2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task   File 
"/usr/lib/python2.7/dist-packages/neutron/scheduler/l3_agent_scheduler.py", 
line 293, in create_ha_port_and_bind
2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task 
ha_network.network.id, tenant_id)
2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task
2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task AttributeError: 
'NoneType' object has no attribute 'network'

Trying to reverse operation "neutron router-update  $rid --ha false"
also fails (with the same error in neutron log), so after spending few
hours on diagnose the problem I found source of the problem and
solution. I had to manualy change ha mode in database
(router_extra_attributes  table) and routers became stable and working.
The problem is that allow_overlapping_ips = False prevents neutron from
creating HA network tenants which are using the same subnets
169.254.x.0/18.

My Openstack version is Liberty. So if there is no solution yet, let me propose 
two solutions:
- allow to create ha networks regardless of allow_overlapping_ips setting (but 
I think it can be hard to develop such exception)
- not to change ha mode of the router if ha network creating failed (the 
procedure create_ha_port_and_bind needs additonal exception).

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: l3-ha neutron

** Description changed:

  I tried to move users routers from non-ha to ha mode. I made neutron
  router-update  $rid  --ha true; It works but only few times. When I try
  to do it on fourth of fifth router - it fails with error:
  
  Invalid input for operation: Requested subnet with cidr:
  169.254.192.0/18 for network: 313e3e5e-79a8-42cd-bdf3-5d385682197a
  overlaps with another subnet.
  
  Unfortunately I did it in a loop with all routers, so all of remaining
  non-ha routers became unusable. Network node with l3 agent was unable to
  create virtual router giving error:
  
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task   File 
"/usr/lib/python2.7/dist-packages/neutron/scheduler/l3_agent_scheduler.py", 
line 293, in create_ha_port_and_bind
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task 
ha_network.network.id, tenant_id)
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task AttributeError: 
'NoneType' object has no attribute 'network'
  
- Trying to reverse operation "neutron router-update  $rid --ha true" also
- fails, so after spending few hours on diagnose the problem I found
+ Trying to reverse operation "neutron router-update  $rid --ha false"
+ also fails, so after spending few hours on diagnose the problem I found
  source of the problem and solution. I had to manualy change ha mode in
  database (router_extra_attributes  table) and routers became stable and
  working. The problem is that allow_overlapping_ips = False prevents
  neutron from creating HA network tenants which are using the same
- subnets 169.254.192.0/18.
+ subnets 169.254.x.0/18.
  
  My Openstack version is Liberty. So if there is no solution yet, let me 
propose two solutions:
  - allow to create ha networks regardless of allow_overlapping_ips setting 
(but I think it can be hard to develop such exception)
  - not to change ha mode of the router if ha network creating failed (the 
procedure create_ha_port_and_bind needs additonal exception).

** Description changed:

  I tried to move users routers from non-ha to ha mode. I made neutron
  router-update  $rid  --ha true; It works but only few times. When I try
  to do it on fourth of fifth router - it fails with error:
  
  Invalid input for operation: Requested subnet with cidr:
  169.254.192.0/18 for network: 313e3e5e-79a8-42cd-bdf3-5d385682197a
  overlaps with another subnet.
  
  Unfortunately I did it in a loop with all routers, so all of remaining
  non-ha routers became unusable. Network node with l3 agent was unable to
  create virtual router giving error:
  
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task   File 
"/usr/lib/python2.7/dist-packages/neutron/scheduler/l3_agent_scheduler.py", 
line 293, in create_ha_port_and_bind
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task 
ha_network.network.id, tenant_id)
  2016-09-12 19:18:35.827 9357 ERROR oslo_service.periodic_task
  2016-09-12 19:18:35.827

[Yahoo-eng-team] [Bug 1622914] [NEW] agent traces about bridge-nf-call sysctl values missing

2016-09-13 Thread Kevin Benton

Public bug reported:

spotted in gate:

2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent Traceback (most recent call 
last):
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/agent/_common_agent.py", 
line 450, in daemon_loop
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent sync = 
self.process_network_devices(device_info)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/usr/local/lib/python2.7/dist-packages/osprofiler/profiler.py", line 154, in 
wrapper
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent return f(*args, **kwargs)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/agent/_common_agent.py", 
line 200, in process_network_devices
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent device_info.get('updated'))
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/securitygroups_rpc.py", line 265, in 
setup_port_filters
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent 
self.prepare_devices_filter(new_devices)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/securitygroups_rpc.py", line 130, in 
decorated_function
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent *args, **kwargs)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/securitygroups_rpc.py", line 138, in 
prepare_devices_filter
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent 
self._apply_port_filter(device_ids)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/securitygroups_rpc.py", line 163, in 
_apply_port_filter
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent 
self.firewall.prepare_port_filter(device)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/iptables_firewall.py", line 170, in 
prepare_port_filter
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent 
self._enable_netfilter_for_bridges()
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/iptables_firewall.py", line 114, in 
_enable_netfilter_for_bridges
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent run_as_root=True)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 138, in execute
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent raise RuntimeError(msg)
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent RuntimeError: Exit code: 255; 
Stdin: ; Stdout: ; Stderr: sysctl: cannot stat 
/proc/sys/net/bridge/bridge-nf-call-arptables: No such file or directory
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent 
2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent

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

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

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

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

Title:
  agent traces about bridge-nf-call sysctl values missing

Status in neutron:
  In Progress

Bug description:
  spotted in gate:

  2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent Traceback (most recent call 
last):
  2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/agent/_common_agent.py", 
line 450, in daemon_loop
  2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent sync = 
self.process_network_devices(device_info)
  2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent   File 
"/usr/local/lib/python2.7/dist-packages/osprofiler/profiler.py", line 154, in 
wrapper
  2016-09-13 07:37:33.437 13401 ERROR 
neutron.plugins.ml2.drivers.agent._common_agent return

[Yahoo-eng-team] [Bug 1622905] [NEW] test_dualnet_multi_prefix_dhcpv6_stateless fails with 'DetachedInstanceError: Instance is not bound to a Session; attribute refresh operation

2016-09-13 Thread Ihar Hrachyshka

Public bug reported:

http://logs.openstack.org/68/367268/4/gate/gate-tempest-dsvm-neutron-
dvr-ubuntu-xenial/da4739d/console.html

2016-09-13 02:23:34.790198 | 
tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_dhcpv6_stateless[compute,id-cf1c4425-766b-45b8-be35-e2959728eb00,network]
2016-09-13 02:23:34.790254 | 
---
2016-09-13 02:23:34.790263 | 
2016-09-13 02:23:34.790273 | Captured traceback:
2016-09-13 02:23:34.790284 | ~~~
2016-09-13 02:23:34.790297 | Traceback (most recent call last):
2016-09-13 02:23:34.790313 |   File "tempest/test.py", line 107, in wrapper
2016-09-13 02:23:34.790329 | return f(self, *func_args, **func_kwargs)
2016-09-13 02:23:34.790357 |   File "tempest/scenario/test_network_v6.py", 
line 256, in test_dualnet_multi_prefix_dhcpv6_stateless
2016-09-13 02:23:34.790368 | dualnet=True)
2016-09-13 02:23:34.790390 |   File "tempest/scenario/test_network_v6.py", 
line 163, in _prepare_and_test
2016-09-13 02:23:34.790402 | dualnet=dualnet)
2016-09-13 02:23:34.790424 |   File "tempest/scenario/test_network_v6.py", 
line 104, in prepare_network
2016-09-13 02:23:34.790436 | subnet_id=sub6['id'])
2016-09-13 02:23:34.790461 |   File 
"tempest/lib/services/network/routers_client.py", line 69, in 
add_router_interface
2016-09-13 02:23:34.790481 | return self.update_resource(uri, kwargs)
2016-09-13 02:23:34.790504 |   File "tempest/lib/services/network/base.py", 
line 74, in update_resource
2016-09-13 02:23:34.790520 | resp, body = self.put(req_uri, 
req_post_data)
2016-09-13 02:23:34.790539 |   File "tempest/lib/common/rest_client.py", 
line 340, in put
2016-09-13 02:23:34.790561 | return self.request('PUT', url, 
extra_headers, headers, body, chunked)
2016-09-13 02:23:34.790581 |   File "tempest/lib/common/rest_client.py", 
line 665, in request
2016-09-13 02:23:34.790591 | resp, resp_body)
2016-09-13 02:23:34.790613 |   File "tempest/lib/common/rest_client.py", 
line 829, in _error_checker
2016-09-13 02:23:34.790623 | message=message)
2016-09-13 02:23:34.790640 | tempest.lib.exceptions.ServerFault: Got server 
fault
2016-09-13 02:23:34.790663 | Details: Request Failed: internal server error 
while processing your request.

In the neutron-server log:

2016-09-13 01:58:24.208 13912 ERROR neutron.plugins.ml2.rpc 
[req-1ab511fe-43a8-4491-b3d1-a33fd6c797ac - -] Failed to update device 
55c41e91-6cf3-4059-8653-3d9727f29674 up
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers 
[req-89f26fae-d652-40e8-ba21-43bc4758ace8 admin -] Mechanism driver 
'l2population' failed in delete_port_postcommit
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers Traceback 
(most recent call last):
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/managers.py", line 433, in 
_call_on_drivers
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers 
getattr(driver.obj, method_name)(context)
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers   File 
"/opt/stack/new/neutron/neutron/plugins/ml2/drivers/l2pop/mech_driver.py", line 
80, in delete_port_postcommit
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers 
fdb_entries[network_id]['ports'] = other_fdb_ports
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers TypeError: 
'NoneType' object has no attribute '__getitem__'
2016-09-13 02:04:16.827 13911 ERROR neutron.plugins.ml2.managers 
2016-09-13 02:04:16.835 13911 ERROR neutron.plugins.ml2.plugin 
[req-89f26fae-d652-40e8-ba21-43bc4758ace8 admin -] 
mechanism_manager.delete_port_postcommit failed for port 
cd4447f6-83d3-44ff-b678-7936272d4368
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource 
[req-7eb6c757-6de0-4f5e-b062-6ccee17e8887 tempest-TestGettingAddress-6985564 -] 
add_router_interface failed: No details.
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource   File 
"/opt/stack/new/neutron/neutron/db/api.py", line 87, in wrapped
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource setattr(e, 
'_RETRY_EXCEEDED', True)
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2016-09-13 02:11:23.858 13910 ERROR neutron.api.v2.resource 
self.force_reraise()
2016-09-13 02:11:23.858 13910 ERROR

[Yahoo-eng-team] [Bug 1298061] Re: nova should allow evacuate for an instance in the Error state

2016-09-13 Thread James Page

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

** Changed in: nova (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: nova (Ubuntu)
   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/1298061

Title:
  nova should allow evacuate for an instance in the Error state

Status in OpenStack Compute (nova):
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Trusty:
  In Progress

Bug description:
  [Impact]

   * Instances in error state cannot be evacuated.

  [Test Case]

   * nova evacuate  
   * nova refuses to evacuate the instance because of its state

  [Regression Potential]

   * None


  We currently allow reboot/rebuild/rescue for an instance in the Error
  state if the instance has successfully booted at least once.

  We should allow "evacuate" as well, since it is essentially a
  "rebuild" on a different compute node.

  This would be useful in a number of cases, in particular if an initial
  evacuation attempt fails (putting the instance into the Error state).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298061/+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 1576692] Re: fully support package installation in systemd

2016-09-13 Thread Launchpad Bug Tracker

This bug was fixed in the package init-system-helpers - 1.44

---
init-system-helpers (1.44) unstable; urgency=medium

  * invoke-rc.d, service: Check for multi-user.target instead of 
graphical.target.
There is a curious bug which sometimes causes "systemctl is-active
default.target" to say inactive until "show" or "status" gets called on
the unit. This needs to be investigated.  Until then, check for
multi-user.target which by and large does the same job, but seems to work
reliably.

 -- Martin Pitt   Mon, 12 Sep 2016 22:52:23
+0200

** Changed in: init-system-helpers (Ubuntu)
   Status: Fix Committed => Fix Released

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

Title:
  fully support package installation in systemd

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in init-system-helpers package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  In Progress
Status in init-system-helpers source package in Xenial:
  In Progress

Bug description:
  in cloud-init users can install packages via cloud-config:
  #cloud-config
  packages: [apache2]

  Due to some intricacies of systemd and service installation that doesn't work 
all that well.
  We fixed the issue for simple services that do not have any dependencies on 
other services, or at least don't check those dependencies well under bug 
1575572.

  We'd like to have a way to fully support this in cloud-init.

  Related bugs:
   * bug 1575572:  apache2 fails to start if installed via cloud config (on 
Xenial)
   * bug 1611973: postgresql@9.5-main service not started if postgres installed 
via cloud-init
   * bug 1621336: snapd.boot-ok.service hangs eternally on cloud image upgrades 
(snapd packaging bug, but this cloud-init fix will workaround it)
   * bug 1620780: dev-sda2.device job running and times out

  SRU INFORMATION
  ===
  FIX for init-system-helpers: 
https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=1460d6a02

  REGRESSION POTENTIAL for init-system-helpers: This changes invoke-rc.d
  and service, two very central pieces of packaging infrastructure.
  Errors in it will break installation/upgrades of packages or
  /etc/network/if-up.d/ hooks and the like. This changes the condition
  when systemd units get started without their dependencies, and the
  condition gets weakened. This means that behaviour in a booted system
  is unchanged, but during boot this could change the behaviour of if-
  up.d/ hooks (although they have never been defined well during boot
  anyway). However, I tested this change extensively in cloud images and
  desktop installations (particularly I recreated
  https://bugs.debian.org/777113 and confirmed that this approach also
  fixes it) and could not find any regression.

  TEST CASE (for both packages):
  Run
 lxc launch ubuntu-daily:x --config=user.user-data="$(printf 
"#cloud-config\npackages: [postgresql, samba, postfix]")" x1

  This will install all three packages, but "systemctl status
  postgresql@9.5-main" will not be running.

  Now prepare a new image with the proposed cloud-init and init-system-
  helpers:

 lxc launch ubuntu-daily:x xprep
 lxc exec xprep bash
 # enable -proposed and dist-upgrade, then poweroff
 lxc publish xprep x-proposed

  Now run the initial lxc launch again, but against that new x-proposed
  image instead of the standard daily:

lxc launch x-proposed --config=user.user-data="$(printf "#cloud-
  config\npackages: [postgresql, samba, postfix]")" x1

  You should now have "systemctl status postgresql@9.5-main" running.
  Directly after rebooting the instance, check that there are no hanging
  jobs (systemctl list-jobs), particularly networking.service, to ensure
  that https://bugs.debian.org/777113 did not come back.

  Also test interactively installing a package that ships a service,
  like "apache2", and verify that it starts properly after installation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1576692/+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 1298061] Re: nova should allow evacuate for an instance in the Error state

2016-09-13 Thread Louis Bouchard

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

** Also affects: nova (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

Title:
  nova should allow evacuate for an instance in the Error state

Status in OpenStack Compute (nova):
  Fix Released
Status in nova package in Ubuntu:
  New
Status in nova source package in Trusty:
  In Progress

Bug description:
  [Impact]

   * Instances in error state cannot be evacuated.

  [Test Case]

   * nova evacuate  
   * nova refuses to evacuate the instance because of its state

  [Regression Potential]

   * None


  We currently allow reboot/rebuild/rescue for an instance in the Error
  state if the instance has successfully booted at least once.

  We should allow "evacuate" as well, since it is essentially a
  "rebuild" on a different compute node.

  This would be useful in a number of cases, in particular if an initial
  evacuation attempt fails (putting the instance into the Error state).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1298061/+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 1622854] [NEW] pci: double pci migration is putting vm in ERROR

2016-09-13 Thread Moshe Levi

Public bug reported:

nova master
devstack multinode with 2 compute nodes
1. booting vm with direct port
2. nova migrate 128a2ba4-fb6e-49f4-a6e0-45cde1c60215
3. nova resize-confirm 128a2ba4-fb6e-49f4-a6e0-45cde1c60215
4. nova migrate 128a2ba4-fb6e-49f4-a6e0-45cde1c60215
5. nova resize-confirm 128a2ba4-fb6e-49f4-a6e0-45cde1c60215

The second migration failed with this error:

2016-09-12 13:12:45.750 8388 DEBUG oslo_concurrency.lockutils 
[req-a4a0126a-215a-489a-b043-ad38d3b5e28d - -] Lock "compute_resources" 
released by "nova.compute.resource_tracker._update_available_resource" :: held 
0.143s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
[req-a4a0126a-215a-489a-b043-ad38d3b5e28d - -] Error updating resources for 
node r-dcs224.mtr.labs.mlnx.
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager Traceback (most recent 
call last):
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/compute/manager.py", line 
6408, in update_available_resource_for_node
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
rt.update_available_resource(context)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/compute/resource_tracker.py",
 line 526, in update_available_resource
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
self._update_available_resource(context, resources)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py", line 271, in 
inner
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager return f(*args, 
**kwargs)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/compute/resource_tracker.py",
 line 580, in _update_available_resource
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
self.pci_tracker.clean_usage(instances, migrations, orphans)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/pci/manager.py", line 326, 
in clean_usage
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
self._free_device(dev)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/pci/manager.py", line 270, 
in _free_device
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager freed_devs = 
dev.free(instance)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/objects/pci_device.py", 
line 397, in free
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
hopestatus=ok_statuses)
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager PciDeviceInvalidStatus: 
PCI device 3::03:00.5 is available instead of ('allocated', 'claimed')
2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager
2016-09-12 13:12:46.220 8388 DEBUG oslo_service.periodic_task 
[req-a4a0126a-215a-489a-b043-ad38d3b5e28d - -] Running periodic task 
ComputeManager._sync_scheduler_instance_info run_periodic_tasks 
/usr/lib/python2.7/site-packages/oslo_service/periodic_task.py:215

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  pci: double pci migration is putting vm in ERROR

Status in OpenStack Compute (nova):
  New

Bug description:
  nova master
  devstack multinode with 2 compute nodes
  1. booting vm with direct port
  2. nova migrate 128a2ba4-fb6e-49f4-a6e0-45cde1c60215
  3. nova resize-confirm 128a2ba4-fb6e-49f4-a6e0-45cde1c60215
  4. nova migrate 128a2ba4-fb6e-49f4-a6e0-45cde1c60215
  5. nova resize-confirm 128a2ba4-fb6e-49f4-a6e0-45cde1c60215

  The second migration failed with this error:

  2016-09-12 13:12:45.750 8388 DEBUG oslo_concurrency.lockutils 
[req-a4a0126a-215a-489a-b043-ad38d3b5e28d - -] Lock "compute_resources" 
released by "nova.compute.resource_tracker._update_available_resource" :: held 
0.143s inner /usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
  2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
[req-a4a0126a-215a-489a-b043-ad38d3b5e28d - -] Error updating resources for 
node r-dcs224.mtr.labs.mlnx.
  2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager Traceback (most 
recent call last):
  2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File 
"/.autodirect/mtrswgwork/moshele/openstack/nova/nova/compute/manager.py", line 
6408, in update_available_resource_for_node
  2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager 
rt.update_available_resource(context)
  2016-09-12 13:12:45.750 8388 ERROR nova.compute.manager   File

[Yahoo-eng-team] [Bug 1621430] Re: L3 flavors handling flavor request incorrectly