[Yahoo-eng-team] [Bug 1657655] [NEW] Dashboard|出错啦！遇到异常情况，请刷新。如需帮助请联系管理员。

[Lance]

Public bug reported:

Documents:
http://docs.openstack.org/mitaka/zh_CN/
While I do with above URl
At the part of Dashboard
http://docs.openstack.org/mitaka/zh_CN/install-guide-rdo/horizon-verify.html
I can't login in ..

登录后提示：出错啦！遇到异常情况，请刷新。如需帮助请联系管理员。

** Affects: horizon
 Importance: Undecided
 Status: New

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

Title:
  Dashboard|出错啦！遇到异常情况，请刷新。如需帮助请联系管理员。

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Documents:
  http://docs.openstack.org/mitaka/zh_CN/
  While I do with above URl
  At the part of Dashboard
  http://docs.openstack.org/mitaka/zh_CN/install-guide-rdo/horizon-verify.html
  I can't login in ..

  登录后提示：出错啦！遇到异常情况，请刷新。如需帮助请联系管理员。

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1657655/+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 1653986] Re: Many views are using identical table templates

[OpenStack Infra]

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

commit 560f23a1c9bb29651be56cabf77236e3024d14c2
Author: Rob Cresswell 
Date:   Wed Jan 4 16:32:33 2017 +

Add default common template to python table views

Many of the Python table views are using identical (or nearly identical)
table templates. This patch adds a common template and makes it the
default for a DataTableView, which allows us to remove many similar
templates and redundant lines of code.

Change-Id: I1e4e15e695ee1f21f4d44f141a854e30f1e567a1
Closes-Bug: 1653986


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

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

Title:
  Many views are using identical table templates

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Many of our table views are using:

  {% extends 'base.html' %}
  {% block title %}{{ page_title }}{% endblock %}
  {% block main %}{{ table.render }}{% endblock %}

  as a template. We should make a common template and remove these.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1653986/+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 1656124] Re: Broken link to nova/devref in http://docs.openstack.org/developer/nova/how_to_get_involved.html#how-to-do-great-nova-spec-reviews

[OpenStack Infra]

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

commit b5790dd314f4e61084116eea5c69c7dbf78f2b49
Author: jichenjc 
Date:   Mon Jan 16 13:50:10 2017 +0800

Fix broken link of Doc

TrivialFix

Change-Id: I668172a1e5346ec6089c37f77423347cad3ec3cb
Closes-Bug: 1656124


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

Title:
  Broken link to nova/devref in
  http://docs.openstack.org/developer/nova/how_to_get_involved.html#how-
  to-do-great-nova-spec-reviews

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Looks like one of the links in
  http://docs.openstack.org/developer/nova/how_to_get_involved.html#how-
  to-do-great-nova-spec-reviews needs to be updated.

  That, or, some redirect is happening so that you can't ever get to a
  /devref/ listing. The link is
  http://docs.openstack.org/developer/nova/devref/kilo.blueprints.html
  #when-is-a-blueprint-needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1656124/+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 1651650] Re: XenAPI: server rescue test sometime failed with timeout waiting for vif plugging

[OpenStack Infra]

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

commit 2207dcf560413b213a8fb3737bb4b0923dcd96e0
Author: Huan Xie 
Date:   Tue Dec 20 23:26:49 2016 -0800

XenAPI: Fix vif plug problem during VM rescue/unrescue

During VM rescue tests, we found nova xenserver driver failed due
to waiting vif-plug-event from neutron timeout. when checking
nova and neutron logs, we found there are several mistakes in
nova driver:
(1) After several rounds of rescuing/unrescuing, it will wait for
vif-plug-event, but actually, it shouldn't wait for such event
(2) Checking neutron log, we found the port status sometimes will
change during rescuing/unrescuing, which also shouldn't happen
(3) Checking nova related code, we found each time when booting a
VM, it will delete and create the tap device, which is used by
neutron security group, this delete/re-create action will cause
the port status change which shouldn't be changed.
(4) When adding/deleting security groups to VM's port, it will
trigger the port status change, e.g. from ACTIVE to BUILDING, but
under rescue scenario, we also depends on VIF's status to determine
whether waiting for vif plug event is not appropriate.

This patch is to fix the above problem and there is another patch
to enable the exclude rescue tests to test this fix
https://review.openstack.org/#/c/416197/

Closes-Bug: #1651650

Change-Id: I32c6670bc9877caea7e2a2290c02b3906708


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

Title:
  XenAPI: server rescue test sometime failed with timeout waiting for
  vif plugging

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Observed several failure in citrix xenserver CI for this test case:
  tempest.api.compute.servers.test_server_rescue

  See there are timeout waiting for vif:

  $ grep 'Timeout waiting for vif plugging callbac' screen-n-cpu.txt.gz
  2016-12-20 10:58:52.036 4528 WARNING nova.virt.xenapi.vmops 
[req-ff027cef-59be-4326-95e1-065f68077d63 
tempest-ServerRescueTestJSON-1293983176 
tempest-ServerRescueTestJSON-1293983176] [instance: 
28b094ee-c571-4083-b72b-5ea78f1f4291] Timeout waiting for vif plugging callback

  For rescue, it seems shouldn't wait for this event as this port should be 
active at the rescuing start.
  But observed:
  neutron service reported the 2nd vif-plugin event:

  
  2016-12-20 10:52:31.689 712 DEBUG neutron.notifiers.nova [-] Sending events: 
[{'status': 'completed', 'tag': u'52d79a78-7205-4e69-8005-76a3cebbf267', 
'name': 'network-vif-plugged', 'server_uuid': 
u'28b094ee-c571-4083-b72b-5ea78f1f4291'}] send_events 
/opt/stack/new/neutron/neutron/notifiers/nova.py:248

  2016-12-20 10:53:45.179 712 DEBUG neutron.notifiers.nova [-] Sending
  events: [{'status': 'completed', 'tag':
  u'52d79a78-7205-4e69-8005-76a3cebbf267', 'name': 'network-vif-
  plugged', 'server_uuid': u'28b094ee-c571-4083-b72b-5ea78f1f4291'}]
  send_events /opt/stack/new/neutron/neutron/notifiers/nova.py:248

  
  And nova attempts to wait for this event after the 2nd event sent out; so it 
won't catch the 2nd event at all:
  2016-12-20 10:53:46.326 4528 DEBUG nova.virt.xenapi.vmops 
[req-ff027cef-59be-4326-95e1-065f68077d63 
tempest-ServerRescueTestJSON-1293983176 
tempest-ServerRescueTestJSON-1293983176] wait for instance 
event:[('network-vif-plugged', u'52d79a78-7205-4e69-8005-76a3cebbf267')] _spawn 
/opt/stack/new/nova/nova/virt/xenapi/vmops.py:599

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1651650/+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 1655286] Re: vmware nsx devstack config

[Matt Riedemann]

This isn't a bug. I don't know that devstack is setup to support vmware
+ NSX, but there are some guides here:

http://docs.openstack.org/admin-guide/networking-config-plugins.html

http://docs.openstack.org/newton/config-reference/compute/hypervisor-
vmware.html

http://docs.openstack.org/liberty/config-reference/content/networking-
plugin-nsx.html

Otherwise you might be able to get some help in the general openstack
mailing list:

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Or try contacting the vmware team in the #openstack-vmware channel in
freenode IRC. Gary Kotton would be a good person to contact (garyk in
IRC).

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

Title:
  vmware nsx devstack config

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  hi who can tell me how to config nsx driver in the devstack?
  i want get the detail config file .
  thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1655286/+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 1657423] Re: Instances view in Dashboard spawns "Error: Unable to retrieve instance list."

[Matt Riedemann]

The TypeError is coming from here:

https://github.com/openstack/nova/blob/stable/mitaka/nova/db/sqlalchemy/models.py#L240

So I don't know what "linuxnet_interface_driver" has to do with this.

What is the value of your "instance_name_template" config option in
nova.conf?  The default is "instance-%08x" so you must have modified
that?

As for the configuration guide for Mitaka, it's here:

http://docs.openstack.org/developer/nova/mitaka/sample_config.html

Or here:

http://docs.openstack.org/mitaka/config-reference/compute.html

So I'm not sure what's missing from the configuration guide.

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

Title:
  Instances view in Dashboard spawns "Error: Unable to retrieve instance
  list."

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  I'm running Mitaka on Ubuntu 16.04 and when I try to access Instances
  list in Dashboard, the following is error is spawned: Error: Unable to
  retrieve instance list. Same error is spawned for all users.

  Same thing happens in CLI:
  nova list --all-tenants
  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-30134c69-6c89-4437-9fd7-a2ca7b169ed7)

  Debug output of the same command from above:
  nova --debug list --all-tenants
  DEBUG (extension:157) found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
  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('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
  DEBUG (extension:157) found extension EntryPoint.parse('v3oidcpassword = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectPassword')
  DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token')
  DEBUG (extension:157) found extension EntryPoint.parse('v3token = 
keystoneauth1.loading._plugins.identity.v3:Token')
  DEBUG (extension:157) found extension EntryPoint.parse('password = 
keystoneauth1.loading._plugins.identity.generic:Password')
  DEBUG (session:248) REQ: curl -g -i -X GET http://10.0.0.1:35357/v3 -H 
"Accept: application/json" -H "User-Agent: keystoneauth1/2.4.1 
python-requests/2.9.1 CPython/2.7.12"
  INFO (connectionpool:208) Starting new HTTP connection (1): 10.0.0.1
  DEBUG (connectionpool:388) "GET /v3 HTTP/1.1" 200 248
  DEBUG (session:277) RESP: [200] Content-Length: 248 Vary: X-Auth-Token 
Server: Apache/2.4.18 (Ubuntu) Date: Wed, 18 Jan 2017 11:25:28 GMT 
x-openstack-request-id: req-43f828d7-4919-4d24-acbf-513c1b7fa496 Content-Type: 
application/json X-Distribution: Ubuntu 
  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://10.0.0.1:35357/v3/;, "rel": "self"}]}}

  DEBUG (base:165) Making authentication request to 
http://10.0.0.1:35357/v3/auth/tokens
  DEBUG (connectionpool:388) "POST /v3/auth/tokens HTTP/1.1" 201 7476
  DEBUG (session:248) REQ: curl -g -i -X GET 
http://10.0.0.1:8774/v2.1/b77576d7ea0c45a3a24a8da20dbe983e -H "User-Agent: 
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}c3bd40d9088aa0e9755d065fa91cea9d5736b361"
  INFO (connectionpool:208) Starting new HTTP connection (1): 10.0.0.1
  DEBUG (connectionpool:388) "GET /v2.1/b77576d7ea0c45a3a24a8da20dbe983e 
HTTP/1.1" 404 52
  DEBUG (session:277) RESP: [404] Date: Wed, 18 Jan 2017 11:25:33 GMT 
Content-Length: 52 Content-Type: text/plain; charset=UTF-8 
X-Compute-Request-Id: req-06891843-9fe6-432f-b038-2191efd401b0 
  RESP BODY: 404 Not Found

  The resource could not be found.


  DEBUG (session:248) REQ: curl -g -i -X GET http://10.0.0.1:8774/v2.1/ -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}c3bd40d9088aa0e9755d065fa91cea9d5736b361"
  DEBUG (connectionpool:388) "GET /v2.1/ HTTP/1.1" 200 382
  DEBUG (session:277) RESP: [200] Content-Length: 382 X-Compute-Request-Id: 
req-732fd6ce-57b0-4858-9740-4bbd9899de6a Vary: X-OpenStack-Nova-API-Version 
X-Openstack-Nova-Api-Version: 2.1 Date: Wed, 18 Jan 2017 11:25:33 GMT 
Content-Type: application/json 
  RESP BODY: {"version": {"status": "CURRENT", "updated": 
"2013-07-23T11:33:21Z", "links": [{"href": 

[Yahoo-eng-team] [Bug 1657597] [NEW] Floating IP association to allowed address pair fails due to transaction in transaction

[Daniel Russell]

Public bug reported:

When associating a floating IP address to an instance's allowed address
pair, the action fails with the following stack :

update failed: No details. 
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 79, 
in resource
result = method(request=request, **args)
  File "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 604, in 
update
return self._update(request, id, body, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 88, in wrapped
setattr(e, '_RETRY_EXCEEDED', True)
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 84, in wrapped
return f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/oslo_db/api.py", line 151, in wrapper
ectxt.value = e.inner_exc
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise 
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python2.7/site-packages/oslo_db/api.py", line 139, in wrapper
return f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 124, in 
wrapped
traceback.format_exc())
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 119, in 
wrapped
return f(*dup_args, **dup_kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 652, in 
_update
obj = obj_updater(request.context, id, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 159, in 
wrapped
return method(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 88, in wrapped
setattr(e, '_RETRY_EXCEEDED', True)
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 84, in wrapped
return f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/oslo_db/api.py", line 151, in wrapper
ectxt.value = e.inner_exc
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python2.7/site-packages/oslo_db/api.py", line 139, in wrapper
return f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 124, in 
wrapped
traceback.format_exc())
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
self.force_reraise()
  File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/usr/lib/python2.7/site-packages/neutron/db/api.py", line 119, in 
wrapped
return f(*dup_args, **dup_kwargs)
  File "/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 1020, 
in update_floatingip
context, id, floatingip)
  File "/usr/lib/python2.7/site-packages/neutron/db/l3_db.py", line 1352, in 
_update_floatingip
context.elevated(), fip_port_id))
  File "/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 284, in 
_update_fip_assoc
port)
  File "/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 297, in 
_inherit_service_port_and_arp_update
address_pair_port=allowed_address_port))
  File "/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 1073, 
in update_unbound_allowed_address_pair_port_binding
context, address_pair_port['id'], {'port': port_data})
  File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 755, in 
inner
"transaction.") % f) 
RuntimeError: Method  cannot be called 
within a transaction.

