[Yahoo-eng-team] [Bug 1657655] [NEW] Dashboard|出错啦!遇到异常情况,请刷新。如需帮助请联系管理员。
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
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
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
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
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."
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": "http://1
[Yahoo-eng-team] [Bug 1657597] [NEW] Floating IP association to allowed address pair fails due to transaction in transaction
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 t
[Yahoo-eng-team] [Bug 1557032] Re: Add "allow_migrate_to_same_host" in deprecated options for nova.conf
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
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
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 nova.api.openstack.extension
[Yahoo-eng-team] [Bug 1298061] Re: nova should allow evacuate for an instance in the Error state
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
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
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
** 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
** 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
** 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
** 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.
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
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
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
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
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
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
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
** 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 neutron.agent.linux.ut
[Yahoo-eng-team] [Bug 1657452] Re: Incompatibility with python-webob 1.7.0
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 mismatc
[Yahoo-eng-team] [Bug 1657452] Re: Incompatibility with python-webob 1.7.0
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
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
** 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
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
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')
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
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
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
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 2
[Yahoo-eng-team] [Bug 1657441] [NEW] Remove the set device_owner when attaching subports
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
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."
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 = keystoneauth1.loading._
[Yahoo-eng-team] [Bug 1657424] [NEW] Hyper-V: Instance ports not bound after resize
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
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
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
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
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
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
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
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
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
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 | c84855bb-bf76-4ed5-b213-9ec4bac2007
[Yahoo-eng-team] [Bug 1657358] [NEW] Create fw_policy with used fw_rule hit internal error
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) 201