** Affects: neutron
 Importance: Undecided
 Assignee: Daniel Russell (danielr-2)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => Daniel Russell (danielr-2)

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

Title:
  Floating IP association to allowed address pair fails due to
  transaction in 

[Yahoo-eng-team] [Bug 1557032] Re: Add "allow_migrate_to_same_host" in deprecated options for nova.conf

[Matt Riedemann]

This option was removed in the Liberty 12.0.0 release (without a
deprecation period admittedly). The only way to get this back into
nova.conf right now is to register the option but mark it deprecated,
even though it's not even used in the code, which doesn't make sense at
this point for something that was removed in Liberty (and Liberty is EOL
now). So I've marked this as Won't Fix also for Nova.

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

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

Title:
  Add  "allow_migrate_to_same_host" in deprecated options for nova.conf

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

Bug description:
  default configuration option "allow_migrate_to_same_host" from
  nova.conf is no longer used. Add this to deprecated options for
  OpenStack compute.

  Detailed information can be found at:
  https://bugs.launchpad.net/nova/+bug/1364851

  doc source: openstack-manuals/doc/config-reference/source/tables/conf-
  changes/nova.rst

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1557032/+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 1657467] Re: placement: unable to refresh compute resource provider record

[Emilien Macchi]

We've found it it comes from HAproxy configuration in TripleO. We're
working on it now.

** No longer affects: nova

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

Title:
  placement: unable to refresh  compute resource provider record

Status in tripleo:
  Triaged

Bug description:
  Deploying Nova Placement API used to work a few days ago in TripleO
  and Puppet OpenStack CIs but not anymore.

  "Unable to refresh my resource provider record"

  nova-compute log files:
  
http://logs.openstack.org/66/421366/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/f138bcc/logs/nova/nova-compute.txt.gz#_2017-01-17_17_32_39_092

  nova.conf:
  https://paste.fedoraproject.org/529703/14847479/

To manage notifications about this bug go to:
https://bugs.launchpad.net/tripleo/+bug/1657467/+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 1657585] [NEW] HTTP 500 for assisted volume snapshot on shelved instance

[Eric Harney]

Public bug reported:

Nova throws an HTTP 500 when trying to create an assisted volume
snapshot for Cinder NFS if the instance is shelved.  (Has no "host"
field, presumably.)

To reproduce:

1.  Pull https://review.openstack.org/#/c/147186/48 for Cinder NFS snapshot 
support.
2.  Create instance.
3.  Attach NFS volume to instance.
4.  Shelve instance.
5.  Cinder snapshot-create on the volume.


2017-01-18 16:43:38.002 DEBUG nova.api.openstack.wsgi 
[req-e441340d-8147-4a03-b401-198ecb0e760d nova service] Action: 'create', 
calling method: >, body: {"snapshot": {"create_info": {"snapshot_id": 
"6e9292a6-ddaf-42f5-9cc7-374f9470e406", "type": "qcow2", "new_file": 
"volume-924ae600-6bfc-47f9-ae48-87eb34fe3c21.6e9292a6-ddaf-42f5-9cc7-374f9470e406"},
 "volume_id": "924ae600-6bfc-47f9-ae48-87eb34fe3c21"}} from (pid=13329) 
_process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:623
2017-01-18 16:43:38.080 ERROR nova.api.openstack.extensions 
[req-e441340d-8147-4a03-b401-198ecb0e760d nova service] Unexpected exception in 
API method
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions Traceback (most 
recent call last):
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/extensions.py", line 338, in wrapped
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions return f(*args, 
**kwargs)
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/compute/assisted_volume_snapshots.py", line 
55, in create
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions create_info)
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/compute/api.py", line 3935, in volume_snapshot_create
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions volume_id, 
create_info)
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/compute/rpcapi.py", line 1044, in volume_snapshot_create
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions 
server=_compute_host(None, instance), version=version)
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/compute/rpcapi.py", line 53, in _compute_host
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions 'Instance %s') 
% instance.uuid)
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions NovaException: 
Unable to find host for Instance 875480c0-8f5e-44e9-9778-b39d6256cfb9
2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions

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

Title:
  HTTP 500 for assisted volume snapshot on shelved instance

Status in OpenStack Compute (nova):
  New

Bug description:
  Nova throws an HTTP 500 when trying to create an assisted volume
  snapshot for Cinder NFS if the instance is shelved.  (Has no "host"
  field, presumably.)

  To reproduce:

  1.  Pull https://review.openstack.org/#/c/147186/48 for Cinder NFS snapshot 
support.
  2.  Create instance.
  3.  Attach NFS volume to instance.
  4.  Shelve instance.
  5.  Cinder snapshot-create on the volume.

  
  2017-01-18 16:43:38.002 DEBUG nova.api.openstack.wsgi 
[req-e441340d-8147-4a03-b401-198ecb0e760d nova service] Action: 'create', 
calling method: >, body: {"snapshot": {"create_info": {"snapshot_id": 
"6e9292a6-ddaf-42f5-9cc7-374f9470e406", "type": "qcow2", "new_file": 
"volume-924ae600-6bfc-47f9-ae48-87eb34fe3c21.6e9292a6-ddaf-42f5-9cc7-374f9470e406"},
 "volume_id": "924ae600-6bfc-47f9-ae48-87eb34fe3c21"}} from (pid=13329) 
_process_stack /opt/stack/nova/nova/api/openstack/wsgi.py:623
  2017-01-18 16:43:38.080 ERROR nova.api.openstack.extensions 
[req-e441340d-8147-4a03-b401-198ecb0e760d nova service] Unexpected exception in 
API method
  2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions Traceback (most 
recent call last):
  2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/extensions.py", line 338, in wrapped
  2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions return 
f(*args, **kwargs)
  2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/validation/__init__.py", line 73, in wrapper
  2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions return 
func(*args, **kwargs)
  2017-01-18 16:43:38.080 TRACE nova.api.openstack.extensions   File 
"/opt/stack/nova/nova/api/openstack/compute/assisted_volume_snapshots.py", line 
55, in create
  2017-01-18 16:43:38.080 TRACE 

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

[Corey Bryant]

Liang, thanks for the patches. LGTM. I'll upload once a local build
passes.

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** No longer affects: cloud-archive

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/icehouse
   Importance: Undecided
   Status: New

** Changed in: cloud-archive
   Status: New => Invalid

** Changed in: cloud-archive
   Status: Invalid => Fix Released

** Changed in: cloud-archive/icehouse
   Status: New => In Progress

** Changed in: cloud-archive/icehouse
   Importance: Undecided => Medium

** Changed in: cloud-archive
   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 Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive icehouse series:
  In Progress
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
   * Passed tempest smoke tests locally.

  Note: one simple way to put an instance into error state is to
  directly change its database record, for example "update instances set
  vm_state='error' where uuid=''"


  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/cloud-archive/+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 1557032] Re: Add "allow_migrate_to_same_host" in deprecated options for nova.conf

[Alexandra Settle]

Marking as Won't Fix. This needs to be updated in the nova repo, and not
the docs repo. So that the files can be updated with the auto-config
tool.

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

** Changed in: openstack-manuals
   Status: In Progress => Won't Fix

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

Title:
  Add  "allow_migrate_to_same_host" in deprecated options for nova.conf

Status in OpenStack Compute (nova):
  New
Status in openstack-manuals:
  Won't Fix

Bug description:
  default configuration option "allow_migrate_to_same_host" from
  nova.conf is no longer used. Add this to deprecated options for
  OpenStack compute.

  Detailed information can be found at:
  https://bugs.launchpad.net/nova/+bug/1364851

  doc source: openstack-manuals/doc/config-reference/source/tables/conf-
  changes/nova.rst

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1557032/+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 1569101] Re: Update Nova process docs to reflect the current release

[Anusha Unnam]

Yes this bug is fixed, so marking it as invalid.

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

Title:
  Update Nova process docs to reflect the current release

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  The Nova process docs contain a number of references to Liberty &
  Mitaka that should be updated to reflect the current release (Newton).

  http://docs.openstack.org/developer/nova/process.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1569101/+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 1567009] Re: Remove flavor seeding from the base migration

[Alexandra Settle]

** Changed in: openstack-manuals
   Status: In Progress => Won't Fix

** Changed in: openstack-manuals
   Status: Won't Fix => Confirmed

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

Title:
  Remove flavor seeding from the base migration

Status in OpenStack Compute (nova):
  Invalid
Status in openstack-manuals:
  Confirmed

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

  commit 1a1a41bdbe0dc16ca594236925e77ce99f432b9d
  Author: Dan Smith 
  Date:   Thu Mar 31 10:57:14 2016 -0700

  Remove flavor seeding from the base migration
  
  In a time long ago and a land far far away, someone thought it was a
  good idea to populate the database with default flavors. That was
  probably reasonable at the time, but it no longer makes sense and
  in fact causes us some pain now.
  
  This patch removes those default flavors from the database. That means
  that new deploys will not have them, but doesn't actually rewrite
  history in any way.
  
  This will require changes to our docs, which largely assume the presence
  of these default flavors from time zero.
  
  DocImpact
  
  Depends-On: Ic275887e97221d9ce5ce6f12cdcfb5ac94e300b0
  Change-Id: I80b63ce1ebca01be61ac0f43d26a2992ecf16678

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1567009/+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 1502773] Re: "Delete Instance" looks better over "Terminate Instance" for consistency

[Alexandra Settle]

** Changed in: openstack-manuals
   Status: In Progress => Fix Released

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

Title:
  "Delete Instance" looks better over "Terminate Instance" for
  consistency

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in openstack-manuals:
  Fix Released

Bug description:
  "Delete Instance" looks better than "Terminate Instance" for consistency.
  We use "Terminate Instance" for the action label of deleting a server.
  I think "Delete Instance" is more consistent from the point of both 
consistency across OpenStack Dashboard and consistency with nova/openstack CLI.

  In addition, I think "Delete" is easier for users to associate this operation 
will delete the instance data completely.
  "Terminate" is a strong word and native English speaker can image this 
operation crashes the instance and we can never use it again, but it is not 
easy that non-native speakers can understand such kind of nuance of the word.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1502773/+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 1570270] Re: nova.sample.conf: The xenserver docs have a wrong indentation

[Anusha Unnam]

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

** Changed in: nova
 Assignee: Hemanth Makkapati (hemanth-makkapati) => (unassigned)

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

Title:
  nova.sample.conf: The xenserver docs have a wrong indentation

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Version: Nova Newton master b335318 Jenkins 2016-04-13

  Steps to reproduce:
  * checkout nova code
  * in base folder execute: "tox -e genconfig"
  * check section "[xenserver]" in file "etc/nova/nova.conf.sample"

  There is too much whitespace between the "#" on the left side until
  the actual doc starts. The multiline comment at [2] is not properly
  formatted. See the other sections for the expected result.

  See the rendered result at [1]. Launchpad crops the superfluous
  whitespace, so I cannot show an example here.

  References:
  [1] http://docs.openstack.org/developer/nova/sample_config.html
  [2] 
https://github.com/openstack/nova/blob/b335318a6254e0e4752bcf0665579527b628c963/nova/conf/xenserver.py

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1570270/+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 1656854] Re: Incorrect metada in ConfigDrive when using barematal ports under neutron

[Matt Riedemann]

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

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

** Tags added: ironic metadata

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

Title:
  Incorrect metada in ConfigDrive when using barematal ports under
  neutron

Status in Ironic:
  Invalid
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) newton series:
  New

Bug description:
  If baremetal instance is booted with neutron network and config drive
  enabled, it receives incorrect network data in network_data.json,
  which cause trace in cloud-init: ValueError: Unknown network_data link
  type: unbound

  All software is at Newton:  ironic (1:6.2.1-0ubuntu1), nova
  (2:14.0.1-0ubuntu1), neutron (2:9.0.0-0ubuntu1).

  network_data.json content:

  {"services": [{"type": "dns", "address": "8.8.8.8"}], "networks":
  [{"network_id": "d22a675f-f89c-44ae-ae48-bb64e4b81a3d", "type":
  "ipv4", "netmask": "255.255.255.224", "link": "tap7d178b79-86",
  "routes": [{"netmask": "0.0.0.0", "network": "0.0.0.0", "gateway":
  "204.74.228.65"}], "ip_address": "204.74.228.75", "id": "network0"}],
  "links": [{"ethernet_mac_address": "18:66:da:5f:07:f4", "mtu": 1500,
  "type": "unbound", "id": "tap7d178b79-86", "vif_id":
  "7d178b79-86a9-4e56-824e-fe503e422960"}]}

  neutron port description:
  openstack  port show 7d178b79-86a9-4e56-824e-fe503e422960  -f json
  {
"status": "DOWN", 
"binding_profile": "local_link_information='[{u'switch_info': u'c426s1', 
u'port_id': u'1/1/21', u'switch_id': u'60:9c:9f:49:a8:b4'}]'", 
"project_id": "7d450ecf00d64399aeb93bc122cb6dae", 
"binding_vnic_type": "baremetal", 
"binding_vif_details": "", 
"name": "", 
"admin_state_up": "UP", 
"network_id": "d22a675f-f89c-44ae-ae48-bb64e4b81a3d", 
"created_at": "2017-01-16T14:32:27Z", 
"updated_at": "2017-01-16T14:36:22Z", 
"id": "7d178b79-86a9-4e56-824e-fe503e422960", 
"device_owner": "baremetal:none", 
"binding_host_id": "d02c7361-5e3a-4fdf-89b5-f29b3901f0fc", 
"revision_number": 7, 
"mac_address": "18:66:da:5f:07:f4", 
"binding_vif_type": "other", 
"device_id": "9762e013-ffb9-4512-a56d-2a11694a1de8", 
"fixed_ips": "ip_address='204.74.228.75', 
subnet_id='f41ae071-d0d8-4192-96c3-1fd73886275b'", 
"extra_dhcp_opts": "", 
"description": ""
  }

  ironic is configured for multitenancy (to use neutron): 
default_network_interface=neutron.
  neutron is configured for ML2, ML2 is configured for 
networking_generic_switch. Former works fine and toggle port on real switch in 
vlan (access) and out.

  Network is configured to work with vlans.

  Network description:
  openstack network show client-22-vlan  -f json
  {
"status": "ACTIVE", 
"router:external": "Internal", 
"availability_zone_hints": "", 
"availability_zones": "nova", 
"description": "", 
"provider:physical_network": "client", 
"admin_state_up": "UP", 
"updated_at": "2017-01-16T13:01:47Z", 
"created_at": "2017-01-16T12:59:10Z", 
"tags": [], 
"ipv6_address_scope": null, 
"provider:segmentation_id": 22, 
"mtu": 1500, 
"provider:network_type": "vlan", 
"revision_number": 5, 
"ipv4_address_scope": null, 
"subnets": "f41ae071-d0d8-4192-96c3-1fd73886275b", 
"shared": false, 
"project_id": "7d450ecf00d64399aeb93bc122cb6dae", 
"id": "d22a675f-f89c-44ae-ae48-bb64e4b81a3d", 
"name": "client-22-vlan"
  }

  subnet description:
  openstack  subnet show f41ae071-d0d8-4192-96c3-1fd73886275b  -f json
  {
"service_types": [], 
"description": "", 
"enable_dhcp": false, 
"network_id": "d22a675f-f89c-44ae-ae48-bb64e4b81a3d", 
"created_at": "2017-01-16T13:01:12Z", 
"dns_nameservers": "8.8.8.8", 
"updated_at": "2017-01-16T13:01:47Z", 
"ipv6_ra_mode": null, 
"allocation_pools": "204.74.228.66-204.74.228.94", 
"gateway_ip": "204.74.228.65", 
"revision_number": 3, 
"ipv6_address_mode": null, 
"ip_version": 4, 
"host_routes": "", 
"cidr": "204.74.228.64/27", 
"project_id": "7d450ecf00d64399aeb93bc122cb6dae", 
"id": "f41ae071-d0d8-4192-96c3-1fd73886275b", 
"subnetpool_id": null, 
"name": ""
  }

  Boot command:

  openstack server create good --config-drive true --flavor bare-1
  --image ubuntu-custom-7 --key-name keybane --nic net-id=d22a675f-f89c-
  44ae-ae48-bb64e4b81a3d

  According to  vdrok from #openstack-ironic allowed types for interface for 
cloud-init are:
  'bridge', 'ethernet', 'hw_veb', 'hyperv', 'ovs', 'phy', 'tap', 'vhostuser', 
'vif', 'bond', 'vlan'

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

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

[Yahoo-eng-team] [Bug 1657529] [NEW] Remove unused columns from BuildRequest table in nova_api db.

[Pushkar Umaranikar]

Public bug reported:

Some columns from BuildRequest table in nova_api schema are no longer
used.

They have been removed from data model as a part of this commit
https://github.com/openstack/nova/commit/98a05bc637e4c2e485d5aa5b62945102ea71d08b

In Ocata, we can drop respective columns from database.

** Affects: nova
 Importance: Undecided
 Assignee: Pushkar Umaranikar (pushkar-umaranikar)
 Status: New


** Tags: db

** Tags added: db

** Changed in: nova
 Assignee: (unassigned) => Pushkar Umaranikar (pushkar-umaranikar)

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

Title:
  Remove unused columns from BuildRequest table in nova_api db.

Status in OpenStack Compute (nova):
  New

Bug description:
  Some columns from BuildRequest table in nova_api schema are no longer
  used.

  They have been removed from data model as a part of this commit
  
https://github.com/openstack/nova/commit/98a05bc637e4c2e485d5aa5b62945102ea71d08b

  In Ocata, we can drop respective columns from database.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1657529/+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 1557165] Re: Add docs for additional bootstrap endpoint parameters

[Alexandra Settle]

This should all be up-to-date and relevant. Requires no further
documentation.

** Changed in: openstack-manuals
   Status: Confirmed => Won't Fix

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

Title:
  Add docs for additional bootstrap endpoint parameters

Status in OpenStack Identity (keystone):
  Invalid
Status in openstack-manuals:
  Won't Fix

Bug description:
  https://review.openstack.org/290226
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/keystone" 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 258d09a5ac0ee8ed98e8cf6c06319ab7760cf00f
  Author: Jamie Lennox 
  Date:   Wed Mar 9 12:53:45 2016 +1100

  Add docs for additional bootstrap endpoint parameters
  
  The patch to add the endpoint parameters to the bootstrap command didn't
  update the documentation to show how to use these commands. Add this
  information now.
  
  Original Patch: Ie78c61ecf1e5f787dd2528b887c1642fd8d457ff
  Related-Bug: #1550057
  DocImpact
  
  Change-Id: I5a1cb38b05ebcb8c44c9cf90a490c849f44dbc32

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1557165/+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 1654427] Re: api-ref: a wrong description for 'hosts' parameter in os-availability-zone.inc

[OpenStack Infra]

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

commit 7c66d4184b225e7f3eda77aee84663e1f1d09c53
Author: Takashi NATSUME 
Date:   Fri Jan 6 07:59:11 2017 +0900

api-ref: Fix a parameter in os-availability-zone.inc

In "Get Availability Zone Information",
the 'hosts' response parameter is always 'null'.
So fix the description.

Change-Id: I23bd8b3a422aa03c3f56d7f2f10f6603acd0078a
Closes-Bug: #1654427


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

Title:
  api-ref: a wrong description for 'hosts' parameter in os-availability-
  zone.inc

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  http://developer.openstack.org/api-ref/compute/#availability-zones-os-
  availability-zone

  In "Get Availability Zone Information", the 'hosts' response parameter
  is always 'null'.

  
https://github.com/openstack/nova/blob/75a4869a845e42cf63e1bfdaaeddafcda219ee28/nova/api/openstack/compute/availability_zone.py#L44

  The following current description for it is not proper.

  > An object containing a list of host information.
  > The host information is comprised of host and service objects.
  > The service object returns three parameters representing the states of the 
service: active, available, and updated_at.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1654427/+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 1552994] Re: [FG-VD-16-013] Openstack Dashboard DoS Vulnerability Notification

[Jeremy Stanley]

Unless instructions are provided as to how to reproduce this, it's class
E. Since this report is already public, I've switched our advisory
status accordingly. If new evidence is presented that there is any
actual risk here, we can revisit the report at that time.

** Information type changed from Public Security to Public

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

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

Title:
  [FG-VD-16-013] Openstack Dashboard DoS Vulnerability Notification

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Security Advisory:
  Invalid

Bug description:
  Vulnerability Notification
  March 3, 2016
  Tracking Case #: FG-VD-16-013

  Dear Openstack,

  The following information pertains to information discovered by
  Fortinet's FortiGuard Labs. It has been determined that a
  vulnerability exists in Openstack Dashboard module.  To streamline the
  disclosure process, we have created a preliminary advisory which you
  can find below. This upcoming advisory is purely intended as a
  reference, and does not contain sensitive information such as proof of
  concept code.

  As a mature corporation involved in security research, we strive to
  responsibly disclose vulnerability information. We will not post an
  advisory until we determine it is appropriate to do so in co-
  ordination with the vendor unless a resolution cannot be reached. We
  will not disclose full proof of concept, only details relevant to the
  advisory.

  We look forward to working closely with you to resolve this issue, and
  kindly ask for your co-operation during this time. Please let us know
  if you have any further questions, and we will promptly respond to
  address any issues.

  If this message is not encrypted, it is because we could not find your
  key to do so. If you have one available for use, please notify us and
  we will ensure that this is used in future correspondence. We ask you
  use our public PGP key to encrypt and communicate any sensitive
  information with us. You may find the key on our FortiGuard center at:
  http://www.fortiguard.com/pgp_key.html.

  Type of Vulnerability & Repercussions:
    DoS

  Affected Software:
    Ubuntu 14.04.3 with latest repository installed
    # apt-get install software-properties-common
    # add-apt-repository cloud-archive:liberty

  Upcoming Advisory Reference:
    http://www.fortiguard.com/advisory/UpcomingAdvisories.html

  Credits:
    This vulnerability was discovered by Fortinet's FortiGuard Labs.

  Proof of Concept/How to Reproduce:
    1. Sign in Dashboard with a non-admin user credential in Chrome or Firefox, 
for example the user demo.
    2. Create a new tab in browser and open the PoC force_logout.html which can 
be hosted on any website.
    3. In Dashboard, when the currently logged-on user clicks any link, he/she 
is forced to logout with a hint "Unauthorized. Please try logging in again.". 
When he/she signs in Dashboard again and clicks any link, he/she is again 
forced to logout with the same hint.
    4. This is caused by the PoC force_logout.html which periodly accesses an 
invalid link 
"http://10.0.0.11/horizon/identity/users/12345678901234567890123456789011/detail/;.
 Please note the user id in the link is fake. When accessing it, the non-admin 
user is forced to logout because the response of the invalid link request 
contains a "sessionid" clear action which can result in DoS in the same browser.

   Notes:
   1) Tested the PoC force_logout.html successfully in Chrome and Firefox.
   2) Replace the IP 10.0.0.11 with your real Openstack control node IP in 
force_logout.html.

   Additional Information:

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1552994/+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 1657496] [NEW] Nova cannot find cinder v3 endpoint

[Scott DAngelo]

Public bug reported:

We are unable to use cinder v3 endpoint.
To Reproduce put the following in nova.conf:
 [cinder]
  catalog_info = volumev3:cinderv3:publicURL

When nova first uses the cinderclient for a volume-attach, an exception will be 
thrown:
2017-01-05 19:30:30.353 7049 ERROR nova.compute.manager [instance: 
cf1ec253-8a03-4080-a7dd-768090c86c5e] raise exceptions.EndpointNotFound(msg)
2017-01-05 19:30:30.353 7049 ERROR nova.compute.manager [instance: 
cf1ec253-8a03-4080-a7dd-768090c86c5e] EndpointNotFound: publicURL endpoint for 
volumev3 service named cinderv3 in RegionOne region not found

See: http://logs.openstack.org/82/385682/3/check/gate-tempest-dsvm-
neutron-full-ubuntu-
xenial/0a4185b/logs/screen-n-cpu.txt.gz?level=TRACE#_2017-01-05_19_30_30_353

This fix is required:

diff --git a/nova/context.py b/nova/context.py
index 68dcdad..02549f3 100644
--- a/nova/context.py
+++ b/nova/context.py
@@ -102,8 +102,8 @@ class RequestContext(context.RequestContext):
 if service_catalog:
 # Only include required parts of service_catalog
 self.service_catalog = [s for s in service_catalog
-if s.get('type') in ('volume', 'volumev2', 'key-manager',
- 'placement')]
+if s.get('type') in ('volume', 'volumev2', 'volumev3',
+ 'key-manager', 'placement')]
 else:
 # if list is empty or none
 self.service_catalog = []

** Affects: nova
 Importance: Undecided
 Assignee: Scott DAngelo (scott-dangelo)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Scott DAngelo (scott-dangelo)

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

Title:
  Nova cannot find cinder v3 endpoint

Status in OpenStack Compute (nova):
  New

Bug description:
  We are unable to use cinder v3 endpoint.
  To Reproduce put the following in nova.conf:
   [cinder]
catalog_info = volumev3:cinderv3:publicURL

  When nova first uses the cinderclient for a volume-attach, an exception will 
be thrown:
  2017-01-05 19:30:30.353 7049 ERROR nova.compute.manager [instance: 
cf1ec253-8a03-4080-a7dd-768090c86c5e] raise exceptions.EndpointNotFound(msg)
  2017-01-05 19:30:30.353 7049 ERROR nova.compute.manager [instance: 
cf1ec253-8a03-4080-a7dd-768090c86c5e] EndpointNotFound: publicURL endpoint for 
volumev3 service named cinderv3 in RegionOne region not found

  See: http://logs.openstack.org/82/385682/3/check/gate-tempest-dsvm-
  neutron-full-ubuntu-
  xenial/0a4185b/logs/screen-n-cpu.txt.gz?level=TRACE#_2017-01-05_19_30_30_353

  This fix is required:

  diff --git a/nova/context.py b/nova/context.py
  index 68dcdad..02549f3 100644
  --- a/nova/context.py
  +++ b/nova/context.py
  @@ -102,8 +102,8 @@ class RequestContext(context.RequestContext):
   if service_catalog:
   # Only include required parts of service_catalog
   self.service_catalog = [s for s in service_catalog
  -if s.get('type') in ('volume', 'volumev2', 'key-manager',
  - 'placement')]
  +if s.get('type') in ('volume', 'volumev2', 'volumev3',
  + 'key-manager', 'placement')]
   else:
   # if list is empty or none
   self.service_catalog = []

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1657496/+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 1657459] Re: WebOb>=1.2.3 requirement for Glance will lead to 0 bytes backing image files on OpenStack Newton, although the image file sent to the python client does not have 0 b

[Corey Bryant]

This is related to issues we're hitting in ubuntu which is at webob
1.7.0 now: https://bugs.launchpad.net/nova/+bug/1657452

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

** Changed in: glance (Ubuntu)
   Status: New => Triaged

** Changed in: glance (Ubuntu)
   Importance: Undecided => High

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

Title:
  WebOb>=1.2.3 requirement for Glance will  lead to 0 bytes backing
  image files on OpenStack Newton, although the image file sent to the
  python client does not have 0 bytes

Status in Glance:
  Triaged
Status in glance package in Ubuntu:
  Triaged

Bug description:
  On CentOS 7 AIO Newton OpenStack deployed with packstack, the default
  WebOb glance requirement was >= 1.2.3 and pip installed the 1.7.0
  version.

  When I created a glance image from the cli, using the filesystem
  backend as default, with a raw file of 1GB, the glance image-create
  command showed that a image was created, but with the size of 0 bytes.

  After forcing with pip the WebOb==1.2.3 version, the issue was not
  longer there.

  I have tried with python 2.7 and 3.4 and to upload the image via
  horizon or with different python-glance client versions => when WebOb
  version was 1.7.0 the outcome was wrong, as I ended up with a 0 bytes
  image in the backing store.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1657459/+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 1657481] [NEW] unused import

[liao...@hotmail.com]

Public bug reported:

unused import horizon/management/commands/startdash.py:14

** Affects: horizon
 Importance: Undecided
 Assignee: liao...@hotmail.com (liaozd)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => liao...@hotmail.com (liaozd)

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

Title:
  unused import

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  unused import horizon/management/commands/startdash.py:14

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1657481/+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 1654287] Re: functional test netns_cleanup failing in gate

[Daniel Alvarez]

** Also affects: oslo.rootwrap
   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/1654287

Title:
  functional test netns_cleanup failing in gate

Status in neutron:
  In Progress
Status in oslo.rootwrap:
  New

Bug description:
  
  The functional test for netns_cleanup has failed in the gate today [0].

  Apparently, when trying to get the list of devices
  (ip_lib.get_devices() 'find /sys/class/net -maxdepth 1 -type 1 -printf
  %f') through rootwrap_daemon, it's getting the output of the previous
  command instead ('netstat -nlp'). This causes that the netns_cleanup
  module tries to unplug random devices which correspond to the actual
  output of the 'netstat' command.

  This bug doesn't look related to the test itself but to
  rootwrap_daemon? Maybe due to long output to the netstat command?

  
  Relevant part of the log

  2017-01-05 12:17:04.609 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Running command (rootwrap 
daemon): ['ip', 'netns', 'exec', 
'qrouter-cf2030c6-c924-45bb-b13b-6774d275b394', 'netstat', '-nlp'] 
execute_rootwrap_daemon neutron/agent/linux/utils.py:108
  2017-01-05 12:17:04.613 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Exit code: 0 execute 
neutron/agent/linux/utils.py:149
  2017-01-05 12:17:04.614 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Running command (rootwrap 
daemon): ['ip', 'netns', 'exec', 
'qrouter-cf2030c6-c924-45bb-b13b-6774d275b394', 'find', '/sys/class/net', 
'-maxdepth', '1', '-type', 'l', '-printf', '%f '] execute_rootwrap_daemon 
neutron/agent/linux/utils.py:108
  2017-01-05 12:17:04.645 27615 DEBUG neutron.agent.ovsdb.native.vlog [-] 
[POLLIN] on fd 14 __log_wakeup 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/ovs/poller.py:202
  2017-01-05 12:17:04.686 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Exit code: 0 execute 
neutron/agent/linux/utils.py:149
  2017-01-05 12:17:04.688 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Running command (rootwrap 
daemon): ['ip', 'netns', 'exec', 
'qrouter-cf2030c6-c924-45bb-b13b-6774d275b394', 'ip', 'link', 'delete', 
'Active'] execute_rootwrap_daemon neutron/agent/linux/utils.py:108
  2017-01-05 12:17:04.746 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Exit code: 0 execute 
neutron/agent/linux/utils.py:149
  2017-01-05 12:17:04.747 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Running command (rootwrap 
daemon): ['ip', 'netns', 'exec', 
'qrouter-cf2030c6-c924-45bb-b13b-6774d275b394', 'ip', 'link', 'delete', 
'Internet'] execute_rootwrap_daemon neutron/agent/linux/utils.py:108
  2017-01-05 12:17:04.758 27615 DEBUG neutron.agent.ovsdb.native.vlog [-] 
[POLLIN] on fd 14 __log_wakeup 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/ovs/poller.py:202
  2017-01-05 12:17:04.815 27615 DEBUG neutron.agent.ovsdb.native.vlog [-] 
[POLLIN] on fd 14 __log_wakeup 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/ovs/poller.py:202
  2017-01-05 12:17:04.822 27615 DEBUG neutron.agent.ovsdb.native.vlog [-] 
[POLLIN] on fd 7 __log_wakeup 
/opt/stack/new/neutron/.tox/dsvm-functional/local/lib/python2.7/site-packages/ovs/poller.py:202
  2017-01-05 12:17:04.822 27615 DEBUG neutron.agent.ovsdb.impl_idl [-] Running 
txn command(idx=0): InterfaceToBridgeCommand(name=Internet) do_commit 
neutron/agent/ovsdb/impl_idl.py:100
  2017-01-05 12:17:04.823 27615 DEBUG neutron.agent.ovsdb.impl_idl [-] 
Transaction aborted do_commit neutron/agent/ovsdb/impl_idl.py:124
  2017-01-05 12:17:04.824 27615 DEBUG neutron.cmd.netns_cleanup 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Unable to find bridge for 
device: Internet unplug_device neutron/cmd/netns_cleanup.py:138
  2017-01-05 12:17:04.824 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Running command (rootwrap 
daemon): ['ip', 'netns', 'exec', 
'qrouter-cf2030c6-c924-45bb-b13b-6774d275b394', 'ip', 'link', 'delete', 
'connections'] execute_rootwrap_daemon neutron/agent/linux/utils.py:108
  
  2017-01-05 12:17:06.388 27615 DEBUG neutron.cmd.netns_cleanup 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Unable to find bridge for 
device: Path unplug_device neutron/cmd/netns_cleanup.py:138
  2017-01-05 12:17:06.389 27615 DEBUG neutron.agent.linux.utils 
[req-68eceb29-052a-4c8c-8152-38bbe636cba5 - - - - -] Running command (rootwrap 
daemon): ['ip', '-o', 'netns', 'list'] execute_rootwrap_daemon 
neutron/agent/linux/utils.py:108
  2017-01-05 12:17:06.454 27615 ERROR 

[Yahoo-eng-team] [Bug 1657452] Re: Incompatibility with python-webob 1.7.0

[Corey Bryant]

nova failures with webob 1.7.0:

nova.tests.unit.api.openstack.compute.test_microversions.MicroversionsTest.test_microversions_inner_function_v21


Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
302, in test_microversions_inner_function_v21
self._test_microversions_inner_function('2.1', 'controller4_val1')
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in 
patched
return func(*args, **keywargs)
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
291, in _test_microversions_inner_function
self.assertEqual(200, res.status_int)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, 
in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, 
in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 200 != 400


Captured pythonlogging:
~~~
2017-01-18 08:45:09,875 INFO [nova.api.openstack] Loaded extensions: 
['test-basic', 'test-microversions']


nova.tests.unit.api.openstack.compute.test_microversions.LegacyMicroversionsTest.test_microversions_inner_function_v21
--

Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
302, in test_microversions_inner_function_v21
self._test_microversions_inner_function('2.1', 'controller4_val1')
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in 
patched
return func(*args, **keywargs)
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
291, in _test_microversions_inner_function
self.assertEqual(200, res.status_int)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, 
in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, 
in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 200 != 400


Captured pythonlogging:
~~~
2017-01-18 08:45:13,158 INFO [nova.api.openstack] Loaded extensions: 
['test-basic', 'test-microversions']


nova.tests.unit.api.openstack.compute.test_microversions.MicroversionsTest.test_microversions_inner_function_v22


Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
299, in test_microversions_inner_function_v22
self._test_microversions_inner_function('2.2', 'controller4_val2')
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in 
patched
return func(*args, **keywargs)
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
291, in _test_microversions_inner_function
self.assertEqual(200, res.status_int)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, 
in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, 
in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 200 != 400


Captured pythonlogging:
~~~
2017-01-18 08:45:13,842 INFO [nova.api.openstack] Loaded extensions: 
['test-basic', 'test-microversions']


nova.tests.unit.api.openstack.compute.test_microversions.LegacyMicroversionsTest.test_microversions_inner_function_v22
--

Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
299, in test_microversions_inner_function_v22
self._test_microversions_inner_function('2.2', 'controller4_val2')
  File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in 
patched
return func(*args, **keywargs)
  File "nova/tests/unit/api/openstack/compute/test_microversions.py", line 
291, in _test_microversions_inner_function
self.assertEqual(200, res.status_int)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, 
in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, 
in assertThat
raise 

[Yahoo-eng-team] [Bug 1657452] Re: Incompatibility with python-webob 1.7.0

[Corey Bryant]

glance failures with webob 1.7.0:

glance.tests.unit.common.test_wsgi.JSONRequestDeserializerTest.test_has_body_valid_transfer_encoding_with_content_length


Captured traceback:
~~~
Traceback (most recent call last):
  File "glance/tests/unit/common/test_wsgi.py", line 515, in 
test_has_body_valid_transfer_encoding_with_content_length
transfer_encoding='chunked', content_length=0))
  File "/usr/lib/python2.7/dist-packages/unittest2/case.py", line 702, in 
assertTrue
raise self.failureException(msg)
AssertionError: False is not true


glance.tests.unit.v1.test_api.TestGlanceAPI.test_add_image_wrong_content_type
-

Captured traceback:
~~~
Traceback (most recent call last):
  File "glance/tests/unit/v1/test_api.py", line 2301, in 
test_add_image_wrong_content_type
self.assertEqual(http_client.BAD_REQUEST, res.status_int)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 350, 
in assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 435, 
in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 400 != 201



** Changed in: glance (Ubuntu)
   Status: New => Confirmed

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

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

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

** Changed in: glance (Ubuntu)
   Importance: Undecided => High

** Changed in: keystone (Ubuntu)
   Importance: Undecided => High

** Changed in: keystone (Ubuntu)
   Status: New => Confirmed

** Changed in: keystone (Ubuntu)
   Status: Confirmed => Triaged

** Changed in: glance (Ubuntu)
   Status: Confirmed => Triaged

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

Title:
  Incompatibility with python-webob 1.7.0

Status in Glance:
  Confirmed
Status in OpenStack Identity (keystone):
  Confirmed
Status in glance package in Ubuntu:
  Triaged
Status in keystone package in Ubuntu:
  Triaged

Bug description:
  
  
keystone.tests.unit.test_v3_federation.WebSSOTests.test_identity_provider_specific_federated_authentication
  
---

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "keystone/tests/unit/test_v3_federation.py", line 4067, in 
test_identity_provider_specific_federated_authentication
  self.PROTOCOL)
File "keystone/federation/controllers.py", line 345, in 
federated_idp_specific_sso_auth
  return self.render_html_response(host, token_id)
File "keystone/federation/controllers.py", line 357, in 
render_html_response
  headerlist=headers)
File "/usr/lib/python2.7/dist-packages/webob/response.py", line 310, in 
__init__
  "You cannot set the body to a text value without a "
  TypeError: You cannot set the body to a text value without a charset

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1657452/+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 1657476] [NEW] Metadata agent fails to serve requests in python 3

[Oleg Bondarev]

Public bug reported:

from http://logs.openstack.org/09/421209/7/experimental/gate-tempest-
dsvm-nova-py35-ubuntu-xenial/2dda79b/logs/screen-q-meta.txt.gz:

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/eventlet/greenpool.py", line 82, 
in _spawn_n_impl
func(*args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/eventlet/wsgi.py", line 719, in 
process_request
proto.__init__(sock, address, self)
  File "/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 409, in 
__init__
server)
  File "/usr/lib/python3.5/socketserver.py", line 681, in __init__
self.handle()
  File "/usr/lib/python3.5/http/server.py", line 422, in handle
self.handle_one_request()
  File "/usr/local/lib/python3.5/dist-packages/eventlet/wsgi.py", line 379, in 
handle_one_request
self.environ = self.get_environ()
  File "/usr/local/lib/python3.5/dist-packages/eventlet/wsgi.py", line 593, in 
get_environ
env['REMOTE_ADDR'] = self.client_address[0]
IndexError: index out of range

** Affects: neutron
 Importance: High
 Assignee: Oleg Bondarev (obondarev)
 Status: Confirmed


** Tags: py34

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

Title:
  Metadata agent fails to serve requests in python 3

Status in neutron:
  Confirmed

Bug description:
  from http://logs.openstack.org/09/421209/7/experimental/gate-tempest-
  dsvm-nova-py35-ubuntu-xenial/2dda79b/logs/screen-q-meta.txt.gz:

  Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/eventlet/greenpool.py", line 
82, in _spawn_n_impl
  func(*args, **kwargs)
File "/usr/local/lib/python3.5/dist-packages/eventlet/wsgi.py", line 719, 
in process_request
  proto.__init__(sock, address, self)
File "/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 409, in 
__init__
  server)
File "/usr/lib/python3.5/socketserver.py", line 681, in __init__
  self.handle()
File "/usr/lib/python3.5/http/server.py", line 422, in handle
  self.handle_one_request()
File "/usr/local/lib/python3.5/dist-packages/eventlet/wsgi.py", line 379, 
in handle_one_request
  self.environ = self.get_environ()
File "/usr/local/lib/python3.5/dist-packages/eventlet/wsgi.py", line 593, 
in get_environ
  env['REMOTE_ADDR'] = self.client_address[0]
  IndexError: index out of range

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657476/+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 1657452] Re: Incompatibility with python-webob 1.7.0

[Corey Bryant]

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

Title:
  Incompatibility with python-webob 1.7.0

Status in OpenStack Identity (keystone):
  Confirmed
Status in glance package in Ubuntu:
  New

Bug description:
  
  
keystone.tests.unit.test_v3_federation.WebSSOTests.test_identity_provider_specific_federated_authentication
  
---

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "keystone/tests/unit/test_v3_federation.py", line 4067, in 
test_identity_provider_specific_federated_authentication
  self.PROTOCOL)
File "keystone/federation/controllers.py", line 345, in 
federated_idp_specific_sso_auth
  return self.render_html_response(host, token_id)
File "keystone/federation/controllers.py", line 357, in 
render_html_response
  headerlist=headers)
File "/usr/lib/python2.7/dist-packages/webob/response.py", line 310, in 
__init__
  "You cannot set the body to a text value without a "
  TypeError: You cannot set the body to a text value without a charset

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1657452/+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 1657467] [NEW] placement: unable to refresh compute resource provider record

[Emilien Macchi]

Public bug reported:

Deploying Nova Placement API used to work a few days ago in TripleO and
Puppet OpenStack CIs but not anymore.

"Unable to refresh my resource provider record"

nova-compute log files:
http://logs.openstack.org/66/421366/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/f138bcc/logs/nova/nova-compute.txt.gz#_2017-01-17_17_32_39_092

nova.conf:
https://paste.fedoraproject.org/529703/14847479/

** Affects: nova
 Importance: Undecided
 Status: New

** Affects: tripleo
 Importance: High
 Status: Triaged

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

** Changed in: tripleo
   Status: New => Triaged

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

** Changed in: tripleo
Milestone: None => ocata-rc1

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

Title:
  placement: unable to refresh  compute resource provider record

Status in OpenStack Compute (nova):
  New
Status in tripleo:
  Triaged

Bug description:
  Deploying Nova Placement API used to work a few days ago in TripleO
  and Puppet OpenStack CIs but not anymore.

  "Unable to refresh my resource provider record"

  nova-compute log files:
  
http://logs.openstack.org/66/421366/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/f138bcc/logs/nova/nova-compute.txt.gz#_2017-01-17_17_32_39_092

  nova.conf:
  https://paste.fedoraproject.org/529703/14847479/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1657467/+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 1657459] [NEW] WebOb>=1.2.3 requirement for Glance will lead to 0 bytes backing image files on OpenStack Newton, although the image file sent to the python client does not have 0

[Adrian Vladu]

Public bug reported:

On CentOS 7 AIO Newton OpenStack deployed with packstack, the default
WebOb glance requirement was >= 1.2.3 and pip installed the 1.7.0
version.

When I created a glance image from the cli, using the filesystem backend
as default, with a raw file of 1GB, the glance image-create command
showed that a image was created, but with the size of 0 bytes.

After forcing with pip the WebOb==1.2.3 version, the issue was not
longer there.

I have tried with python 2.7 and 3.4 and to upload the image via horizon
or with different python-glance client versions => when WebOb version
was 1.7.0 the outcome was wrong, as I ended up with a 0 bytes image in
the backing store.

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  WebOb>=1.2.3 requirement for Glance will  lead to 0 bytes backing
  image files on OpenStack Newton, although the image file sent to the
  python client does not have 0 bytes

Status in Glance:
  New

Bug description:
  On CentOS 7 AIO Newton OpenStack deployed with packstack, the default
  WebOb glance requirement was >= 1.2.3 and pip installed the 1.7.0
  version.

  When I created a glance image from the cli, using the filesystem
  backend as default, with a raw file of 1GB, the glance image-create
  command showed that a image was created, but with the size of 0 bytes.

  After forcing with pip the WebOb==1.2.3 version, the issue was not
  longer there.

  I have tried with python 2.7 and 3.4 and to upload the image via
  horizon or with different python-glance client versions => when WebOb
  version was 1.7.0 the outcome was wrong, as I ended up with a 0 bytes
  image in the backing store.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1657459/+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 1657454] [NEW] use safer method splitlines() to replace split('\n')

[liao...@hotmail.com]

Public bug reported:

user may copy/paste content from a txt file created in Windows, line
breaks are different, splitlines() method is better and safer than
split('\n')

** Affects: horizon
 Importance: Undecided
 Assignee: liao...@hotmail.com (liaozd)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => liao...@hotmail.com (liaozd)

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

Title:
  use safer method splitlines() to replace split('\n')

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  user may copy/paste content from a txt file created in Windows, line
  breaks are different, splitlines() method is better and safer than
  split('\n')

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1657454/+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 1657452] [NEW] Incompatibility with python-webob 1.7.1

[Chuck Short]

Public bug reported:


keystone.tests.unit.test_v3_federation.WebSSOTests.test_identity_provider_specific_federated_authentication
---

Captured traceback:
~~~
Traceback (most recent call last):
  File "keystone/tests/unit/test_v3_federation.py", line 4067, in 
test_identity_provider_specific_federated_authentication
self.PROTOCOL)
  File "keystone/federation/controllers.py", line 345, in 
federated_idp_specific_sso_auth
return self.render_html_response(host, token_id)
  File "keystone/federation/controllers.py", line 357, in 
render_html_response
headerlist=headers)
  File "/usr/lib/python2.7/dist-packages/webob/response.py", line 310, in 
__init__
"You cannot set the body to a text value without a "
TypeError: You cannot set the body to a text value without a charset

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

Title:
  Incompatibility with python-webob 1.7.1

Status in OpenStack Identity (keystone):
  New

Bug description:
  
  
keystone.tests.unit.test_v3_federation.WebSSOTests.test_identity_provider_specific_federated_authentication
  
---

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "keystone/tests/unit/test_v3_federation.py", line 4067, in 
test_identity_provider_specific_federated_authentication
  self.PROTOCOL)
File "keystone/federation/controllers.py", line 345, in 
federated_idp_specific_sso_auth
  return self.render_html_response(host, token_id)
File "keystone/federation/controllers.py", line 357, in 
render_html_response
  headerlist=headers)
File "/usr/lib/python2.7/dist-packages/webob/response.py", line 310, in 
__init__
  "You cannot set the body to a text value without a "
  TypeError: You cannot set the body to a text value without a charset

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1657452/+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 1657450] [NEW] a wrong indentation in openstack_dashboard/api/base.py:206

[liao...@hotmail.com]

Public bug reported:

a wrong indentation in openstack_dashboard/api/base.py:206

** Affects: horizon
 Importance: Undecided
 Assignee: liao...@hotmail.com (liaozd)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => liao...@hotmail.com (liaozd)

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

Title:
  a wrong indentation in openstack_dashboard/api/base.py:206

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  a wrong indentation in openstack_dashboard/api/base.py:206

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1657450/+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 1657446] [NEW] Wrong timestamps in /var/log/cloud-init.log

[Junien Fridrick]

Public bug reported:

Hi,

The timestamps displayed in /var/log/cloud-init.log are different from
the timestamps displayed in "journactl -u cloud-init".

For example :

$ head -n1 /var/log/cloud-init.log ; tail -n 1 /var/log/cloud-init.log
Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8 running 
'init-local' at Tue, 17 Jan 2017 23:22:36 +. Up 6.24 seconds.
Jan 17 23:23:01 foo [CLOUDINIT] handlers.py[DEBUG]: finish: modules-final: 
SUCCESS: running modules for final

Here, by looking at the timestamp at the beginning of the 2 lines, you
could believe that cloud-init took 3 seconds to complete.

However, there are several pieces of information that contradicts this.

First, there is a discrepancy in the first line pasted above : the first
timestamp says "Jan 17 23:22:58" but on the same line, you also have "at
Tue, 17 Jan 2017 23:22:36 +."

Then, there is the console log (this is an OpenStack VM), which shows :

cloud-init[1050]: Cloud-init v. 0.7.8 running 'init' at Tue, 17 Jan 2017 
23:22:38 +. Up 7.55 seconds.
[...]
cloud-init[1690]: Cloud-init v. 0.7.8 running 'modules:final' at Tue, 17 Jan 
2017 23:23:00 +. Up 30.32 seconds.

which hints that the run took ~23 seconds.

Then, there are the various "duration" messages in /var/log/cloud-init.log :
$ grep ' took ' /var/log/cloud-init.log
Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'init' took 
0.530 seconds (0.53)
Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Crawl of openstack metadata 
service took 18.093 seconds
Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: resize_devices took 0.082 
seconds
Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Resizing took 0.048 seconds
Jan 17 23:23:00 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' took 
1.764 seconds (1.77)
Jan 17 23:23:01 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' took 
0.240 seconds (0.24)

The metadata discovery alone took 18s !

And finally, it looks like the proper information is produced by "journactl -u 
cloud-init" :
$ journalctl -u cloud-init |head -n2
-- Logs begin at Tue 2017-01-17 23:22:35 UTC, end at Wed 2017-01-18 12:28:22 
UTC. --
Jan 17 23:22:37 ubuntu systemd[1]: Starting Initial cloud-init job (metadata 
service crawler)...

$ journalctl -u cloud-init |tail -n1
Jan 17 23:22:57 foo systemd[1]: Started Initial cloud-init job (metadata 
service crawler).


Could we please get the correct timestamps in /var/log/cloud-init.log ?

Thanks

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

Title:
  Wrong timestamps in /var/log/cloud-init.log

Status in cloud-init:
  New

Bug description:
  Hi,

  The timestamps displayed in /var/log/cloud-init.log are different from
  the timestamps displayed in "journactl -u cloud-init".

  For example :

  $ head -n1 /var/log/cloud-init.log ; tail -n 1 /var/log/cloud-init.log
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8 running 
'init-local' at Tue, 17 Jan 2017 23:22:36 +. Up 6.24 seconds.
  Jan 17 23:23:01 foo [CLOUDINIT] handlers.py[DEBUG]: finish: modules-final: 
SUCCESS: running modules for final

  Here, by looking at the timestamp at the beginning of the 2 lines, you
  could believe that cloud-init took 3 seconds to complete.

  However, there are several pieces of information that contradicts
  this.

  First, there is a discrepancy in the first line pasted above : the
  first timestamp says "Jan 17 23:22:58" but on the same line, you also
  have "at Tue, 17 Jan 2017 23:22:36 +."

  Then, there is the console log (this is an OpenStack VM), which shows
  :

  cloud-init[1050]: Cloud-init v. 0.7.8 running 'init' at Tue, 17 Jan 2017 
23:22:38 +. Up 7.55 seconds.
  [...]
  cloud-init[1690]: Cloud-init v. 0.7.8 running 'modules:final' at Tue, 17 Jan 
2017 23:23:00 +. Up 30.32 seconds.

  which hints that the run took ~23 seconds.

  Then, there are the various "duration" messages in /var/log/cloud-init.log :
  $ grep ' took ' /var/log/cloud-init.log
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'init' took 
0.530 seconds (0.53)
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Crawl of openstack metadata 
service took 18.093 seconds
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: resize_devices took 0.082 
seconds
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Resizing took 0.048 seconds
  Jan 17 23:23:00 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' 
took 1.764 seconds (1.77)
  Jan 17 23:23:01 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' 
took 0.240 seconds (0.24)

  The metadata discovery alone took 18s !

  And finally, it looks like the proper information is produced by "journactl 
-u cloud-init" :
  $ journalctl -u cloud-init |head -n2
  -- Logs begin at Tue 2017-01-17 23:22:35 UTC, end at Wed 

[Yahoo-eng-team] [Bug 1657441] [NEW] Remove the set device_owner when attaching subports

[Luis Tomas Bolivar]

Public bug reported:

This is not required by business logic as pointed out in the commit
message of https://review.openstack.org/#/c/368289/, and in some
cases can lead to race problems.

There may be other proyects using neutron TrunkPorts, such as kuryr,
that can trigger the port/subport creation, therefore wanting to use
the device_owner to specify that kuryr-service is the one managing
those subports.

To give an example of the possible race, as the trunk_add_subport
internally calls update_port to set the device owner, it may happen that
a call from kuryr that wants to attach a subport to a port, and then set
the device_owner to kuryr, end up with the wrong device_owner as, 
even though the calls are triggered in this order:
1.- trunk_add_subport (internally calls update_port)
2.- update_port

The update_port is executed between trunk_add_subport and the internal call to
update_port, resulting in device_owner being set to trunk:subport, instead of
kuryr.

Possible solutions are:
- Revert the commit https://review.openstack.org/#/c/368289/. We have already 
have some discussion about this in the patch 
https://review.openstack.org/#/c/419028/
- Make the set device_owner optional based on the value of TRUNK_SUBPORT_OWNER
- Define what should be the scope of device_owner to clarify how this attribute
should be used within/outside neutron

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

Title:
  Remove the set device_owner when attaching subports

Status in neutron:
  New

Bug description:
  This is not required by business logic as pointed out in the commit
  message of https://review.openstack.org/#/c/368289/, and in some
  cases can lead to race problems.

  There may be other proyects using neutron TrunkPorts, such as kuryr,
  that can trigger the port/subport creation, therefore wanting to use
  the device_owner to specify that kuryr-service is the one managing
  those subports.

  To give an example of the possible race, as the trunk_add_subport
  internally calls update_port to set the device owner, it may happen that
  a call from kuryr that wants to attach a subport to a port, and then set
  the device_owner to kuryr, end up with the wrong device_owner as, 
  even though the calls are triggered in this order:
  1.- trunk_add_subport (internally calls update_port)
  2.- update_port

  The update_port is executed between trunk_add_subport and the internal call to
  update_port, resulting in device_owner being set to trunk:subport, instead of
  kuryr.

  Possible solutions are:
  - Revert the commit https://review.openstack.org/#/c/368289/. We have already 
  have some discussion about this in the patch 
https://review.openstack.org/#/c/419028/
  - Make the set device_owner optional based on the value of TRUNK_SUBPORT_OWNER
  - Define what should be the scope of device_owner to clarify how this 
attribute
  should be used within/outside neutron

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657441/+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 1657428] [NEW] Nova sends notifications with different timestamp formats

[Nadya Privalova]

Public bug reported:

Nova sends metadata about instances with different timestamp formats.
Example:

Notification is:

[{"meters":{"instance":{"type":"gauge","unit":"instance"}},"source":"openstack","metadata":{"launched_at":"20
17-01-16T09:00:15.00","progress":"","host":"compute.node-2.domain.tld","bandwidth":{},"kernel_id":"","ramdisk_id":"","disk_gb":1,"memory_mb":512,"created_at":"2017-0
1-16 
09:00:00+00:00","cell_name":"","state":"active","state_description":"","tenant_id":"c99e47b77866411a9819823ddfc98751","root_gb":1,"terminated_at":"","user_id":"2707
ffeac90949cbbd9fe809da63b60b","audit_period_beginning":"2017-01-17 
07:00:00","image_ref_url":"http://10.21.2.9:9292/images/33350a42-3c6e-41b4-b449-8c180599f57b","deleted
_at":"","audit_period_ending":"2017-01-17 08:00:00"

Different formats are detected in the following fields:

"launched_at":"2017-01-16T09:00:15.00"
"created_at":"2017-01-16 09:00:00+00:00"
"audit_period_beginning":"2017-01-17 07:00:00"
"audit_period_ending":"2017-01-17 08:00:00"

Because of this inconsistency, we cannot insert this data in ElasticSearch 
without additional processing. The following error occurs:
IllegalArgumentException[Invalid format: "2017-01-16 09:00:00+00:00" is 
malformed at " 09:00:00+00:00"];
at 
org.elasticsearch.index.mapper.FieldMapper.parse(FieldMapper.java:329)
at 
org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:309)
at 
org.elasticsearch.index.mapper.DocumentParser.parseValue(DocumentParser.java:436)
at 
org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:262)
at 
org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:306)
at 
org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:326)
 .

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

Title:
  Nova sends notifications with different timestamp formats

Status in OpenStack Compute (nova):
  New

Bug description:
  Nova sends metadata about instances with different timestamp formats.
  Example:

  Notification is:

  
[{"meters":{"instance":{"type":"gauge","unit":"instance"}},"source":"openstack","metadata":{"launched_at":"20
  
17-01-16T09:00:15.00","progress":"","host":"compute.node-2.domain.tld","bandwidth":{},"kernel_id":"","ramdisk_id":"","disk_gb":1,"memory_mb":512,"created_at":"2017-0
  1-16 
09:00:00+00:00","cell_name":"","state":"active","state_description":"","tenant_id":"c99e47b77866411a9819823ddfc98751","root_gb":1,"terminated_at":"","user_id":"2707
  ffeac90949cbbd9fe809da63b60b","audit_period_beginning":"2017-01-17 
07:00:00","image_ref_url":"http://10.21.2.9:9292/images/33350a42-3c6e-41b4-b449-8c180599f57b","deleted
  _at":"","audit_period_ending":"2017-01-17 08:00:00"

  Different formats are detected in the following fields:

  "launched_at":"2017-01-16T09:00:15.00"
  "created_at":"2017-01-16 09:00:00+00:00"
  "audit_period_beginning":"2017-01-17 07:00:00"
  "audit_period_ending":"2017-01-17 08:00:00"

  Because of this inconsistency, we cannot insert this data in ElasticSearch 
without additional processing. The following error occurs:
  IllegalArgumentException[Invalid format: "2017-01-16 09:00:00+00:00" is 
malformed at " 09:00:00+00:00"];
  at 
org.elasticsearch.index.mapper.FieldMapper.parse(FieldMapper.java:329)
  at 
org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:309)
  at 
org.elasticsearch.index.mapper.DocumentParser.parseValue(DocumentParser.java:436)
  at 
org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:262)
  at 
org.elasticsearch.index.mapper.DocumentParser.parseObjectOrField(DocumentParser.java:306)
  at 
org.elasticsearch.index.mapper.DocumentParser.parseObject(DocumentParser.java:326)
 .

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1657428/+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 1657423] [NEW] Instances view in Dashboard spawns "Error: Unable to retrieve instance list."

[Željko Jagušt]

Public bug reported:

I'm running Mitaka on Ubuntu 16.04 and when I try to access Instances
list in Dashboard, the following is error is spawned: Error: Unable to
retrieve instance list. Same error is spawned for all users.

Same thing happens in CLI:
nova list --all-tenants
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-30134c69-6c89-4437-9fd7-a2ca7b169ed7)

Debug output of the same command from above:
nova --debug list --all-tenants
DEBUG (extension:157) found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
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('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcpassword = 
keystoneauth1.loading._plugins.identity.v3:OpenIDConnectPassword')
DEBUG (extension:157) found extension EntryPoint.parse('token = 
keystoneauth1.loading._plugins.identity.generic:Token')
DEBUG (extension:157) found extension EntryPoint.parse('v3token = 
keystoneauth1.loading._plugins.identity.v3:Token')
DEBUG (extension:157) found extension EntryPoint.parse('password = 
keystoneauth1.loading._plugins.identity.generic:Password')
DEBUG (session:248) REQ: curl -g -i -X GET http://10.0.0.1:35357/v3 -H "Accept: 
application/json" -H "User-Agent: keystoneauth1/2.4.1 python-requests/2.9.1 
CPython/2.7.12"
INFO (connectionpool:208) Starting new HTTP connection (1): 10.0.0.1
DEBUG (connectionpool:388) "GET /v3 HTTP/1.1" 200 248
DEBUG (session:277) RESP: [200] Content-Length: 248 Vary: X-Auth-Token Server: 
Apache/2.4.18 (Ubuntu) Date: Wed, 18 Jan 2017 11:25:28 GMT 
x-openstack-request-id: req-43f828d7-4919-4d24-acbf-513c1b7fa496 Content-Type: 
application/json X-Distribution: Ubuntu 
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://10.0.0.1:35357/v3/;, "rel": "self"}]}}

DEBUG (base:165) Making authentication request to 
http://10.0.0.1:35357/v3/auth/tokens
DEBUG (connectionpool:388) "POST /v3/auth/tokens HTTP/1.1" 201 7476
DEBUG (session:248) REQ: curl -g -i -X GET 
http://10.0.0.1:8774/v2.1/b77576d7ea0c45a3a24a8da20dbe983e -H "User-Agent: 
python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}c3bd40d9088aa0e9755d065fa91cea9d5736b361"
INFO (connectionpool:208) Starting new HTTP connection (1): 10.0.0.1
DEBUG (connectionpool:388) "GET /v2.1/b77576d7ea0c45a3a24a8da20dbe983e 
HTTP/1.1" 404 52
DEBUG (session:277) RESP: [404] Date: Wed, 18 Jan 2017 11:25:33 GMT 
Content-Length: 52 Content-Type: text/plain; charset=UTF-8 
X-Compute-Request-Id: req-06891843-9fe6-432f-b038-2191efd401b0 
RESP BODY: 404 Not Found

The resource could not be found.


DEBUG (session:248) REQ: curl -g -i -X GET http://10.0.0.1:8774/v2.1/ -H 
"User-Agent: python-novaclient" -H "Accept: application/json" -H "X-Auth-Token: 
{SHA1}c3bd40d9088aa0e9755d065fa91cea9d5736b361"
DEBUG (connectionpool:388) "GET /v2.1/ HTTP/1.1" 200 382
DEBUG (session:277) RESP: [200] Content-Length: 382 X-Compute-Request-Id: 
req-732fd6ce-57b0-4858-9740-4bbd9899de6a Vary: X-OpenStack-Nova-API-Version 
X-Openstack-Nova-Api-Version: 2.1 Date: Wed, 18 Jan 2017 11:25:33 GMT 
Content-Type: application/json 
RESP BODY: {"version": {"status": "CURRENT", "updated": "2013-07-23T11:33:21Z", 
"links": [{"href": "http://10.0.0.1:8774/v2.1/;, "rel": "self"}, {"href": 
"http://docs.openstack.org/;, "type": "text/html", "rel": "describedby"}], 
"min_version": "2.1", "version": "2.25", "media-types": [{"base": 
"application/json", "type": 
"application/vnd.openstack.compute+json;version=2.1"}], "id": "v2.1"}}

DEBUG (extension:157) found extension EntryPoint.parse('v2token = 
keystoneauth1.loading._plugins.identity.v2:Token')
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('v3password = 
keystoneauth1.loading._plugins.identity.v3:Password')
DEBUG (extension:157) found extension EntryPoint.parse('v3oidcpassword = 

[Yahoo-eng-team] [Bug 1657424] [NEW] Hyper-V: Instance ports not bound after resize

[Lucian Petrut]

Public bug reported:

When using OVS, the Hyper-V driver creates the OVS ports only after the
instance is powered on (due to a Hyper-V limitation).

The issue is that in case of cold migrations/resize, this step is currently 
skipped, as the driver doesn't pass the network info object when powering on 
the instance:
https://github.com/openstack/nova/blob/07b6580a1648a860eefb5a949cb443c2a335a89a/nova/virt/hyperv/migrationops.py#L300-L301

Simply passing that object will fix the issue.

** Affects: compute-hyperv
 Importance: Undecided
 Status: New

** Affects: nova
 Importance: Undecided
 Status: New

** Also affects: compute-hyperv
   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/1657424

Title:
  Hyper-V: Instance ports not bound after resize

Status in compute-hyperv:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  When using OVS, the Hyper-V driver creates the OVS ports only after
  the instance is powered on (due to a Hyper-V limitation).

  The issue is that in case of cold migrations/resize, this step is currently 
skipped, as the driver doesn't pass the network info object when powering on 
the instance:
  
https://github.com/openstack/nova/blob/07b6580a1648a860eefb5a949cb443c2a335a89a/nova/virt/hyperv/migrationops.py#L300-L301

  Simply passing that object will fix the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/compute-hyperv/+bug/1657424/+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 1657412] [NEW] L3_NAT_dbonly_mixin __new__ method has wrong signature

[Wim De Clercq]

Public bug reported:

Since stable/newton, there is this code: 
https://github.com/openstack/neutron/blob/stable/newton/neutron/db/l3_db.py#L173
master link: 
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L95

Python doc says: 
https://docs.python.org/2/reference/datamodel.html#object.__new__
"...that takes the class of which an instance was requested as its first 
argument. The remaining arguments are those passed to the object constructor 
expression..."

Because the __new__ method is overridden in L3_NAT_dbonly_mixin without
accepting extra arguments. This forces all subclasses to have either no
arguments to the __init__ method, or they have to override __new__
themselves to workaround this.

The following code fails to run:
  from neutron.db import l3_db


  class Test(l3_db.L3_NAT_dbonly_mixin):

  def __init__(self, arg1):
  super(Test, self).__init__()
  self.arg1 = arg1

  Test(1)


The, hacky imo, workaround:
  from neutron.db import l3_db


  class Test(l3_db.L3_NAT_dbonly_mixin):

  @staticmethod
  def __new__(cls, *more):
  return super(Test, cls).__new__(cls)

  def __init__(self, arg1):
  super(Test, self).__init__()
  self.arg1 = arg1

  Test(1)

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

Title:
  L3_NAT_dbonly_mixin __new__ method has wrong signature

Status in neutron:
  New

Bug description:
  Since stable/newton, there is this code: 
https://github.com/openstack/neutron/blob/stable/newton/neutron/db/l3_db.py#L173
  master link: 
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L95

  Python doc says: 
https://docs.python.org/2/reference/datamodel.html#object.__new__
  "...that takes the class of which an instance was requested as its first 
argument. The remaining arguments are those passed to the object constructor 
expression..."

  Because the __new__ method is overridden in L3_NAT_dbonly_mixin
  without accepting extra arguments. This forces all subclasses to have
  either no arguments to the __init__ method, or they have to override
  __new__ themselves to workaround this.

  The following code fails to run:
from neutron.db import l3_db

  
class Test(l3_db.L3_NAT_dbonly_mixin):

def __init__(self, arg1):
super(Test, self).__init__()
self.arg1 = arg1

Test(1)

  
  The, hacky imo, workaround:
from neutron.db import l3_db

  
class Test(l3_db.L3_NAT_dbonly_mixin):

@staticmethod
def __new__(cls, *more):
return super(Test, cls).__new__(cls)

def __init__(self, arg1):
super(Test, self).__init__()
self.arg1 = arg1

Test(1)

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657412/+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 1657210] Re: Remove deprecated min_l3_agents_per_router

[John Davidge]

Can't see any references in the neutron tree, but there are some to be
changed in the networking guide.

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

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

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

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

** Tags added: networking-guide

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

Title:
  Remove deprecated min_l3_agents_per_router

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

Bug description:
  https://review.openstack.org/385604
  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 dd5aca38f90e1b387837c555e110d825062bfb5a
  Author: Assaf Muller 
  Date:   Wed Oct 12 15:32:45 2016 -0400

  Remove deprecated min_l3_agents_per_router
  
  The option was deprecated [1] for removal in Newton
  and is being removed in Ocata.
  
  [1] Deprecated in patch with Gerrit Change-Id of:
  I8a5fc74a96c784d474aefe2d9b27eeb66521ca82
  
  DocImpact remove all references to the option.
  
  Change-Id: I3a9195ff6fd18fad9f85cec03a632e7e52d954e7
  Closes-Bug: #1555042

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657210/+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 1657364] Re: net has a subnet which cidr in subnetpool, and then create another subnet with cidr not in subnetpool failed

[John Davidge]

This is working as expected, as explained in the error message you
posted:

"Subnets hosted on the same network must be allocated from the same
subnet pool."

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

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

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

Title:
  net has a subnet which cidr in subnetpool, and  then create another
  subnet with cidr not in subnetpool failed

Status in neutron:
  Invalid

Bug description:
  For branch master

  1. I hava a net and a subnetpool:
    [root@devstack178 devstack]# neutron net-create poolnet
  Created a new network:
  +---+--+
  | Field | Value|
  +---+--+
  | admin_state_up| True |
  | availability_zone_hints   |  |
  | availability_zones|  |
  | created_at| 2017-01-18T16:14:10Z |
  | description   |  |
  | id| ce04f4db-22e3-4ba4-9f64-686e57c2d633 |
  | ipv4_address_scope|  |
  | ipv6_address_scope|  |
  | mtu   | 1450 |
  | name  | poolnet  |
  | port_security_enabled | True |
  | project_id| db0c096ae736499b84b08ef06106b138 |
  | provider:network_type | vxlan|
  | provider:physical_network |  |
  | provider:segmentation_id  | 68   |
  | revision_number   | 3|
  | router:external   | False|
  | shared| False|
  | status| ACTIVE   |
  | subnets   |  |
  | tags  |  |
  | tenant_id | db0c096ae736499b84b08ef06106b138 |
  | updated_at| 2017-01-18T16:14:10Z |
  +---+--+

  [root@devstack178 devstack]# neutron  subnetpool-create  addresspool25  
--pool-prefix 25.0.0.0/8 --default-prefixlen 24
  Created a new subnetpool:
  +---+--+
  | Field | Value|
  +---+--+
  | address_scope_id  |  |
  | created_at| 2017-01-18T16:16:23Z |
  | default_prefixlen | 24   |
  | default_quota |  |
  | description   |  |
  | id| c84855bb-bf76-4ed5-b213-9ec4bac20077 |
  | ip_version| 4|
  | is_default| False|
  | max_prefixlen | 32   |
  | min_prefixlen | 8|
  | name  | addresspool25|
  | prefixes  | 25.0.0.0/8   |
  | project_id| db0c096ae736499b84b08ef06106b138 |
  | revision_number   | 1|
  | shared| False|
  | tenant_id | db0c096ae736499b84b08ef06106b138 |
  | updated_at| 2017-01-18T16:16:23Z |
  +---+--+

  2. creat a subnet which cidr in subnetpool
  [root@devstack178 devstack]# neutron subnet-create poolnet  --subnetpool 
addresspool25
  Created a new subnet:
  +---++
  | Field | Value  |
  +---++
  | allocation_pools  | {"start": "25.0.0.2", "end": "25.0.0.254"} |
  | cidr  | 25.0.0.0/24|
  | created_at| 2017-01-18T16:17:54Z   |
  | description   ||
  | dns_nameservers   ||
  | enable_dhcp   | True   |
  | gateway_ip| 25.0.0.1 

[Yahoo-eng-team] [Bug 1608934] Re: ephemeral/swap disk creation fails for local storage with image type raw/lvm

[James Page]

Marking liberty task as done as nova is now in -updates.

** Changed in: cloud-archive/liberty
   Status: Fix Committed => 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/1608934

Title:
  ephemeral/swap disk creation fails for local storage with image type
  raw/lvm

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive liberty series:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in Ubuntu Cloud Archive newton series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) mitaka series:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in nova source package in Xenial:
  Fix Released

Bug description:
  Description
  ===
  I am currently trying to launch an instance in my mitaka cluster with a 
flavor with ephemeral and root storage. Whenever i am trying to start the 
instance i am running into an "DiskNotFound" Error (see trace below). Starting 
instances without ephemeral works perfectly fine and the root disk is created 
as expected in /var/lib/nova/instance/$INSTANCEID/disk .

  Steps to reproduce
  ==
  1. Create a flavor with ephemeral and root storage.
  2. Start an instance with that flavor.

  Expected result
  ===
  Instance starts and ephemeral disk is created in 
/var/lib/nova/instances/$INSTANCEID/disk.eph0 or disk.local ? (Not sure where 
the switchase for the naming is)

  Actual result
  =
  Instance does not start, ephemeral disk seems to be created at 
/var/lib/nova/instances/$INSTANCEID/disk.eph0, but nova checks 
/var/lib/nova/instances/_base/ephemeral_* for disk_size

  TRACE: http://pastebin.com/raw/TwtiNLY2

  Environment
  ===
  I am running OpenStack mitaka on Ubuntu 16.04 in the latest version with 
Libvirt + KVM as hypervisor (also latest stable in xenial).

  Config
  ==

  nova.conf:

  ...
  [libvirt]
  images_type = raw
  rbd_secret_uuid = XXX
  virt_type = kvm
  inject_key = true
  snapshot_image_format = raw
  disk_cachemodes = "network=writeback"
  rng_dev_path = /dev/random
  rbd_user = cinder
  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1608934/+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 1657381] [NEW] QoS drivers need to implement a precommit for the actions

[Miguel Angel Ajo]

Public bug reported:

Some backends like ODL use a logging and sync mechanism that would
benefit from exposing a precommit for all the exposed driver actions.

We should implement a create_policy_precommit, update_policy_precommit,
delete_policy_precommit.

** Affects: neutron
 Importance: Medium
 Assignee: Miguel Angel Ajo (mangelajo)
 Status: In Progress


** Tags: qos

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

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

** Changed in: neutron
Milestone: None => ocata-3

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

Title:
  QoS drivers need to implement a precommit for the actions

Status in neutron:
  In Progress

Bug description:
  Some backends like ODL use a logging and sync mechanism that would
  benefit from exposing a precommit for all the exposed driver actions.

  We should implement a create_policy_precommit,
  update_policy_precommit, delete_policy_precommit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657381/+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 1657377] [NEW] FWaaS - message of FirewallGroupPortInvalidProject should be fixed

[Yushiro FURUKAWA]

Public bug reported:

When updating 'ports' attribute for firewall_group with admin privilege
and specified port belongs to different project, following error
occurred:

{"NeutronError": {"message": "Firewall Group 704d951e-980e-451f-bfae-
854bcc094fa7 in invalid Project", "type":
"FirewallGroupPortInvalidProject", "detail": ""}}

704d951e-980e-451f-bfae-854bcc094fa7 is not firewall group but port.
Therefore, message should be fixed like as follows:

  Specified port  in invalid Project   or
  Port  in invalid Project


[How to reproduce]
1. Create firewall_group in admin project
  source devstack/openrc admin admin
  openstack firewall group create --name fwg

2. Create router-port in demo project
  source devstack/openrc demo demo
  neutron net-create test; neutron subnet-create test 192.168.100.0/24 --name 
subnet; neutron router-create test-router; neutron router-add-interface 
test-router subnet
  neutron port-update `neutron port-list | grep 192.168.200.1 | get_field 1` 
--name target_l3

3. Update firewall_group with 'ports' attribute
  source devstack/openrc admin admin
  export TOKEN=`openstack token issue| grep ' id ' | get_field 2`
  curl -X PUT -H "x-auth-token:$TOKEN" -H "content-type:application/json" -d 
'{"firewall_group":{"ports":["704d951e-980e-451f-bfae-854bcc094fa7"]}}' 
localhost:9696/v2.0/fwaas/firewall_groups/bba0311b-db3d-4989-bfa3-3e132d719b94

Note: 704d951e-980e-451f-bfae-854bcc094fa7 is ID for port named
'target_l3'

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: fwaas

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

Title:
  FWaaS - message of FirewallGroupPortInvalidProject should be fixed

Status in neutron:
  New

Bug description:
  When updating 'ports' attribute for firewall_group with admin
  privilege and specified port belongs to different project, following
  error occurred:

  {"NeutronError": {"message": "Firewall Group 704d951e-980e-451f-bfae-
  854bcc094fa7 in invalid Project", "type":
  "FirewallGroupPortInvalidProject", "detail": ""}}

  704d951e-980e-451f-bfae-854bcc094fa7 is not firewall group but port.
  Therefore, message should be fixed like as follows:

Specified port  in invalid Project   or
Port  in invalid Project

  
  [How to reproduce]
  1. Create firewall_group in admin project
source devstack/openrc admin admin
openstack firewall group create --name fwg

  2. Create router-port in demo project
source devstack/openrc demo demo
neutron net-create test; neutron subnet-create test 192.168.100.0/24 --name 
subnet; neutron router-create test-router; neutron router-add-interface 
test-router subnet
neutron port-update `neutron port-list | grep 192.168.200.1 | get_field 1` 
--name target_l3

  3. Update firewall_group with 'ports' attribute
source devstack/openrc admin admin
export TOKEN=`openstack token issue| grep ' id ' | get_field 2`
curl -X PUT -H "x-auth-token:$TOKEN" -H "content-type:application/json" -d 
'{"firewall_group":{"ports":["704d951e-980e-451f-bfae-854bcc094fa7"]}}' 
localhost:9696/v2.0/fwaas/firewall_groups/bba0311b-db3d-4989-bfa3-3e132d719b94

  Note: 704d951e-980e-451f-bfae-854bcc094fa7 is ID for port named
  'target_l3'

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657377/+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 1657379] [NEW] Refactor the QoS "notification_drivers" into QoS drivers

[Miguel Angel Ajo]

Public bug reported:


  Beyond doing a decoupling refactor from the mechanism drivers and the core 
plugin this change will removes the need to define a notification_driver in the 
[qos] section of the neutron config file, being those drivers automatically 
exposed by the loaded mechanism drivers or the loaded core plugin.

  This is also a preliminary step to make
https://bugs.launchpad.net/neutron/+bug/1586056 ( Improved validation
mechanism for QoS rules with port types) possible.

** Affects: neutron
 Importance: Medium
 Assignee: Miguel Angel Ajo (mangelajo)
 Status: In Progress


** Tags: qos

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

** Changed in: neutron
 Assignee: (unassigned) => Miguel Angel Ajo (mangelajo)

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

** Changed in: neutron
Milestone: None => ocata-3

** Tags added: qos

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

Title:
  Refactor the QoS "notification_drivers" into QoS drivers

Status in neutron:
  In Progress

Bug description:
  
Beyond doing a decoupling refactor from the mechanism drivers and the core 
plugin this change will removes the need to define a notification_driver in the 
[qos] section of the neutron config file, being those drivers automatically 
exposed by the loaded mechanism drivers or the loaded core plugin.

This is also a preliminary step to make
  https://bugs.launchpad.net/neutron/+bug/1586056 ( Improved validation
  mechanism for QoS rules with port types) possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657379/+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 1657366] [NEW] sort_key and sort_dir combination are not being honored in correct way

[Ghanshyam Mann]

Public bug reported:

while sorting servers, user can pass sort_key and sort_dir combination
and API says:

"You can specify multiple pairs of sort key and sort direction query
parameters. If you omit the sort direction in a pair, the API uses the
natural sorting direction of the direction of the server sort_key
attribute. " - http://developer.openstack.org/api-ref/compute/?expanded
=list-servers-detail

But if any sort_dir are not being passed in between of multiple
sort_key, sort_dir combination then, it end up with having wrong mapping
sort_key and sort_dir.

API layer just prepare the list of sort_key and sort_dir and then DB
layer append remaining sort_dir as default value in list.

- 
https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L145
- https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2111

While preparing the list of sort_key and sort_dir from req query,
missing sort_dir should be added as default value so that all the way
down combination can be remembered with index.

If user pass both combination of sort_key and sort_dir then there is no
issue.

** Affects: nova
 Importance: Undecided
 Assignee: Ghanshyam Mann (ghanshyammann)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann)

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

Title:
  sort_key and sort_dir combination are not being honored in correct way

Status in OpenStack Compute (nova):
  New

Bug description:
  while sorting servers, user can pass sort_key and sort_dir combination
  and API says:

  "You can specify multiple pairs of sort key and sort direction query
  parameters. If you omit the sort direction in a pair, the API uses the
  natural sorting direction of the direction of the server sort_key
  attribute. " - http://developer.openstack.org/api-
  ref/compute/?expanded=list-servers-detail

  But if any sort_dir are not being passed in between of multiple
  sort_key, sort_dir combination then, it end up with having wrong
  mapping sort_key and sort_dir.

  API layer just prepare the list of sort_key and sort_dir and then DB
  layer append remaining sort_dir as default value in list.

  - 
https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L145
  - 
https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L2111

  While preparing the list of sort_key and sort_dir from req query,
  missing sort_dir should be added as default value so that all the way
  down combination can be remembered with index.

  If user pass both combination of sort_key and sort_dir then there is
  no issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1657366/+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 1657364] [NEW] onet net has a subnet with a cidr in subnetpool, and then create a subnet with cidr not in subnetpool fail

[QunyingRan]

Public bug reported:

For branch master

1. I hava a net and a subnetpool:
  [root@devstack178 devstack]# neutron net-create poolnet
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| availability_zone_hints   |  |
| availability_zones|  |
| created_at| 2017-01-18T16:14:10Z |
| description   |  |
| id| ce04f4db-22e3-4ba4-9f64-686e57c2d633 |
| ipv4_address_scope|  |
| ipv6_address_scope|  |
| mtu   | 1450 |
| name  | poolnet  |
| port_security_enabled | True |
| project_id| db0c096ae736499b84b08ef06106b138 |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 68   |
| revision_number   | 3|
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tags  |  |
| tenant_id | db0c096ae736499b84b08ef06106b138 |
| updated_at| 2017-01-18T16:14:10Z |
+---+--+

[root@devstack178 devstack]# neutron  subnetpool-create  addresspool25  
--pool-prefix 25.0.0.0/8 --default-prefixlen 24
Created a new subnetpool:
+---+--+
| Field | Value|
+---+--+
| address_scope_id  |  |
| created_at| 2017-01-18T16:16:23Z |
| default_prefixlen | 24   |
| default_quota |  |
| description   |  |
| id| c84855bb-bf76-4ed5-b213-9ec4bac20077 |
| ip_version| 4|
| is_default| False|
| max_prefixlen | 32   |
| min_prefixlen | 8|
| name  | addresspool25|
| prefixes  | 25.0.0.0/8   |
| project_id| db0c096ae736499b84b08ef06106b138 |
| revision_number   | 1|
| shared| False|
| tenant_id | db0c096ae736499b84b08ef06106b138 |
| updated_at| 2017-01-18T16:16:23Z |
+---+--+

2. creat a subnet which cidr in subnetpool
[root@devstack178 devstack]# neutron subnet-create poolnet  --subnetpool 
addresspool25
Created a new subnet:
+---++
| Field | Value  |
+---++
| allocation_pools  | {"start": "25.0.0.2", "end": "25.0.0.254"} |
| cidr  | 25.0.0.0/24|
| created_at| 2017-01-18T16:17:54Z   |
| description   ||
| dns_nameservers   ||
| enable_dhcp   | True   |
| gateway_ip| 25.0.0.1   |
| host_routes   ||
| id| 8705a697-8c63-4511-b4b7-7e0e968ce460   |
| ip_version| 4  |
| ipv6_address_mode ||
| ipv6_ra_mode  ||
| name  ||
| network_id| ce04f4db-22e3-4ba4-9f64-686e57c2d633   |
| project_id| db0c096ae736499b84b08ef06106b138   |
| revision_number   | 2  |
| service_types ||
| subnetpool_id | 

[Yahoo-eng-team] [Bug 1657358] [NEW] Create fw_policy with used fw_rule hit internal error

[zhaobo]

Public bug reported:

Hit internal error when create fw_policy with exist fw_rule.

If there is a policy with this fw_rule already, new request create an
new policy with the fw_rule, neutron-server will hit internal error.


repo
-
1. create a fw_ruleA
2. create a fw_policyX with fw_ruleA
3. create another fw_policyY with fw_ruleA ERROR


2017-01-16 16:01:20.220 ERROR neutron.api.v2.resource 
[req-d4fa6f6b-852d-4233-a39b-9ae73dbd8c45 admin 
a4d7fafd8b6e42f5aa1de690e360d285] create failed: No details.
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource Traceback (most recent 
call last):
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/resource.py", line 79, in resource
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource result = 
method(request=request, **args)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 438, in create
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource return 
self._create(request, body, **kwargs)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 92, in wrapped
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource setattr(e, 
'_RETRY_EXCEEDED', True)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource self.force_reraise()
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 88, in wrapped
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource return f(*args, 
**kwargs)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource ectxt.value = 
e.inner_exc
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource self.force_reraise()
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource return f(*args, 
**kwargs)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 128, in wrapped
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource 
traceback.format_exc())
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource self.force_reraise()
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/db/api.py", line 123, in wrapped
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource return f(*dup_args, 
**dup_kwargs)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 551, in _create
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource obj = do_create(body)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 533, in do_create
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource request.context, 
reservation.reservation_id)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource self.force_reraise()
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource   File 
"/opt/stack/neutron/neutron/api/v2/base.py", line 526, in do_create
2017-01-16 16:01:20.220 TRACE neutron.api.v2.resource return 
obj_creator(request.context, **kwargs)