[Yahoo-eng-team] [Bug 1611627] [NEW] revision plugin throwing objectdeletederror
Public bug reported: If there is an expired object in the session that got concurrently deleted by another session, the revision plugin may throw an ObjectDeletedError when it goes to bump the revision and references expired attributes (causing a DB lookup that returns nothing). 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource [req-c1b008ba-a6a7-4ac0-bb71-baf27253e098 tempest-NetworksTestDHCPv6-139641 -] create failed: No details. 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource Traceback (most recent call last): 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource result = method(request=request, **args) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 397, in create 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource return self._create(request, body, **kwargs) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource ectxt.value = e.inner_exc 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource self.force_reraise() 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource return f(*args, **kwargs) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 510, in _create 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource obj = do_create(body) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 492, in do_create 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource request.context, reservation.reservation_id) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource self.force_reraise() 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource six.reraise(self.type_, self.value, self.tb) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/api/v2/base.py", line 485, in do_create 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource return obj_creator(request.context, **kwargs) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/common/utils.py", line 613, in inner 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource return f(self, context, *args, **kwargs) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 977, in create_subnet 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource result, mech_context = self._create_subnet_db(context, subnet) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/plugins/ml2/plugin.py", line 965, in _create_subnet_db 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource result = super(Ml2Plugin, self).create_subnet(context, subnet) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/db_base_plugin_v2.py", line 723, in create_subnet 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource return self._create_subnet(context, subnet, subnetpool_id) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/db_base_plugin_v2.py", line 623, in _create_subnet 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource subnet, ipam_subnet) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/opt/stack/new/neutron/neutron/db/ipam_non_pluggable_backend.py", line 350, in add_auto_addrs_on_network_ports 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource context.session.add(allocated) 2016-08-09 23:57:02.093 17791 ERROR neutron.api.v2.resource File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/orm/s
[Yahoo-eng-team] [Bug 1611628] [NEW] test_admin_only_rules doesn't check an 'admin_or_owner' case correctly
Public bug reported: The test_admin_only_rules method of RealRolePolicyTestCase class in nova/tests/unit/test_policy.py doesn't check an 'admin_or_owner' case correctly. def test_admin_only_rules(self): for rule in self.admin_only_rules: self.assertRaises(exception.PolicyNotAuthorized, policy.authorize, self.non_admin_context, rule, self.target) policy.authorize(self.admin_context, rule, self.target) https://github.com/openstack/nova/blob/3d6e72689ee18a779d70405d11e09a69183cc853/nova/tests/unit/test_policy.py#L495 If an admin only rule in source code is changed to 'admin_or_owner' rule by mistake, the assertRaises statement raises a PolicyNotAuthorized exception because it is not that the context is non admin user but the owner is defferent. So the target should be set to same project of non admin context. ** Affects: nova Importance: Undecided Assignee: Takashi NATSUME (natsume-takashi) 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/1611628 Title: test_admin_only_rules doesn't check an 'admin_or_owner' case correctly Status in OpenStack Compute (nova): New Bug description: The test_admin_only_rules method of RealRolePolicyTestCase class in nova/tests/unit/test_policy.py doesn't check an 'admin_or_owner' case correctly. def test_admin_only_rules(self): for rule in self.admin_only_rules: self.assertRaises(exception.PolicyNotAuthorized, policy.authorize, self.non_admin_context, rule, self.target) policy.authorize(self.admin_context, rule, self.target) https://github.com/openstack/nova/blob/3d6e72689ee18a779d70405d11e09a69183cc853/nova/tests/unit/test_policy.py#L495 If an admin only rule in source code is changed to 'admin_or_owner' rule by mistake, the assertRaises statement raises a PolicyNotAuthorized exception because it is not that the context is non admin user but the owner is defferent. So the target should be set to same project of non admin context. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611628/+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 1611626] [NEW] neutron port-list consumes much longer for normal tenant user than admin role user
Public bug reported: I have a neutron deployment where there are just 300 ports. for admin user to run neutron port-list, it just took 2 secs, but for normal tenant user, it took more than 10+ secs. I examined the API codes, thought it is the authorisation check that makes the difference. ** 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/1611626 Title: neutron port-list consumes much longer for normal tenant user than admin role user Status in neutron: New Bug description: I have a neutron deployment where there are just 300 ports. for admin user to run neutron port-list, it just took 2 secs, but for normal tenant user, it took more than 10+ secs. I examined the API codes, thought it is the authorisation check that makes the difference. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611626/+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 1611613] [NEW] python-cinderclient documentation unclear on Volume.attach
Public bug reported: python-cinderclient ships a class cinderclient.v1.volumes.Volume which has an 'attach' method, documented rather vaguely as "Set attachment metadata.". This method should not be called directly by API users when attempting to attach a Cinder volume to a Nova instance, else the Nova and Cinder databases will become inconsistent, as detailed at: http://www.florentflament.com/blog/openstack-volume-in-use-although-vm- doesnt-exist.html As far as I can tell, this API exists solely for use by consumers of Cinder services such as Nova, so they can inform Cinder that they're now using one of Cinder's volumes. If this is true, then: 1. The documentation should state this; and 2. If all consumers of Cinder volumes already have an admin token (as Nova does), then this API should require such an admin token, to prevent cloud end-users from calling it. Steps to reproduce: See http://www.florentflament.com/blog/openstack-volume-in-use-although- vm-doesnt-exist.html Expected results: Nova and Cinder shall agree on whether or not a given volume is in use. Unprivileged end users shall not be able to call APIs that aren't intended for their use. Documentation shall contain useful information. It shall not be possible for unprivileged end users to create inconsistent database data that require privilege to clean up. Actual results: Nova thinks the volume is not in use, but Cinder thinks it is, so the OpenStack deployment as a whole is confused about the state of the volume. Unprivileged users can call an API that appears to only be intended for Nova's use. Documentation doesn't communicate anything. An unprivileged user can create inconsistent database data that require either OpenStack admin creds and 'cinder reset-state' or manual database changes to restore consistency. Environment: Liberty/KVM/Ceph/customised Neutron ** Affects: python-cinderclient 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/1611613 Title: python-cinderclient documentation unclear on Volume.attach Status in python-cinderclient: New Bug description: python-cinderclient ships a class cinderclient.v1.volumes.Volume which has an 'attach' method, documented rather vaguely as "Set attachment metadata.". This method should not be called directly by API users when attempting to attach a Cinder volume to a Nova instance, else the Nova and Cinder databases will become inconsistent, as detailed at: http://www.florentflament.com/blog/openstack-volume-in-use-although- vm-doesnt-exist.html As far as I can tell, this API exists solely for use by consumers of Cinder services such as Nova, so they can inform Cinder that they're now using one of Cinder's volumes. If this is true, then: 1. The documentation should state this; and 2. If all consumers of Cinder volumes already have an admin token (as Nova does), then this API should require such an admin token, to prevent cloud end-users from calling it. Steps to reproduce: See http://www.florentflament.com/blog/openstack-volume-in-use- although-vm-doesnt-exist.html Expected results: Nova and Cinder shall agree on whether or not a given volume is in use. Unprivileged end users shall not be able to call APIs that aren't intended for their use. Documentation shall contain useful information. It shall not be possible for unprivileged end users to create inconsistent database data that require privilege to clean up. Actual results: Nova thinks the volume is not in use, but Cinder thinks it is, so the OpenStack deployment as a whole is confused about the state of the volume. Unprivileged users can call an API that appears to only be intended for Nova's use. Documentation doesn't communicate anything. An unprivileged user can create inconsistent database data that require either OpenStack admin creds and 'cinder reset-state' or manual database changes to restore consistency. Environment: Liberty/KVM/Ceph/customised Neutron To manage notifications about this bug go to: https://bugs.launchpad.net/python-cinderclient/+bug/1611613/+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 1611613] Re: python-cinderclient documentation unclear on Volume.attach
Proposed replacement help text: Inform Cinder that the given volume is attached to the given instance. If the volume is not actually attached to the given instance, inconsistent data will result. This is not the correct way to attach a volume to an instance. ** Project changed: nova => python-cinderclient -- 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/1611613 Title: python-cinderclient documentation unclear on Volume.attach Status in python-cinderclient: New Bug description: python-cinderclient ships a class cinderclient.v1.volumes.Volume which has an 'attach' method, documented rather vaguely as "Set attachment metadata.". This method should not be called directly by API users when attempting to attach a Cinder volume to a Nova instance, else the Nova and Cinder databases will become inconsistent, as detailed at: http://www.florentflament.com/blog/openstack-volume-in-use-although- vm-doesnt-exist.html As far as I can tell, this API exists solely for use by consumers of Cinder services such as Nova, so they can inform Cinder that they're now using one of Cinder's volumes. If this is true, then: 1. The documentation should state this; and 2. If all consumers of Cinder volumes already have an admin token (as Nova does), then this API should require such an admin token, to prevent cloud end-users from calling it. Steps to reproduce: See http://www.florentflament.com/blog/openstack-volume-in-use- although-vm-doesnt-exist.html Expected results: Nova and Cinder shall agree on whether or not a given volume is in use. Unprivileged end users shall not be able to call APIs that aren't intended for their use. Documentation shall contain useful information. It shall not be possible for unprivileged end users to create inconsistent database data that require privilege to clean up. Actual results: Nova thinks the volume is not in use, but Cinder thinks it is, so the OpenStack deployment as a whole is confused about the state of the volume. Unprivileged users can call an API that appears to only be intended for Nova's use. Documentation doesn't communicate anything. An unprivileged user can create inconsistent database data that require either OpenStack admin creds and 'cinder reset-state' or manual database changes to restore consistency. Environment: Liberty/KVM/Ceph/customised Neutron To manage notifications about this bug go to: https://bugs.launchpad.net/python-cinderclient/+bug/1611613/+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 1611612] [NEW] linuxbridge and dhcp agents race removing tap
Public bug reported: When a network is deleted, an exception can happen because the lb-agent tries to removes the dhcp tap from the bridge at about the same time as the dhcp-agent is deleting the tap. The unhandled expection results in the bridge not getting cleaned up and an error and stacktrace in the logs. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22self.remove_interface%5C%22 Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming res = self.dispatcher.dispatch(message) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch return self._do_dispatch(endpoint, method, ctxt, args) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch result = func(ctxt, **new_args) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 803, in network_delete self.agent.mgr.delete_bridge(bridge_name) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 521, in delete_bridge self.remove_interface(bridge_name, interface) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 568, in remove_interface if bridge_device.delif(interface_name): File "/opt/stack/new/neutron/neutron/agent/linux/bridge_lib.py", line 80, in delif return self._brctl(['delif', self.name, interface]) File "/opt/stack/new/neutron/neutron/agent/linux/bridge_lib.py", line 55, in _brctl return ip_wrapper.netns.execute(cmd, run_as_root=True) File "/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 876, in execute log_fail_as_error=log_fail_as_error, **kwargs) File "/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 138, in execute raise RuntimeError(msg) RuntimeError: Exit code: 1; Stdin: ; Stdout: ; Stderr: device tap1aa0d45a-39 is not a slave of brq6d449049-5c ** Affects: neutron Importance: Undecided Assignee: Darragh O'Reilly (darragh-oreilly) Status: In Progress ** Tags: linuxbridge ** Tags added: linuxbridge ** Changed in: neutron Assignee: (unassigned) => Darragh O'Reilly (darragh-oreilly) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611612 Title: linuxbridge and dhcp agents race removing tap Status in neutron: In Progress Bug description: When a network is deleted, an exception can happen because the lb- agent tries to removes the dhcp tap from the bridge at about the same time as the dhcp-agent is deleting the tap. The unhandled expection results in the bridge not getting cleaned up and an error and stacktrace in the logs. http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%20%5C%22self.remove_interface%5C%22 Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 133, in _process_incoming res = self.dispatcher.dispatch(message) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 150, in dispatch return self._do_dispatch(endpoint, method, ctxt, args) File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 121, in _do_dispatch result = func(ctxt, **new_args) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 803, in network_delete self.agent.mgr.delete_bridge(bridge_name) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 521, in delete_bridge self.remove_interface(bridge_name, interface) File "/opt/stack/new/neutron/neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py", line 568, in remove_interface if bridge_device.delif(interface_name): File "/opt/stack/new/neutron/neutron/agent/linux/bridge_lib.py", line 80, in delif return self._brctl(['delif', self.name, interface]) File "/opt/stack/new/neutron/neutron/agent/linux/bridge_lib.py", line 55, in _brctl return ip_wrapper.netns.execute(cmd, run_as_root=True) File "/opt/stack/new/neutron/neutron/agent/linux/ip_lib.py", line 876, in execute log_fail_as_error=log_fail_as_error, **kwargs) File "/opt/stack/new/neutron/neutron/agent/linux/utils.py", line 138, in execute raise RuntimeError(msg) RuntimeError: Exit code: 1; Stdin: ; Stdout: ; Stderr: device tap1aa0d45a-39 is not a slave of brq6d449049-5c To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611612/+subscripti
[Yahoo-eng-team] [Bug 1247132] Re: Python 3 support and dropping cheetah
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1247132 Title: Python 3 support and dropping cheetah Status in cloud-init: Fix Released Bug description: Hi, in Fedora, we would like to use cloud-init with Python 3. While we are willing to help porting boto and cloud-init to support both Python 2.6/2.7 and 3.3, cheetah is the thing we won't like to port, as it is old. So the question is: Would you accept patches that would introduce support for Python 3 and replace cheetah with a different templating system, such as jinja? If not we would need to come with our own solution (either repalce cloud-init or fork it) and I would not like to do that very much. Thanks for info Related bugs: * bug 1219223: Is it possible that we switch from cheetah to a lighter weight template engine? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1247132/+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 1571004] Re: apply networking only on first instance boot
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1571004 Title: apply networking only on first instance boot Status in cloud-init: Fix Released Bug description: Currently cloud-init is applying networking on every boot. On 'local' data sources that provides network information this is great. On any other datasource: * local datasource without networking info * network based datasource then the fallback networking is rendered on every boot. In the scenario: a.) boot instance b.) fallback networking picks eth0.cfg and that is fine c.) attach network device d.) reboot things can get hairy. The suggested change is to only apply the networking configuration once per instance. This is less dynamic and less surprising. ie, if a user modifies /etc/network/interfaces.d/my.cfg and adds to or improves on the fallback (or unconfigures the fallback) then their changes might not interact well. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1571004/+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 1286164] Re: final_message does not work with cloud-init 0.7.3
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1286164 Title: final_message does not work with cloud-init 0.7.3 Status in cloud-init: Fix Released Bug description: Setup: Ubuntu UEC saucy 13.10 Cloud-init v0.7.3 I use the user data sample [1] to set a final message in VM logs and I get error message at the end of the logs: '2014-02-28 14:33:33,288 - util.py[WARNING]: Failed to render final message template' error. If I made the same test with Ubuntu UEC precise 12.04.3 which uses cloud-init version 0.6.3, it works. [1] http://bazaar.launchpad.net/~cloud-init-dev/cloud- init/trunk/view/head:/doc/examples/cloud-config-final-message.txt To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1286164/+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 1275414] Re: Support for Google Cloud Engine.
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1275414 Title: Support for Google Cloud Engine. Status in cloud-init: Fix Released Bug description: Dear Scott and everybody, Debian carries a patch to support Google Cloud Engine (GCE). Would it be suitable for inclusion in cloud-init ? http://anonscm.debian.org/viewvc/python- apps?view=revision&revision=10052 Note the changes to the Debconf templates in the same revision. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan Uploader of the cloud-init package in Debian To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1275414/+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 1603533] Re: Can't build correctly using brpm on cent7
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1603533 Title: Can't build correctly using brpm on cent7 Status in cloud-init: Fix Released Bug description: Getting the following after building on cent7 and installing, Traceback (most recent call last): File "/usr/bin/cloud-init", line 5, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 3007, in working_set.require(__requires__) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 728, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: argparse It appears that even though it gets added as a dep that cent7 doesn't register it correctly, $ sudo yum install python-argparse Loaded plugins: changelog, fastestmirror, rhnplugin, versionlock This system is receiving updates from RHN Classic or Red Hat Satellite. ... Package python-2.7.5-34.el7.x86_64 already installed and latest version Nothing to do But then when ran cloud-init has a dep on a thing that does not actually exist. So on 2.7 we don't need to do this in the first place (the explicit dep for argparse is only for 2.6) so we can just do this smarter (and avoid this mess in the first place). To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1603533/+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 1611596] [NEW] recent routerports unique key change broke out-of-tree plugins
Public bug reported: recent change [1] broke out-of-tree plugins which uses surrounding transactions. eg. networking-midonet [1] I15be35689ec59ac02ed34abe5862fa4580c8587c eg. http://logs.openstack.org/40/353140/1/check/gate-networking-midonet- python35/4099ec1/testr_results.html.gz Traceback (most recent call last): File "/tmp/openstack/neutron/neutron/api/v2/resource.py", line 79, in resource result = method(request=request, **args) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/oslo_db/api.py", line 151, in wrapper ectxt.value = e.inner_exc File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/six.py", line 686, in reraise raise value File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/oslo_db/api.py", line 139, in wrapper return f(*args, **kwargs) File "/tmp/openstack/neutron/neutron/db/api.py", line 74, in wrapped traceback.format_exc()) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/six.py", line 686, in reraise raise value File "/tmp/openstack/neutron/neutron/db/api.py", line 69, in wrapped return f(*args, **kwargs) File "/tmp/openstack/neutron/neutron/api/v2/base.py", line 217, in _handle_action ret_value = getattr(self._plugin, name)(*arg_list, **kwargs) File "/home/jenkins/workspace/gate-networking-midonet-python35/midonet/neutron/plugin_v1.py", line 388, in add_router_interface context, router_id, interface_info) File "/tmp/openstack/neutron/neutron/db/l3_db.py", line 1766, in add_router_interface context, router_id, interface_info) File "/tmp/openstack/neutron/neutron/db/l3_db.py", line 807, in add_router_interface port_id=port['id']).one() File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2718, in one ret = list(self) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2761, in __iter__ return self._execute_and_instances(context) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2774, in _execute_and_instances close_with_result=True) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/query.py", line 2765, in _connection_from_session **kw) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/session.py", line 893, in connection execution_options=execution_options) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/session.py", line 898, in _connection_for_bind engine, execution_options) File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/session.py", line 313, in _connection_for_bind self._assert_active() File "/home/jenkins/workspace/gate-networking-midonet-python35/.tox/py35/lib/python3.5/site-packages/sqlalchemy/orm/session.py", line 218, in _assert_active "This Session's transaction has been rolled back " sqlalchemy.exc.InvalidRequestError: This Session's transaction has been rolled back by a nested rollback() call. To begin a new transaction, issue Session.rollback() first. }}} ** Affects: networking-midonet Importance: Critical Assignee: YAMAMOTO Takashi (yamamoto) Status: New ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure ** Also affects: networking-midonet Importance: Undecided Status: New ** Changed in: networking-midonet Importance: Undecided => Critical ** Changed in: networking-midonet Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto) ** Tags added: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launch
[Yahoo-eng-team] [Bug 1574991] Re: member-id should contian only numbers and letters
** Project changed: glance => python-glanceclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1574991 Title: member-id should contian only numbers and letters Status in python-glanceclient: In Progress Bug description: Now, there is no limit for member-id's format. It means that all characters are allowed. But member_id means a project's(tenant's) id. It shoud contian only numbers and letters. If not, it will lead some error: reprodue: env: glance master 1.create a member for an image: $glance member-create b9125ded-d2d0-4d4e-9eee-5623344c9cbf fdsae#$%^^da 2.delete the member from the image: $glance member-delete b9125ded-d2d0-4d4e-9eee-5623344c9cbf fdsae#$%^^da the error accoured: 404 Not Found fdsae not found in the member list of the image b9125ded-d2d0-4d4e-9eee-5623344c9cbf. (HTTP 404) To manage notifications about this bug go to: https://bugs.launchpad.net/python-glanceclient/+bug/1574991/+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 1550269] Re: 'hw:cpu_thread_policy=require' does not function correctly if NUMATopologyFilter is disabled
Reviewed: https://review.openstack.org/285232 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=ad0047e97b2847412ee28bad6a3bfb48395add35 Submitter: Jenkins Branch:master commit ad0047e97b2847412ee28bad6a3bfb48395add35 Author: Stephen Finucane Date: Fri Feb 26 10:55:55 2016 + virt/hardware: Check for threads when "required" The 'require' case "requires" the presence of hardware threads on a host. At present, this check is done using the NUMATopology filter. Unfortunately, this means that if this filter is disabled then instances can be scheduled on invalid hosts. Resolve this by adding a new check to be run when hosts are actually scheduling. Change-Id: Ia9e4784e02ca9ce7a3d81c962b95bee100f6db42 Closes-bug: #1550269 ** 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/1550269 Title: 'hw:cpu_thread_policy=require' does not function correctly if NUMATopologyFilter is disabled Status in OpenStack Compute (nova): Fix Released Bug description: The 'require' policy is supposed to restrict instances to hosts that support hardware threads, e.g. HyperThreading. However, this filtering is done as part of the NUMATopologyFilter. If this filter is disabled, the host boots just fine. This should not be the case and needs to be fixed. Findings below. --- Testing was conducted on a single-node, Fedora 23-based (4.3.5-300.fc23.x86_64) OpenStack instance (built with devstack). The system is a dual-socket, ten core, HT-enabled system (2 sockets * 10 cores * 2 threads = 40 "pCPUs". 0-9,20-29 = node0, 10-19,30-39 = node1). Commit '8bafc9' of Nova was used. # Steps ## Create flavors $ openstack flavor create pinned.require \ --id 102 --ram 2048 --disk 0 --vcpus 4 $ openstack flavor set pinned.require \ --property "hw:cpu_policy=dedicated" \ --property "hw:cpu_thread_policy=require" ## Validate a HT-enabled node The 'require' case is a stricter version of the `prefer` case, in that it should fail if we have HyperThreading disabled, do not have enough free sibling sets, or have no HyperThreading support at all. However, since we're not hitting any of these conditions on this host, things should function just like they do for the `prefer` case. Therefore, the guest should see a two sockets with one core per socket and two threads per core. $ openstack server create --flavor=pinned.require \ --image=cirros-0.3.4-x86_64-uec --wait test1 $ sudo virsh list IdName State 2 instance-0002 running $ sudo virsh dumpxml 2 instance-0002 ... 4 4096 ... ... $ openstack server delete test1 No issues here. ## Validate a HT-disabled node This policy "requires" HyperThreading or similar on the host, so it shouldn't work here. $ openstack server create --flavor=pinned.require \ --image=cirros-0.3.4-x86_64-uec --wait test1 $ sudo virsh list IdName State 2 instance-0002 running $ sudo virsh dumpxml 2 instance-0002 ... 4 4096 ... ... $ openstack server delete test1 This is a problem, but we do not currently have the filter activated: $ cat /etc/nova/nova.conf | grep scheduler_default_filters scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,\ DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,\ ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,\ DifferentHostFilter Let's activate this: $ cat /etc/nova/nova.conf | grep scheduler_default_filters scheduler_default_filters = RetryFilter,AvailabilityZoneFilter,RamFilter,\ DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,\ ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,\ DifferentHostFilter,NUMATopologyFilter And try again: $ openstack server create --flavor=pinned.require \ --image=cirros-0.3.4-x86_64-uec --wait test1 Error creating server:
[Yahoo-eng-team] [Bug 1572168] Re: [api] Missing response parameter tables identity admin API
Reviewed: https://review.openstack.org/352980 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=6db31c8590261ae10c7ae59b737601795192a9b4 Submitter: Jenkins Branch:master commit 6db31c8590261ae10c7ae59b737601795192a9b4 Author: Gage Hugo Date: Tue Aug 9 10:37:31 2016 -0500 api-ref: Add missing parameter tables to tenant This adds response tables to multiple tenant API calls within the identity admin API. Change-Id: I78ff3d981ed0a1d4dc42d0a81b0369e7275d4d85 Closes-Bug: #1572168 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1572168 Title: [api] Missing response parameter tables identity admin API Status in OpenStack Identity (keystone): Fix Released Bug description: http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-listTenants http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-showTenantByName http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-showTenantById http://developer.openstack.org/api-ref-identity-admin-v2.html#admin-listRolesForUserOnTenant The above APIs do not have response parameter table. They must be documented. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1572168/+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 1609177] Re: [api] Add "nocatalog" option to GET /v3/auth/tokens
Reviewed: https://review.openstack.org/352718 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=82bf342f20b345e37649676ff76a85c110c2191d Submitter: Jenkins Branch:master commit 82bf342f20b345e37649676ff76a85c110c2191d Author: Tin Lam Date: Tue Aug 9 00:51:58 2016 -0500 api-ref: Add "nocatalog" option to GET /v3/auth/tokens Added missing "nocatalog" query parameter for GET /v3/auth/tokens API to api-ref. See [1]. [1] http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#validate-token Change-Id: Ie2310b7dfaf8d6a05b6a61ac6f9639d181798930 Closes-Bug: #1609177 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1609177 Title: [api] Add "nocatalog" option to GET /v3/auth/tokens Status in OpenStack Identity (keystone): Fix Released Bug description: The following API route is missing from the API site (POST /v3/auth/tokens?nocatalog), it can be seen in the specs repo: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity- api-v3.html#catalog-opt-out To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1609177/+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 1535551] Re: One port can be added as multiple routers' interfaces if commands are executed at the same time
Reviewed: https://review.openstack.org/285048 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6281fddbcb4c471b6b06e24d3faa2990e040f3d2 Submitter: Jenkins Branch:master commit 6281fddbcb4c471b6b06e24d3faa2990e040f3d2 Author: Lujin Luo Date: Tue Jun 21 14:23:33 2016 +0900 Add a unique key to port_id in routerports table If multiple commands to add router interfaces to different routers by the same port are executed concurrently, then all the commands would show success. However, there are three issues: 1. Only one router interface is actually added by the port 2. Multiple router ports records are stored in routerports table 3. The port table is updated multiple times and eventually the last-arrived command would truly take effect This patch adds a unique key to port_id in routerport table, so that only the first-arrived command will insert router port record and all later requests would raise exceptions. Besides, port.device_id and port.device_owner in port table needs to be updated again after routerport record is inserted. Otherwise, in race condition the port table will store the router information from last-arrived request. However, in routerport table, only the first-arrived request's router information is inserted. Change-Id: I15be35689ec59ac02ed34abe5862fa4580c8587c Closes-Bug: #1535551 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1535551 Title: One port can be added as multiple routers' interfaces if commands are executed at the same time Status in neutron: Fix Released Bug description: I have three controller nodes and the Neutron servers on these controllers are set behind Pacemaker and HAProxy to realize active/active HA using DevStack. MariaDB Galera cluster is used as my database backend.I am using the latest codes. If one port is added as multiple routers' interfaces, the expected result is that only API request is executed successfully and the port is associated to one router. Other API requests would recieve error message like PortInUseClient: Unable to complete operation on port d2c97788-61d7-489a-8b20-7a6e8e39a217 for network 496de8cf-4284-41d7-ad6b-7dd5f232dc21. Port already has an attached device 1b316d80-f5d8-4477-88df-54b376c4c8cd. Besides, in routerports database, only one record of port is allowed to exist. However, if we run two commands to add one port as two different routers' interfaces at the same time. Both of the commands would show execution succeed. The truth is two records that the port is associated to both routers are listed in routerports database. How to reproduce Step 1: Create two routers $ neutron router-create router-1 $ neutron router-create router-2 Step 2: Create an internal network $ neutron net-create net1 Step 3: Add a subnet to the network $ neutron subnet-create --name subnet1 net1 192.166.100.0/24 Step 4: Create a port in the network $ neutron port-create --name port1 net1 Step 5: Add this port as two routers' interfaces at the same time On controller1: $ neutron router-interface-add router-1 port=port1 on controller2: $ neutron router-interface-add router-2 port=port1 Both commands would return success, as shown http://paste.openstack.org/show/483840/ Step 6: Check port list on both routers The result is shown http://paste.openstack.org/show/483843/ As we can see, only one router is successfully associated to the port Step 7: Check routerports database http://paste.openstack.org/show/483842/ where '99276755-236a-44b7-bf97-b2234d97028b' is the port_id of the port we created in Step 4. To sum up, we have two issues here a) Only one API request is executed successfully, but both commands return success b) Routerports database is updated twice and we need to delete the older record. Related source codes is [1] [1] https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L535 Update on 2016/6/15 If we have operator-1 who is trying to add port_1 as router_1's interface while at the same time operator-2 is trying to add port_2 as router_2's interface. However, operator-2 miss-typed "port-2" to "port-1". Without this unique key, both commands will return Success. Operator-2 would hardly realize that he/she did a wrong command. What is worse is that, if router_1 truly added port_1 as interface, and router_2 did not. If we perform interface_delete command on router_2, port_1 is deleted and router_1 (which truly has the interface of port_1) will lose interface. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1535551/+subscriptions --
[Yahoo-eng-team] [Bug 1558888] Re: Duplicated codes in ovs_neutron_agent and ovs_dvr_neutron_agent
Reviewed: https://review.openstack.org/294378 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bc53c3b376b08e66f93048ced5e9349105d13ddf Submitter: Jenkins Branch:master commit bc53c3b376b08e66f93048ced5e9349105d13ddf Author: JieLee Date: Sun Jan 3 08:37:23 2016 +0800 ML2 remove extra checks in ovs_dvr_neutron_agent Remove the extra checks in ovs_dvr_neutron_agent that can be done in ovs_neutron_agent in one place. Closes-bug: #155 Change-Id: I7192e1c0447ea35649672caa771e5a9c6aa2636b ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/155 Title: Duplicated codes in ovs_neutron_agent and ovs_dvr_neutron_agent Status in neutron: Fix Released Bug description: After the neutron-openvswitch-agent service starting or the openvswitch restarting, neutron-openvswitch-agent will check if it run in dvr mode and then determine to set dvr flows or not, howerver, i find there are some dumplcate if statements, . To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/155/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1611546] [NEW] db_models.rst isn't included in any toctree
Public bug reported: Neutron documentation warnings are treated them as errors. $ sphinx-build -W -b html doc/source doc/build/html 18:00:59 Running Sphinx v1.2.3 fatal: unknown date format local - loading pickled environment... not yet created Using openstack theme from /Users/vjmorale/src/vagrant-intel-devstack/stack/neutron/.venv/lib/python2.7/site-packages/oslosphinx/theme building [html]: targets for 57 source files that are out of date updating environment: 57 added, 0 changed, 0 removed reading sources... [100%] stadium/sub_projects looking for now-outdated files... none found pickling environment... done checking consistency... Warning, treated as error: /Users/vjmorale/src/vagrant-intel-devstack/stack/neutron/doc/source/devref/db_models.rst:: WARNING: document isn't included in any toctree ** Affects: neutron Importance: Undecided Assignee: Victor Morales (electrocucaracha) Status: In Progress ** Tags: doc ** Changed in: neutron Assignee: (unassigned) => Victor Morales (electrocucaracha) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611546 Title: db_models.rst isn't included in any toctree Status in neutron: In Progress Bug description: Neutron documentation warnings are treated them as errors. $ sphinx-build -W -b html doc/source doc/build/html 18:00:59 Running Sphinx v1.2.3 fatal: unknown date format local - loading pickled environment... not yet created Using openstack theme from /Users/vjmorale/src/vagrant-intel-devstack/stack/neutron/.venv/lib/python2.7/site-packages/oslosphinx/theme building [html]: targets for 57 source files that are out of date updating environment: 57 added, 0 changed, 0 removed reading sources... [100%] stadium/sub_projects looking for now-outdated files... none found pickling environment... done checking consistency... Warning, treated as error: /Users/vjmorale/src/vagrant-intel-devstack/stack/neutron/doc/source/devref/db_models.rst:: WARNING: document isn't included in any toctree To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611546/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1610645] Re: Migrating last HA router to legacy doesn't delete HA network
Reviewed: https://review.openstack.org/352068 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f13f56f4032784fa3b2e1751c7c3a897877d2fe0 Submitter: Jenkins Branch:master commit f13f56f4032784fa3b2e1751c7c3a897877d2fe0 Author: John Schwarz Date: Sun Aug 7 11:23:59 2016 +0300 Delete HA network if last HA router is migrated If an HA router is deleted and it's the last one a tenant has, the HA network is deleted as it's no longer needed. The same should occur when migrating the last HA router of a tenant from HA to Legacy. Closes-Bug: #1610645 Change-Id: Ib27224c028bef98b78a5cea91e62ea98a2847008 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1610645 Title: Migrating last HA router to legacy doesn't delete HA network Status in neutron: Fix Released Bug description: As the title suggests, migrating a tenant's the last HA router from HA to legacy, doesn't cleanup the HA network. [stack@js16 ~]$ neutron router-create x --ha=True Created a new router: +-+--+ | Field | Value| +-+--+ | admin_state_up | True | | availability_zone_hints | | | availability_zones | | | description | | | distributed | False| | external_gateway_info | | | flavor_id | | | ha | True | | id | 2bafaae3-776b-4707-958b-f1df77d832fb | | name| x| | revision| 2| | routes | | | status | ACTIVE | | tenant_id | 20482218062b458589b9cffa3a1bb172 | +-+--+ [stack@js16 ~]$ neutron router-update x --admin_state_up=False Updated router: x [stack@js16 ~]$ neutron router-update x --ha=False Updated router: x [stack@js16 ~]$ neutron router-delete x Deleted router: x [stack@js16 ~]$ neutron net-list +--++--+ | id | name | subnets | +--++--+ | 088ffed2-27a0-422e-b92c-c388e825cf8f | HA network tenant 20482218062b458589b9cffa3a1bb172 | 92ee2c83-8fdb-4767-90b3-bfb69fca452f 169.254.192.0/18| | e0e366ee-8a94-4753-8b9a-474bf692fb99 | public | e0933b88-7baf-47a9-84d8-7c98e140f747 172.24.4.0/24 | | | | 400fa2e9-f373-4c7b-954c-f419d6dfba7b 2001:db8::/64 | | fa13ed8e-dd44-4499-a3e8-531a25f26256 | private | 26f2f679-c255-4c36-93ac-7f6ec3e98ffe fd22:5205:4fcc::/64 | | | | ed866867-1611-4919-bb3a-1ff0b4f1d36a 10.0.0.0/24 | +--++--+ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1610645/+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 1611533] Re: ml2 transaction_guard broke out of tree plugins
** Also affects: networking-midonet
Importance: Undecided
Status: New
** Changed in: networking-midonet
Importance: Undecided => Critical
** Changed in: networking-midonet
Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto)
** Tags added: gate-failure
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611533
Title:
ml2 transaction_guard broke out of tree plugins
Status in networking-midonet:
New
Status in neutron:
In Progress
Bug description:
recent change [1] broke l3 plugin for networking-midonet.
[1] I9924600c57648f7eccaa5abb6979419d9547a2ff
l3 plugins for networking-odl and dragonflow seem to have similar code
and would be affected too.
eg.
http://logs.openstack.org/87/199387/36/check/gate-tempest-dsvm-networking-midonet-ml2/ceb0331/logs/q-svc.txt.gz?level=TRACE
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
[req-af588d02-2944-411f-aa22-eafca4fdabeb
tempest-TestSecurityGroupsBasicOps-509565194 -] remove_router_interface failed:
No details.
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource ectxt.value =
e.inner_exc
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in
__exit__
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
self.force_reraise()
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource return
f(*args, **kwargs)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 217, in _handle_action
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource ret_value =
getattr(self._plugin, name)(*arg_list, **kwargs)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_log/helpers.py", line 48, in
wrapper
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource return
method(*args, **kwargs)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/networking-midonet/midonet/neutron/services/l3/l3_midonet.py",
line 190, in remove_router_interface
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource context,
router_id, interface_info)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/db/l3_db.py", line 1756, in
remove_router_interface
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource context,
router_id, interface_info)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/db/l3_db.py", line 924, in
remove_router_interface
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource context,
router_id, subnet_id, device_owner)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/db/l3_db.py", line 901, in
_remove_interface_by_subnet
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
l3_port_check=False)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/common/utils.py", line 611, in inner
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource raise
RuntimeError(_("Method cannot be called within a "
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource RuntimeError:
Method cannot be called within a transaction.
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource
[req-c9ae4bf8-2baf-4327-be58-bb3006b4d9c9
tempest-TestSecurityGroupsBasicOps-2112515119 -] delete failed: No details.
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.re
[Yahoo-eng-team] [Bug 1609213] Re: gate-neutron-fwaas-dsvm-tempest failure
*** This bug is a duplicate of bug 1608401 *** https://bugs.launchpad.net/bugs/1608401 Reviewed: https://review.openstack.org/350362 Committed: https://git.openstack.org/cgit/openstack/neutron-fwaas/commit/?id=ea23bbc3ee4cc90280375153d13f59cb85ffe6f2 Submitter: Jenkins Branch:master commit ea23bbc3ee4cc90280375153d13f59cb85ffe6f2 Author: YAMAMOTO Takashi Date: Wed Aug 3 12:25:08 2016 +0900 devstack: Don't bother to have our own l3 agent config file Instead, simply add our config to Q_L3_CONF_FILE. Closes-Bug: #1608401 Closes-Bug: #1609213 Depends-On: I630969b3556bcffba506cab02a09cc83f4430c88 Change-Id: Ibd186a81c5483ede3f1286e165efb55225198c51 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1609213 Title: gate-neutron-fwaas-dsvm-tempest failure Status in devstack: In Progress Status in neutron: Fix Released Bug description: eg. http://logs.openstack.org/41/349341/2/check/gate-neutron-fwaas-dsvm- tempest/42b33ce/logs/screen-q-l3.txt.gz + functions-common:_run_process:1440 : [[ -n '' ]] + functions-common:_run_process:1443 : setsid /usr/local/bin/neutron-l3-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/l3_agent.ini --config-file + functions-common:_run_process:1443 : echo 22185 + functions-common:_run_process:1447 : exit 0 usage: neutron-l3-agent [-h] [--config-dir DIR] [--config-file PATH] [--debug] [--log-config-append PATH] [--log-date-format DATE_FORMAT] [--log-dir LOG_DIR] [--log-file PATH] [--nodebug] [--nouse-syslog] [--noverbose] [--nowatch-log-file] [--state_path STATE_PATH] [--syslog-log-facility SYSLOG_LOG_FACILITY] [--use-syslog] [--verbose] [--version] [--watch-log-file] neutron-l3-agent: error: argument --config-file: expected one argument To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1609213/+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 1611533] [NEW] ml2 transaction_guard broke out of tree plugins
Public bug reported:
recent change [1] broke l3 plugin for networking-midonet.
[1] I9924600c57648f7eccaa5abb6979419d9547a2ff
l3 plugins for networking-odl and dragonflow seem to have similar code
and would be affected too.
eg.
http://logs.openstack.org/87/199387/36/check/gate-tempest-dsvm-networking-midonet-ml2/ceb0331/logs/q-svc.txt.gz?level=TRACE
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
[req-af588d02-2944-411f-aa22-eafca4fdabeb
tempest-TestSecurityGroupsBasicOps-509565194 -] remove_router_interface failed:
No details.
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource ectxt.value =
e.inner_exc
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in
__exit__
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
self.force_reraise()
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in
force_reraise
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 139, in wrapper
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource return f(*args,
**kwargs)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 217, in _handle_action
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource ret_value =
getattr(self._plugin, name)(*arg_list, **kwargs)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_log/helpers.py", line 48, in
wrapper
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource return
method(*args, **kwargs)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/networking-midonet/midonet/neutron/services/l3/l3_midonet.py",
line 190, in remove_router_interface
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource context,
router_id, interface_info)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/db/l3_db.py", line 1756, in
remove_router_interface
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource context,
router_id, interface_info)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/db/l3_db.py", line 924, in
remove_router_interface
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource context,
router_id, subnet_id, device_owner)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/db/l3_db.py", line 901, in
_remove_interface_by_subnet
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
l3_port_check=False)
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/common/utils.py", line 611, in inner
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource raise
RuntimeError(_("Method cannot be called within a "
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource RuntimeError:
Method cannot be called within a transaction.
2016-08-09 12:31:57.844 25876 ERROR neutron.api.v2.resource
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource
[req-c9ae4bf8-2baf-4327-be58-bb3006b4d9c9
tempest-TestSecurityGroupsBasicOps-2112515119 -] delete failed: No details.
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/resource.py", line 79, in resource
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource File
"/opt/stack/new/neutron/neutron/api/v2/base.py", line 522, in delete
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource return
self._delete(request, id, **kwargs)
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 151, in wrapper
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource ectxt.value =
e.inner_exc
2016-08-09 12:31:58.293 25876 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-package
[Yahoo-eng-team] [Bug 1609184] Re: ML2: Allow retry on db error by precommit
Reviewed: https://review.openstack.org/350315 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7e69891412e967a8509fe6877501114e148f7518 Submitter: Jenkins Branch:master commit 7e69891412e967a8509fe6877501114e148f7518 Author: Isaku Yamahata Date: Tue Aug 2 15:51:18 2016 -0700 ml2: allow retry on retriabable db error by precommit Db retriable error by precommit can be recovered with upper layer by retry instead of converting into ML2MechanismDriverError. Raise retriable db error instead of swallowing it and let upper layer to retry. Due to concurrency, db error by precommit is sometimes inevitable. precommit may issue db transactions depending on mechanism driver, Some operations on e.g. subnet, routers, touches many other resources (e.g. ip allocation, ports) in single db transaction as well. And background operation by mechanism driver (e.g. background sync, monitoring resources periodically, etc) may touch those db tables with other order. Change-Id: Ifc670c1eb5801934bf46fdc23a7721ce4c2cfa6c Closes-Bug: #1609184 Closes-Bug: #1609149 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1609184 Title: ML2: Allow retry on db error by precommit Status in neutron: Fix Released Bug description: Allow retry on db retriable error by precommit mothod. Currently ML2 driver manager swallows all exceptions by mechanism driver and return errors to user. However, there are classes of retriable db errors(DBDeadlock, taleDataError, DDuplicateEntry, TretryRequest). With those error by precommit, it's better to allow neutron.api.v2.base.Controller to retry request. Sometimes, those db error by precommit is inevitable. Especially subnet operation touches many resources(port, ip address, etc). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1609184/+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 1611400] Re: pep8 job failing with F821 in test_l3
Reviewed: https://review.openstack.org/352941
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=a200f4a7b670abd7f6fc59847782719057bfe6ef
Submitter: Jenkins
Branch:master
commit a200f4a7b670abd7f6fc59847782719057bfe6ef
Author: Ihar Hrachyshka
Date: Tue Aug 9 16:32:33 2016 +0200
pep8: fixed F821 violation in a unit test
The _ symbol should have been imported explicitly. Actually, there is no
use case for translatable messages in unit tests, it's just a waste of
translator time to mark it as such. The patch removes the translation
marker for good.
Change-Id: I76bef710a1030dcb4eb35778ebf44ed600016f17
Closes-Bug: #1611400
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611400
Title:
pep8 job failing with F821 in test_l3
Status in neutron:
Fix Released
Bug description:
New flake8 was released today, and probably broke neutron pep8 job
with:
pep8 runtests: commands[2] | flake8
./neutron/tests/unit/extensions/test_l3.py:2931:19: F821 undefined name '_'
msg = _("Failure mocking...")
^
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1611400/+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 1611509] Re: lbaasv2 doesn't support "https" keystone endpoint
** Project changed: neutron => octavia
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611509
Title:
lbaasv2 doesn't support "https" keystone endpoint
Status in octavia:
New
Bug description:
I am trying to enable lbaasv2 using octavia driver in one of our mitaka
deployment. And we got the error
{code}
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
[req-87d34869-7fec-4269-894b-81a4f1771736 6928cf223a0948699fab55612678cfdc
10d7de26713241a2b623f2028c77e8eb - - -] There was an error in the driver
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin Traceback (most recent call last):
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
line 489, in _call_driver_operation
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin driver_method(context, db_entity)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 118, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
args[0].failed_completion(args[1], args[2])
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin self.force_reraise()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin six.reraise(self.type_,
self.value, self.tb)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 108, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin r = func(*args, **kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 220, in create
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
self.driver.req.post(self._url(lb), args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 150, in post
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return self.request('POST', url,
args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 131, in request
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token =
self.auth_session.get_token()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 618, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
(self.get_auth_headers(auth) or {}).get('X-Auth-Token')
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 597, in
get_auth_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return auth.get_headers(self,
**kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/plugin.py", line 84, in
get_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token = self.get_token(session)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py", line 89, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
self.get_access(session).auth_token
neutron
[Yahoo-eng-team] [Bug 1611513] [NEW] ip_lib: Add support for 'Flush' command in iproute
Public bug reported: This would be enhancement to the ip_lib iproute library to provide additional support for the 'Flush' command that is not available right now. This is a dependency for a fix in DVR to cleanup the gateway rules. Ref: Bug: #1599287 ** Affects: neutron Importance: Undecided Assignee: Swaminathan Vasudevan (swaminathan-vasudevan) Status: In Progress ** Tags: l3-dvr-backlog ** Summary changed: - ip_lib: Add support for 'Flush' command for iproute + ip_lib: Add support for 'Flush' command in iproute -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611513 Title: ip_lib: Add support for 'Flush' command in iproute Status in neutron: In Progress Bug description: This would be enhancement to the ip_lib iproute library to provide additional support for the 'Flush' command that is not available right now. This is a dependency for a fix in DVR to cleanup the gateway rules. Ref: Bug: #1599287 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611513/+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 1611509] [NEW] lbaasv2 doesn't support "https" keystone endpoint
Public bug reported:
I am trying to enable lbaasv2 using octavia driver in one of our mitaka
deployment. And we got the error
{code}
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
[req-87d34869-7fec-4269-894b-81a4f1771736 6928cf223a0948699fab55612678cfdc
10d7de26713241a2b623f2028c77e8eb - - -] There was an error in the driver
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin Traceback (most recent call last):
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
line 489, in _call_driver_operation
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin driver_method(context, db_entity)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 118, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
args[0].failed_completion(args[1], args[2])
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin self.force_reraise()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin six.reraise(self.type_,
self.value, self.tb)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 108, in func_wrapper
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin r = func(*args, **kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 220, in create
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin
self.driver.req.post(self._url(lb), args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 150, in post
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return self.request('POST', url,
args)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/neutron_lbaas/drivers/octavia/driver.py",
line 131, in request
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token =
self.auth_session.get_token()
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 618, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
(self.get_auth_headers(auth) or {}).get('X-Auth-Token')
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 597, in
get_auth_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return auth.get_headers(self,
**kwargs)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/plugin.py", line 84, in
get_headers
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin token = self.get_token(session)
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py", line 89, in
get_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin return
self.get_access(session).auth_token
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin File
"/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py", line 135, in
get_access
neutron-server.log:2016-08-09 20:15:25.462 74450 ERROR
neutron_lbaas.services.loadbalancer.plugin self.auth_ref =
self.get_auth_ref(session)
neutr
[Yahoo-eng-team] [Bug 1607412] Re: gate-grenade-dsvm-neutron-multinode fails server build on newton side with "Unrecognized attribute(s) 'dns_name'"
** Changed in: nova Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1607412 Title: gate-grenade-dsvm-neutron-multinode fails server build on newton side with "Unrecognized attribute(s) 'dns_name'" Status in neutron: Fix Released Status in OpenStack Compute (nova): Invalid Bug description: Saw this here in the gate: http://logs.openstack.org/62/324262/3/gate/gate-grenade-dsvm-neutron- multinode/9af98c8/logs/new/screen-n-cond.txt.gz?level=TRACE#_2016-07-25_10_24_50_160 2016-07-25 10:24:50.160 3162 ERROR nova.scheduler.utils [req-3b0678a2 -4d9c-462e-97a5-913dc36fab81 tempest-ServerAddressesTestJSON-491230418 tempest-ServerAddressesTestJSON-491230418] [instance: f0e2b7fc-d88a- 4e2d-9bc8-adcb81efc0dc] Error from last host: ubuntu-trusty-2-node- rax-ord-2845415-108069 (node ubuntu-trusty-2-node-rax- ord-2845415-108069): [u'Traceback (most recent call last):\n', u' File "/opt/stack/old/nova/nova/compute/manager.py", line 1926, in _do_build_and_run_instance\nfilter_properties)\n', u' File "/opt/stack/old/nova/nova/compute/manager.py", line 2116, in _build_and_run_instance\ninstance_uuid=instance.uuid, reason=six.text_type(e))\n', u"RescheduledException: Build of instance f0e2b7fc-d88a-4e2d-9bc8-adcb81efc0dc was re-scheduled: Unrecognized attribute(s) 'dns_name'\nNeutron server returns request_ids: ['req- d96c687a-3971-4d8d-bb42-08661632f7c8']\n"] There are only 3 hits in 7 days in logstash, but it seems like there should be more than this (we might also be backed up on logstash results): http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22RescheduledException%3A%20Build%20of%20instance%5C%22%20AND%20message%3A%5C%22was %20re- scheduled%3A%20Unrecognized%20attribute(s)%20'dns_name'%5C%22%20AND%20tags%3A%5C%22screen-n-cond.txt%5C%22&from=7d To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1607412/+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 1611490] [NEW] api-ref: make example URLs consistent
Public bug reported: This bug covers the api-ref, namely, the stuff in api-ref/source in the glance repo. For consistency, make sure that example URLs for openstack components are in the form: project.openstack.example.org So, for example, an example image-list call to Glance would use a URL written like this: http://glance.openstack.example.org/v2/images ** Affects: glance Importance: Low Status: Triaged ** Tags: api-ref documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1611490 Title: api-ref: make example URLs consistent Status in Glance: Triaged Bug description: This bug covers the api-ref, namely, the stuff in api-ref/source in the glance repo. For consistency, make sure that example URLs for openstack components are in the form: project.openstack.example.org So, for example, an example image-list call to Glance would use a URL written like this: http://glance.openstack.example.org/v2/images To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1611490/+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 1611489] [NEW] dev-docs: make example URLs consistent
Public bug reported: This bug covers the dev-docs, namely, the stuff in doc/source in the glance repo. For consistency, make sure that example URLs for openstack components are in the form: project.openstack.example.org So, for example, an example image-list call to Glance would use a URL written like this: http://glance.openstack.example.org/v2/images ** Affects: glance Importance: Low Status: Triaged ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1611489 Title: dev-docs: make example URLs consistent Status in Glance: Triaged Bug description: This bug covers the dev-docs, namely, the stuff in doc/source in the glance repo. For consistency, make sure that example URLs for openstack components are in the form: project.openstack.example.org So, for example, an example image-list call to Glance would use a URL written like this: http://glance.openstack.example.org/v2/images To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1611489/+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 1611380] Re: libvirt: drop py26 compat for get_console_output
These are the kind of bugs that mostly just get lost in the system, as they are personal todo list items. I'd rather just see the patch for something like this. ** Changed in: nova Status: New => Opinion ** Changed in: nova Importance: Undecided => Wishlist -- 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/1611380 Title: libvirt: drop py26 compat for get_console_output Status in OpenStack Compute (nova): Opinion Bug description: There is py26 compatibility code in the libvirt driver to query the console output [1]. We can drop that as we have py27 as minimum. At the same time we can refactor that method a little to make it easier to read. References: [1] https://github.com/openstack/nova/blob/b2100015ac6f98c68451cb8827687866fe695452/nova/virt/libvirt/driver.py#L2701-L2704 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611380/+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 1611491] [NEW] api-docs: make example URLs consistent
Public bug reported: This bug covers the narrative-style API docs, namely, the stuff in specs/api in the glance-specs repo. For consistency, make sure that example URLs for openstack components are in the form: project.openstack.example.org So, for example, an example image-list call to Glance would use a URL written like this: http://glance.openstack.example.org/v2/images ** Affects: glance Importance: Low Status: Triaged ** Tags: documentation -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1611491 Title: api-docs: make example URLs consistent Status in Glance: Triaged Bug description: This bug covers the narrative-style API docs, namely, the stuff in specs/api in the glance-specs repo. For consistency, make sure that example URLs for openstack components are in the form: project.openstack.example.org So, for example, an example image-list call to Glance would use a URL written like this: http://glance.openstack.example.org/v2/images To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1611491/+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 1611458] [NEW] MIgration incorrectly compares None as greater than any time
Public bug reported: Description === The code in nova/compute/resource_tracker.py was updated in commit e5269b3a8f95c41283a9e6109835142586fe62a6 to better handle the comparison of potential None values in order to make the code Python 3 compatible. Unfortunately, the logic is incorrect, and will consider a migration with a None value for updated_at as more recent than a migration with a non-None datetime value. Steps to reproduce == The easiest way to reproduce is to run the unit test here: https://review.openstack.org/#/c/350319/8/nova/tests/unit/compute/test_tracker.py@1827 Note that it now has to *expect* the None value to be preferred over an actual value Expected result === Any migration that has been updated is always more recent than one that hasn't, so I would expect that any None-valued migration would not be selected over an actual date. Actual result = The None value is selected over one that has been updated. Environment === Nova master ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) => Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1611458 Title: MIgration incorrectly compares None as greater than any time Status in OpenStack Compute (nova): New Bug description: Description === The code in nova/compute/resource_tracker.py was updated in commit e5269b3a8f95c41283a9e6109835142586fe62a6 to better handle the comparison of potential None values in order to make the code Python 3 compatible. Unfortunately, the logic is incorrect, and will consider a migration with a None value for updated_at as more recent than a migration with a non-None datetime value. Steps to reproduce == The easiest way to reproduce is to run the unit test here: https://review.openstack.org/#/c/350319/8/nova/tests/unit/compute/test_tracker.py@1827 Note that it now has to *expect* the None value to be preferred over an actual value Expected result === Any migration that has been updated is always more recent than one that hasn't, so I would expect that any None-valued migration would not be selected over an actual date. Actual result = The None value is selected over one that has been updated. Environment === Nova master To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611458/+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 1611447] [NEW] Nova showCellData request returns an "Unexpected API Error"
Public bug reported:
It has been reproduced against single-node devstack with cells enabled:
ENABLED_SERVICES=c-api,c-bak,c-sch,c-vol,cinder,dstat,g-api,g-reg,horizon,key,mysql,n-api,n-cell,n-cond,n-cpu,n-crt,n-net,n-obj,n-sch,rabbit,s-account,s-container,s-object,s-proxy,tempest
nova.conf:
[DEFAULT]
...
transport_url = rabbit://stackrabbit:secretrabbit@127.0.0.1:5672/
...
[cells]
name = region
cell_type = api
enable = True
nova-cells.conf:
[DEFAULT]
...
transport_url = rabbit://stackrabbit:secretrabbit@127.0.0.1:5672/
...
[cells]
name = child
cell_type = compute
enable = True
The http://developer.openstack.org/api-ref-compute-v2.1.html#listCells
request has been successful and returned:
stack@ubuntu:~$ TOKEN=$(openstack token issue | awk '/ id /{print $4}')
stack@ubuntu:~$ NOVA_ENDPOINT=$(openstack endpoint show nova | awk '/ publicurl
/{print $4}')
stack@ubuntu:~$ TENANT_ID=$(openstack project show admin | awk '/ id /{print
$4}')
stack@ubuntu:~$ curl --include --request GET -H "X-Auth-Token: $TOKEN" -H
"Content-Type: application/json" $NOVA_ENDPOINT/$TENANT_ID/os-cells
HTTP/1.1 200 OK
Content-Length: 117
Content-Type: application/json
Openstack-Api-Version: compute 2.1
X-Openstack-Nova-Api-Version: 2.1
Vary: OpenStack-API-Version
Vary: X-OpenStack-Nova-API-Version
X-Compute-Request-Id: req-9d5ea58a-256f-42d3-bca6-c388e632ca02
Date: Tue, 09 Aug 2016 15:38:31 GMT
{"cells": [{"username": "stackrabbit", "rpc_host": "127.0.0.1", "type":
"child", "name": "child", "rpc_port": 5672}]}
(It's unexpected, that parent cell is absent both here and in 'cells'
table of Nova DB, but can suggest that single-node configuration may
affect it)
After that I tried to send the
http://developer.openstack.org/api-ref-compute-v2.1.html#showCellData request.
The UUID of cell expected by this request isn't returned by previous one, and
the 'uuid' field is absent in 'cells' Nova DB table:
mysql> select * from cells;
+-++++-+---+--+---+---+-+-+
| created_at | updated_at | deleted_at | id | api_url | weight_offset
| weight_scale | name | is_parent | deleted | transport_url
|
+-++++-+---+--+---+---+-+-+
| 2016-08-08 15:26:43 | NULL | NULL | 1 | NULL| 0
|1 | child | 0 | 0 |
rabbit://stackrabbit:secretrabbit@127.0.0.1:5672,stackrabbit:secretrabbit@127.0.0.1:5672/child_cell
|
+-++++-+---+--+---+---+-+-+
1 row in set (0.00 sec)
So, let's try to get cell's info by its name, and the result is:
stack@ubuntu:~/devstack$ curl --include --request GET -H "X-Auth-Token: $TOKEN"
-H "Content-Type: application/json" $NOVA_ENDPOINT/$TENANT_ID/os-cells/child
HTTP/1.1 500 Internal Server Error
Openstack-Api-Version: compute 2.1
X-Openstack-Nova-Api-Version: 2.1
Vary: OpenStack-API-Versio
Vary: X-OpenStack-Nova-API-Version
Content-Type: application/json; charset=UTF-8
Content-Length: 216
X-Compute-Request-Id: req-05f0f93a-c9ad-403b-ae3f-639b5f64d659
Date: Tue, 09 Aug 2016 15:40:32 GMT
{"computeFault": {"message": "Unexpected API Error. Please report this
at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.\n",
"code": 500}}
And there is n-api.log trace:
2016-08-09 11:39:32.215 24100 DEBUG nova.api.openstack.wsgi
[req-05f0f93a-c9ad-403b-ae3f-639b5f64d659 admin admin] Calling method '>'
_process_stack /opt/stack/new/nova/nova/api/openstack/wsgi.py:636
2016-08-09 11:39:32.217 24100 DEBUG oslo_messaging._drivers.amqpdriver
[req-05f0f93a-c9ad-403b-ae3f-639b5f64d659 admin admin] CALL msg_id:
b34cb4c869444efba1ba76844208cfba exchange 'nova' topic 'cells' _send
/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py:448
2016-08-09 11:40:32.223 24100 ERROR nova.api.openstack.extensions
[req-05f0f93a-c9ad-403b-ae3f-639b5f64d659 admin admin] Unexpected exception in
API method
2016-08-09 11:40:32.223 24100 ERROR nova.api.openstack.extensions Traceback
(most recent call last):
2016-08-09 11:40:32.223 24100 ERROR nova.api.openstack.extensions File
"/opt/stack/new/nova/nova/api/openstack/extensions.py", line 338, in wrapped
2016-08-09 11:40:32.223 24100 ERROR nova.api.openstack.extensions return
f(*args, **kwargs)
2016-08-09 11:40:32.223 24100 ERROR nova.api.openstack.extensions File
"/opt/stack/new/nova/nova/api/openstack/common.py", line 530, in
[Yahoo-eng-team] [Bug 1611443] [NEW] nova-scheduler doesn't account for create-new-volume disk space when using ceph
Public bug reported: Description === It seems that nova-scheduler may not account for disk space appropriately when creating a new instance using a new cinder volume. We have ceph backing cinder and glance, so in theory if we spin up a new instance (boot from image create new volume) that is backed by ceph, the scheduler should only take ceph disk space into account. However, it seems like it may take local disk space on compute nodes (we have this being used for ephemeral disks if not using cinder) when scheduling. This causes an issue if we have limited local disk space but plenty of storage space in ceph, and we try to spin up a new instance fully backed by ceph but based on a flavor with root disk specification too large for local nodes (even though this gets overwritten when spinning up on new volume since you manually specify volume size). The instance fails to boot. Steps to reproduce == 1. Environment uses ephemeral storage local to compute nodes, ceph backs cinder/glance. 2. Create a flavor that has root disk size > available ephemeral storage on compute nodes. 3. Launch instance from image (create new volume) so it's fully backed by ceph and it should not need the ephemeral storage on compute nodes, using the previously created flavor. Specify a disk size for new volume that is smaller than available ceph space but larger than ephemeral disk 4. Instance will fail to launch and drop errors pasted below. Now, 1. Create another flavor with root disk size < available ephemeral storage on compute nodes 2. Launch instance again using same settings, so still create new volume and ensure volume is greater in size than ephemeral space. 3. Note instance launches and works no issue. This shows that the ephemeral disk space specified on flavor has no real affect on ability to spin up the instance outside of initial scheduling, because that space isn't actually used when spinning up an instance where cinder/glance is backed by ceph. The only thing is it is taken into consideration during scheduling and it will fail to try and create the instance if there isn't enough ephemeral space. Logs = <180>Aug 9 15:55:37 controller01 nova-scheduler: 2016-08-09 15:55:37.261 155487 WARNING nova.scheduler.host_manager [req-c10f09a5-2909-4f84-bb01-2ff0114f2a43 9c9903e9d5d24411abfc6d9867ab054e 3bbe4dd24a5f497ca081d5b22011d39e - - -] Host compute02.gsrt.paloaltonetworks.local has more disk space than database expected (116gb > 89gb) <182>Aug 9 15:55:37 controller01 nova-scheduler: 2016-08-09 15:55:37.262 155487 INFO nova.filters [req-c10f09a5-2909-4f84-bb01-2ff0114f2a43 9c9903e9d5d24411abfc6d9867ab054e 3bbe4dd24a5f497ca081d5b22011d39e - - -] Filter DiskFilter returned 0 hosts <182>Aug 9 15:55:37 controller01 nova-scheduler: 2016-08-09 15:55:37.263 155487 INFO nova.filters [req-c10f09a5-2909-4f84-bb01-2ff0114f2a43 9c9903e9d5d24411abfc6d9867ab054e 3bbe4dd24a5f497ca081d5b22011d39e - - -] Filtering removed all hosts for the request with reservation ID 'r-4ziwar65' and instance ID '6034d716-fe3b-4d41-a564-47b36ae441e5'. Filter results: ['DifferentHostFilter: (start: 2, end: 2)', 'RetryFilter: (start: 2, end: 2)', 'AvailabilityZoneFilter: (start: 2, end: 2)', 'RamFilter: (start: 2, end: 2)', 'CoreFilter: (start: 2, end: 2)', 'DiskFilter: (start: 2, end: 0)'] <180>Aug 9 15:55:37 controller01 nova-conductor: 2016-08-09 15:55:37.266 155590 WARNING nova.scheduler.utils [req-c10f09a5-2909-4f84-bb01-2ff0114f2a43 9c9903e9d5d24411abfc6d9867ab054e 3bbe4dd24a5f497ca081d5b22011d39e - - -] Failed to compute_task_build_instances: No valid host was found. There are not enough hosts available. Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 142, in inner return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/nova/scheduler/manager.py", line 84, in select_destinations filter_properties) File "/usr/lib/python2.7/dist-packages/nova/scheduler/filter_scheduler.py", line 90, in select_destinations raise exception.NoValidHost(reason=reason) NoValidHost: No valid host was found. There are not enough hosts available. <180>Aug 9 15:55:37 controller01 nova-conductor: 2016-08-09 15:55:37.267 155590 WARNING nova.scheduler.utils [req-c10f09a5-2909-4f84-bb01-2ff0114f2a43 9c9903e9d5d24411abfc6d9867ab054e 3bbe4dd24a5f497ca081d5b22011d39e - - -] [instance: 6034d716-fe3b-4d41-a564-47b36ae441e5] Setting instance to ERROR state. Expected Result === If ephemeral disk space will not be utilized or touched as part of instance launching, it should not be used as part of diskfilter / scheduling as it may lead to unnecessary errors. Actual Result = Cannot launch instance because scheduler fails find a valid host (even if enough disk space is available) Environment === Liberty based, MOS 8.0. It looks like Mirantis has some of their own packages for nova-scheduler,
[Yahoo-eng-team] [Bug 1492773] Re: there are a lot of warn log "No DHCP agents available, skipping rescheduling""
Reviewed: https://review.openstack.org/349727 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4cb60587a4a28f63b40fae2d56f3f1bf22394af9 Submitter: Jenkins Branch:master commit 4cb60587a4a28f63b40fae2d56f3f1bf22394af9 Author: john_a_joyce Date: Mon Aug 1 18:12:57 2016 -0400 Suppresses a warning when no agents are configured Change-Id: Ia8dbf83ce1cdd66d1e0a3e42e8ce216377a61adf Closes-Bug: #1492773 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1492773 Title: there are a lot of warn log "No DHCP agents available, skipping rescheduling"" Status in neutron: Fix Released Bug description: when no agent is active, there are a lot of warn log "No DHCP agents available, skipping rescheduling", which are so many that it is difficult to read log To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1492773/+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 1490743] Re: Attempt to call strftime on a str fails revocation_list
** Changed in: keystone Status: Expired => Fix Committed -- 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/1490743 Title: Attempt to call strftime on a str fails revocation_list Status in OpenStack Identity (keystone): Fix Committed Bug description: This bug is nearly identical to the old bug https://bugs.launchpad.net/keystone/+bug/1285871 , same symptom and nearly identical code . It is currently causing barbican to fail for us. 2015-08-21 03:17:05.244 22742 ERROR keystone.common.wsgi [-] 'str' object has no a ttribute 'strftime' 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi Traceback (most recent ca ll last): 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/wsgi.py", line 239, in __call__ 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi result = method(context, **params) 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 158, in inner 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi return f(self, context, *args, **kwargs) 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/keystone/auth/controllers.py", line 549, in revocation_list 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi t['expires'] = timeutils.isotime(expires) 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi File "/usr/lib/python2.7/site-packages/oslo_utils/timeutils.py", line 52, in isotime 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi st = at.strftime(_ISO8601_TIME_FORMAT 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi AttributeError: 'str' object has no attribute 'strftime' 2015-08-21 03:17:05.244 22742 TRACE keystone.common.wsgi 2015-08-21 03:17:05.263 22742 INFO eventlet.wsgi.server [-] 100.72.132.128,10.50.249.37 - - [21/Aug/2015 03:17:05] "GET /v3/auth/tokens/OS-PKI/revoked HTTP/1.1" 500 470 0.063453 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1490743/+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 1611400] [NEW] pep8 job failing with new flake8 3.0.4
Public bug reported:
New flake8 was released today, and probably broke neutron pep8 job with:
pep8 runtests: commands[2] | flake8
./neutron/tests/unit/extensions/test_l3.py:2931:19: F821 undefined name '_'
msg = _("Failure mocking...")
^
** Affects: neutron
Importance: High
Assignee: Ihar Hrachyshka (ihar-hrachyshka)
Status: New
** Tags: gate-failure
** Changed in: neutron
Importance: Undecided => High
** Changed in: neutron
Assignee: (unassigned) => Ihar Hrachyshka (ihar-hrachyshka)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1611400
Title:
pep8 job failing with new flake8 3.0.4
Status in neutron:
New
Bug description:
New flake8 was released today, and probably broke neutron pep8 job
with:
pep8 runtests: commands[2] | flake8
./neutron/tests/unit/extensions/test_l3.py:2931:19: F821 undefined name '_'
msg = _("Failure mocking...")
^
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1611400/+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 1570171] Re: ip_conntrack only delete one direction entry
Reviewed: https://review.openstack.org/318679 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4a7e9ce6849e6fb30d42edbf858fd4235954 Submitter: Jenkins Branch:master commit 4a7e9ce6849e6fb30d42edbf858fd4235954 Author: yujie Date: Fri Aug 5 10:41:08 2016 +0800 Delete conntrack entry with remote_ip on the other direction Patch [1] is incomplete for deleting conntrack entries with remote_ip set. This patch fixes the defect. [1]: I44d6bd0c2465294b557fd01566b72e016d34bba3 Change-Id: I31c579dbe28e4e8e824912b695eaba9475cf0095 Closes-Bug: #1570171 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1570171 Title: ip_conntrack only delete one direction entry Status in neutron: Fix Released Bug description: The test was used neutron master. I use devstack create one net and two vm on this net, vm1 fixed-ip is: 10.0.0.3, vm2 fixed-ip is: 10.0.0.4. Both vm bind sg1: rule1: ingress, any protocol, any remote ip prefix rule2: egress, any protocol, any remote ip prefix 1. vm1 ping vm2 and vm2 ping vm1, the conntrack will be: $ sudo conntrack -L -p icmp icmp 1 29 src=10.0.0.3 dst=10.0.0.4 type=8 code=0 id=21761 src=10.0.0.4 dst=10.0.0.3 type=0 code=0 id=21761 mark=0 zone=4 use=1 icmp 1 29 src=10.0.0.4 dst=10.0.0.3 type=8 code=0 id=22017 src=10.0.0.3 dst=10.0.0.4 type=0 code=0 id=22017 mark=0 zone=4 use=1 icmp 1 29 src=10.0.0.3 dst=10.0.0.4 type=8 code=0 id=21761 src=10.0.0.4 dst=10.0.0.3 type=0 code=0 id=21761 mark=0 zone=3 use=1 icmp 1 29 src=10.0.0.4 dst=10.0.0.3 type=8 code=0 id=22017 src=10.0.0.3 dst=10.0.0.4 type=0 code=0 id=22017 mark=0 zone=3 use=1 conntrack v1.4.1 (conntrack-tools): 4 flow entries have been shown. 2. vm2 unbind sg1, the conntrack turn to: $ sudo conntrack -L -p icmp icmp 1 29 src=10.0.0.3 dst=10.0.0.4 type=8 code=0 id=21761 src=10.0.0.4 dst=10.0.0.3 type=0 code=0 id=21761 mark=0 zone=4 use=1 icmp 1 29 src=10.0.0.4 dst=10.0.0.3 type=8 code=0 id=22017 src=10.0.0.3 dst=10.0.0.4 type=0 code=0 id=22017 mark=0 zone=4 use=1 icmp 1 29 src=10.0.0.4 dst=10.0.0.3 type=8 code=0 id=22017 src=10.0.0.3 dst=10.0.0.4 type=0 code=0 id=22017 mark=0 zone=3 use=1 conntrack v1.4.1 (conntrack-tools): 3 flow entries have been shown. Now vm1 could not connect vm2, which is right; but vm2 could still ping vm1 successfully. The entry "icmp 1 29 src=10.0.0.4 dst=10.0.0.3 type=8 code=0 id=22017 src=10.0.0.3 dst=10.0.0.4 type=0 code=0 id=22017 mark=0 zone=3 use=1" was not delete as expect. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1570171/+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 1610960] Re: Invalid input for external_gateway_info. Reason: '' is not a valid UUID.
** No longer affects: neutron
** No longer affects: tempest
** Changed in: grenade
Status: New => Invalid
** Changed in: manila
Status: New => Invalid
** Changed in: ironic
Status: Confirmed => Invalid
** Changed in: os-client-config
Status: New => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1610960
Title:
Invalid input for external_gateway_info. Reason: '' is not a valid
UUID.
Status in grenade:
Invalid
Status in Ironic:
Invalid
Status in Manila:
Invalid
Status in os-client-config:
Confirmed
Bug description:
Currently grenade gate is completely busted with:
ft14.1: setUpClass
(tempest.api.identity.admin.v3.test_domains.DomainsTestJSON)_StringException:
Traceback (most recent call last):
File "tempest/test.py", line 273, in setUpClass
six.reraise(etype, value, trace)
File "tempest/test.py", line 261, in setUpClass
cls.setup_credentials()
File "tempest/test.py", line 361, in setup_credentials
credential_type=credentials_type)
File "tempest/test.py", line 535, in get_client_manager
creds = getattr(cred_provider, credentials_method)()
File "tempest/common/dynamic_creds.py", line 305, in get_primary_creds
return self.get_credentials('primary')
File "tempest/common/dynamic_creds.py", line 297, in get_credentials
credentials.tenant_id)
File "tempest/common/dynamic_creds.py", line 214, in
_create_network_resources
router = self._create_router(router_name, tenant_id)
File "tempest/common/dynamic_creds.py", line 273, in _create_router
tenant_id=tenant_id)
File "tempest/lib/services/network/routers_client.py", line 26, in
create_router
return self.create_resource(uri, post_body)
File "tempest/lib/services/network/base.py", line 60, in create_resource
resp, body = self.post(req_uri, req_post_data)
File "tempest/lib/common/rest_client.py", line 273, in post
return self.request('POST', url, extra_headers, headers, body, chunked)
File "tempest/lib/common/rest_client.py", line 667, in request
resp, resp_body)
File "tempest/lib/common/rest_client.py", line 770, in _error_checker
raise exceptions.BadRequest(resp_body, resp=resp)
tempest.lib.exceptions.BadRequest: Bad request
Details: {u'type': u'HTTPBadRequest', u'detail': u'', u'message': u"Invalid
input for external_gateway_info. Reason: '' is not a valid UUID."}
http://logs.openstack.org/26/352326/1/check/gate-grenade-dsvm-neutron-
ubuntu-trusty/acf0516/console.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/grenade/+bug/1610960/+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 1611389] [NEW] 500 error when using unicode in url
Public bug reported: ENVARIMENT: devstack, master 09.08.2016, glance send request: curl -H "X-Auth-Token: token" -H "Content-Type: text/html; charset=UTF-8" -X GET http://host:port/v2/images?name=ввв actual result: 500 error, log http://paste.openstack.org/show/552442/ ** Affects: glance Importance: Undecided Assignee: Darja Shakhray (dshakhray) Status: New ** Changed in: glance Assignee: (unassigned) => Darja Shakhray (dshakhray) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1611389 Title: 500 error when using unicode in url Status in Glance: New Bug description: ENVARIMENT: devstack, master 09.08.2016, glance send request: curl -H "X-Auth-Token: token" -H "Content-Type: text/html; charset=UTF-8" -X GET http://host:port/v2/images?name=ввв actual result: 500 error, log http://paste.openstack.org/show/552442/ To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1611389/+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 1611380] [NEW] libvirt: drop py26 compat for get_console_output
Public bug reported: There is py26 compatibility code in the libvirt driver to query the console output [1]. We can drop that as we have py27 as minimum. At the same time we can refactor that method a little to make it easier to read. References: [1] https://github.com/openstack/nova/blob/b2100015ac6f98c68451cb8827687866fe695452/nova/virt/libvirt/driver.py#L2701-L2704 ** 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/1611380 Title: libvirt: drop py26 compat for get_console_output Status in OpenStack Compute (nova): New Bug description: There is py26 compatibility code in the libvirt driver to query the console output [1]. We can drop that as we have py27 as minimum. At the same time we can refactor that method a little to make it easier to read. References: [1] https://github.com/openstack/nova/blob/b2100015ac6f98c68451cb8827687866fe695452/nova/virt/libvirt/driver.py#L2701-L2704 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611380/+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 1610887] Re: Error while launching instance. ERROR (ClientException): Unexpected API Error.
Unfortunately we don't have the capacity to resolve support requests here. The issue you describe is most probably a configuration issue where Nova cannot communicate/authenticate with Keystone. The manuals [1] should give you enough information how to solve this. There is also a mailing list [2] where OpenStack users help each other and there's also a forum [3]. References: [1] http://docs.openstack.org/liberty/install-guide-ubuntu/nova-controller-install.html#install-and-configure-components [2] https://wiki.openstack.org/wiki/Mailing_Lists#General_List [3] https://ask.openstack.org/ ** 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/1610887 Title: Error while launching instance. ERROR (ClientException): Unexpected API Error. Status in OpenStack Compute (nova): Invalid Bug description: I'm unable to launch instance using nova boot command. I'm running openstack liberty on Ubuntu Server 14 VMs on virtual box in a multi-node set-up. Following official docs for liberty on ubuntu. Below are command and error details, nova-api.log and nova-compute.log lines and my nova.conf contenets. Command and Error; root@controller:~# nova boot --flavor m1.tiny --image cirros --nic net-id=aaa59963-a3b2-4c37-b691-5a0369b6ffde \ > --security-group default --key-name mykey vm1 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-91af2d4b-8948-476e-b87a-00c34598dde7) Error log in 'Nova-api.log' file; 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions return self.request(url, 'POST', **kwargs) 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/keystoneclient/utils.py", line 337, in inner 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/keystoneclient/session.py", line 401, in request 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions raise exceptions.from_response(resp, method, url) 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions BadRequest: Expecting to find username or userId in passwordCredentials - the server could not comply with the request since it is either malformed or otherwise incorrect. The client is assumed to be in error. (HTTP 400) (Request-ID: req-3265697b-246a-4596-8e35-348e4f36a671) 2016-08-08 12:30:41.195 4992 ERROR nova.api.openstack.extensions 2016-08-08 12:30:41.291 4992 INFO nova.api.openstack.wsgi [req-91af2d4b-8948-476e-b87a-00c34598dde7 fd2b20887e9847bf80d84ee31e47aec9 61544fe6c61040cc98ba2c636cb0f889 - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2016-08-08 12:30:41.322 4992 INFO nova.osapi_compute.wsgi.server [req-91af2d4b-8948-476e-b87a-00c34598dde7 fd2b20887e9847bf80d84ee31e47aec9 61544fe6c61040cc98ba2c636cb0f889 - - -] 10.1.1.21 "POST /v2/61544fe6c61040cc98ba2c636cb0f889/servers HTTP/1.1" status: 500 len: 441 time: 2.0076089 Error in nova-compute.log on compute noce; 2016-08-08 11:41:25.074 1581 ERROR oslo.messaging._drivers.impl_rabbit [req-cddbd2fb-f356-4d84-823b-a9703fc70751 - - - - -] AMQP server on controller:5672 is unreachable: timed out. Trying again in 2 seconds. Below is my /etc/nova/nova.conf file on controller; [DEFAULT] dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True libvirt_use_virtio_for_bridges=True #verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini #enabled_apis=ec2,osapi_compute,metadata rpc_backend = rabbit auth_strategy = keystone my_ip = network_api_class = nova.network.neutronv2.api.API security_group_api = neutron linuxnet_interface_driver = nova.network.linux_net.NeutronLinuxBridgeInterfaceDriver firewall_driver = nova.virt.firewall.NoopFirewallDriver enabled_apis=osapi_compute,metadata verbose = True [database] connection = mysql+pymysql://nova:nova@controller/nova [oslo_messaging_rabbit] rabbit_host = controller rabbit_userid = openstack rabbit_password = [keystone_authtoken] auth_uri = http://controller:5000 #identity_url = http://controller:35357 auth_host = controller auth_port = 35357 auth_protocol = http #auth_plugin = password admin_tenant_name = service admin_user = nova admin_password = #auth_plugin = password #project_domain_id = default #user_domain_id = default #project_na
[Yahoo-eng-team] [Bug 1609467] Re: Rename Network return 403 Error
Reviewed: https://review.openstack.org/350661
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=28c443f4e320c4c35b650f0aedb1e6343c785be3
Submitter: Jenkins
Branch:master
commit 28c443f4e320c4c35b650f0aedb1e6343c785be3
Author: zarrouk
Date: Wed Aug 3 17:43:14 2016 +0200
Do not send shared param when not allowed.
When a user changes the name of a network,
neutron returns a 403 error.
Even if the user only changes the name and doesn't
change the shared state, Horizon send
the shared data to neutron and neutron returns
403 when the user doesn't have admin rights
Change-Id: I52726b7215acb877f38069c95d190eb36399954f
Closes-Bug: #1609467
** 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/1609467
Title:
Rename Network return 403 Error
Status in OpenStack Dashboard (Horizon):
Fix Released
Bug description:
When renaming a network, Horizon sends all parameters of the network,
even the ones we do not change:
curl -i https://v2.0/networks/.json -X PUT
-H "User-Agent: python-neutronclient" -H "X-Auth-Token: " -d
'{"network": {"shared": false, "name": "dfdf", "admin_state_up":
true}}'
DEBUG: openstack_dashboard.api.neutron network_update 678: network_update():
netid=, params={'shared': False, 'name': u'plouf', 'admin_state_up':
True}
DEBUG: neutronclient.client http_log_req 185: REQ: curl -i
https://network.fr1.cloudwatt.com/v2.0/networks/.json -X PUT -H
"User-Agent: python-neutronclient" -H "X-Auth-Token:d" -d
'{"network": {"shared": false, "name": "plouf", "admin_state_up": true}}'
DEBUG: neutronclient.client http_log_resp 194: RESP: 403 {'Content-Length':
'130', 'Keep-Alive': 'timeout=5, max=100', 'Connection': 'Keep-Alive', 'Date':
'Tue, 02 Aug 2016 13:30:11 GMT', 'Access-Control-Allow-Origin': '*',
'Content-Type': 'application/json; charset=UTF-8', 'X-Openstack-Request-Id':
'req-8593fcfb-835c-4684-b068-068b5e14e4f2'} {"NeutronError": {"message":
"Policy doesn't allow update_network to be performed.", "type":
"PolicyNotAuthorized", "detail": ""}}
DEBUG: neutronclient.v2_0.client _handle_fault_response 247: Error message:
{"NeutronError": {"message": "Policy doesn't allow update_network to be
performed.", "type": "PolicyNotAuthorized", "detail": ""}}
INFO: openstack_dashboard.dashboards.project.networks.forms handle 71: Echec
de mise à jour du réseau plouf
WARNING: horizon.exceptions handle_recoverable 255: Recoverable error: Policy
doesn't allow update_network to be performed.
Neutron server returns request_ids:
['req-8593fcfb-835c-4684-b068-068b5e14e4f2']
curl -i
https://network.fr1.cloudwatt.com/v2.0/networks/79564170-e563-4b82-b2ac-c5a5bbef3b98.json
-X PUT -H "User-Agent: python-neutronclient" -H "X-Auth-Token:
c5e5196e85994a468b41919d5fd74fa8" -d '{"network": {"name":
"erertrtrtrtrt","admin_state_up": true}}'
The api refuses the "shared": false even if it does not change.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1609467/+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 1606844] Re: L3 agent constantly resyncing deleted router
Reviewed: https://review.openstack.org/348372 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=31a7feea6b60dac138b00652d2f16982a3b25f78 Submitter: Jenkins Branch:master commit 31a7feea6b60dac138b00652d2f16982a3b25f78 Author: Oleg Bondarev Date: Thu Jul 28 17:03:22 2016 +0300 L3 agent: check router namespace existence before delete Router namespace absence may lead to infinite loop in l3 agent trying to delete the router. This patch adds checks before going into namespace to prevent RuntimeError and following infinite loop. Closes-Bug: #1606844 Change-Id: Iae95ccb8eeb06d0fd5fc7d71e63408b3f843b371 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1606844 Title: L3 agent constantly resyncing deleted router Status in neutron: Fix Released Bug description: No need to constantly resync router which was deleted and for which there is no namespace. Observed: l3 agent log full of 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent [-] Error while deleting router 81ef46de-f7f9-4c5e-b787-c935e0af253a 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent Traceback (most recent call last): 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/l3/agent.py", line 359, in _safe_router_removed 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent self._router_removed(router_id) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/l3/agent.py", line 377, in _router_removed 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent ri.delete(self) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/l3/router_info.py", line 347, in delete 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent self.process_delete(agent) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/common/utils.py", line 385, in call 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent self.logger(e) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent self.force_reraise() 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent six.reraise(self.type_, self.value, self.tb) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/common/utils.py", line 382, in call 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent return func(*args, **kwargs) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/l3/router_info.py", line 947, in process_delete 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent self._process_internal_ports(agent.pd) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/l3/router_info.py", line 530, in _process_internal_ports 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent existing_devices = self._get_existing_devices() 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/l3/router_info.py", line 413, in _get_existing_devices 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent ip_devs = ip_wrapper.get_devices(exclude_loopback=True) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/linux/ip_lib.py", line 130, in get_devices 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent log_fail_as_error=self.log_fail_as_error 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent File "/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py", line 140, in execute 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent raise RuntimeError(msg) 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent RuntimeError: Exit code: 1; Stdin: ; Stdout: ; Stderr: Cannot open network namespace "qrouter-81ef46de-f7f9-4c5e-b787-c935e0af253a": No such file or directory 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent 2016-07-26 14:00:45.224 13360 ERROR neutron.agent.l3.agent 2016-07-26 14:00:45.236 13360 ERROR neutron.agent.linux.utils [-] Exit code: 1; Stdin: ; Stdout: ; Stderr: Cannot open network namespace "qrouter-81ef46de-f7f9-4c5e-b787-c935e0af2
[Yahoo-eng-team] [Bug 1611171] Re: re-runs self via sudo
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
It seems like a class D type of bug (e.g., hardening opportunity)
according to VMT taxonomy ( https://security.openstack.org/vmt-
process.html#incident-report-taxonomy ).
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Incomplete
--
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/1611171
Title:
re-runs self via sudo
Status in Cinder:
New
Status in Designate:
In Progress
Status in ec2-api:
New
Status in gce-api:
New
Status in Manila:
New
Status in masakari:
New
Status in OpenStack Compute (nova):
New
Status in OpenStack Security Advisory:
Incomplete
Status in Rally:
New
Bug description:
Hello, I'm looking through Designate source code to determine if is
appropriate to include in Ubuntu Main. This isn't a full security
audit.
This looks like trouble:
./designate/cmd/manage.py
def main():
CONF.register_cli_opt(category_opt)
try:
utils.read_config('designate', sys.argv)
logging.setup(CONF, 'designate')
except cfg.ConfigFilesNotFoundError:
cfgfile = CONF.config_file[-1] if CONF.config_file else None
if cfgfile and not os.access(cfgfile, os.R_OK):
st = os.stat(cfgfile)
print(_("Could not read %s. Re-running with sudo") % cfgfile)
try:
os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] +
sys.argv)
except Exception:
print(_('sudo failed, continuing as if nothing happened'))
print(_('Please re-run designate-manage as root.'))
sys.exit(2)
This is an interesting decision -- if the configuration file is _not_
readable by the user in question, give the executing user complete privileges
of the user that owns the unreadable file.
I'm not a fan of hiding privilege escalation / modifications in
programs -- if a user had recently used sudo and thus had the
authentication token already stored for their terminal, this 'hidden'
use of sudo may be unexpected and unwelcome, especially since it
appears that argv from the first call leaks through to the sudo call.
Is this intentional OpenStack style? Or unexpected for you guys too?
(Feel free to make this public at your convenience.)
Thanks
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+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 1607825] Re: A question about compute node docking VMware virtualization platform
Support requests won't get handled here. The mailing list (openst...@lists.openstack.org) or the ask.openstack.org forum are better places. ** Changed in: nova Status: Incomplete => 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/1607825 Title: A question about compute node docking VMware virtualization platform Status in OpenStack Compute (nova): Invalid Bug description: I am running OpenStack Kilo on CentOS7.1.I want to launch a vm with two port,and each port can communicate with different standard vswitch,then the vm can be access to the outside with two physical cards.But now my environment can only be accessed through a standard vswitch.Current OpenStack release can support? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1607825/+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 1611171] Re: re-runs self via sudo
Apparantly, this isn't unique to Designate either:
http://git.openstack.org/cgit/openstack/cinder/tree/cinder/cmd/manage.py
http://git.openstack.org/cgit/openstack/nova/tree/nova/cmd/manage.py
** Also affects: nova
Importance: Undecided
Status: New
** Also affects: cinder
Importance: Undecided
Status: New
** Also affects: ec2-api
Importance: Undecided
Status: New
** Also affects: gce-api
Importance: Undecided
Status: New
** Also affects: manila
Importance: Undecided
Status: New
** Also affects: masakari
Importance: Undecided
Status: New
** Also affects: rally
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/1611171
Title:
re-runs self via sudo
Status in Cinder:
New
Status in Designate:
In Progress
Status in ec2-api:
New
Status in gce-api:
New
Status in Manila:
New
Status in masakari:
New
Status in OpenStack Compute (nova):
New
Status in Rally:
New
Bug description:
Hello, I'm looking through Designate source code to determine if is
appropriate to include in Ubuntu Main. This isn't a full security
audit.
This looks like trouble:
./designate/cmd/manage.py
def main():
CONF.register_cli_opt(category_opt)
try:
utils.read_config('designate', sys.argv)
logging.setup(CONF, 'designate')
except cfg.ConfigFilesNotFoundError:
cfgfile = CONF.config_file[-1] if CONF.config_file else None
if cfgfile and not os.access(cfgfile, os.R_OK):
st = os.stat(cfgfile)
print(_("Could not read %s. Re-running with sudo") % cfgfile)
try:
os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] +
sys.argv)
except Exception:
print(_('sudo failed, continuing as if nothing happened'))
print(_('Please re-run designate-manage as root.'))
sys.exit(2)
This is an interesting decision -- if the configuration file is _not_
readable by the user in question, give the executing user complete privileges
of the user that owns the unreadable file.
I'm not a fan of hiding privilege escalation / modifications in
programs -- if a user had recently used sudo and thus had the
authentication token already stored for their terminal, this 'hidden'
use of sudo may be unexpected and unwelcome, especially since it
appears that argv from the first call leaks through to the sudo call.
Is this intentional OpenStack style? Or unexpected for you guys too?
(Feel free to make this public at your convenience.)
Thanks
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+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 1605894] Re: some test_l3 unit test failures
Reviewed: https://review.openstack.org/346954 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=22a341a204e84b83094899730602975baa469af9 Submitter: Jenkins Branch:master commit 22a341a204e84b83094899730602975baa469af9 Author: Sreekumar S Date: Mon Jul 25 22:43:24 2016 +0530 Fixes the midonet test_l3 unit test failures Failures for midonet unit tests seems to be caused due to nested rollback. Referred https://review.openstack.org/#/c/230481/ for this fix. Change-Id: Ic6b37bf3f799055c93e9eeb9b7f51758ceecbeb5 Closes-Bug: #1605894 Related-Bug: #1501686 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1605894 Title: some test_l3 unit test failures Status in networking-midonet: Fix Released Status in neutron: Fix Released Bug description: networking-midonet gate fails due to recent l3_db change. [1] any plugins which have a surrounding transaction for add_router_interface would be affected in the same way. [1] I797df266dafc41843408dc95a6ce9f986db5c21c http://logs.openstack.org/00/344100/2/check/gate-networking-midonet- python27/f55680d/console.html 2016-07-23 10:56:05.220890 | == 2016-07-23 10:56:05.220921 | FAIL: midonet.neutron.tests.unit.test_midonet_plugin.TestMidonetL3NatDBIntTest.test_router_add_interface_dup_subnet2_returns_400 2016-07-23 10:56:05.220941 | -- 2016-07-23 10:56:05.220953 | Traceback (most recent call last): 2016-07-23 10:56:05.220984 | File "/tmp/openstack/neutron/neutron/tests/unit/extensions/test_l3.py", line 1425, in test_router_add_interface_dup_subnet2_returns_400 2016-07-23 10:56:05.221003 | expected_code=exc.HTTPBadRequest.code) 2016-07-23 10:56:05.221029 | File "/tmp/openstack/neutron/neutron/tests/unit/extensions/test_l3.py", line 403, in _router_interface_action 2016-07-23 10:56:05.221046 | self.assertEqual(expected_code, res.status_int, msg) 2016-07-23 10:56:05.221081 | File "/home/jenkins/workspace/gate-networking-midonet-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual 2016-07-23 10:56:05.221101 | self.assertThat(observed, matcher, message) 2016-07-23 10:56:05.221136 | File "/home/jenkins/workspace/gate-networking-midonet-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat 2016-07-23 10:56:05.221146 | raise mismatch_error 2016-07-23 10:56:05.221160 | testtools.matchers._impl.MismatchError: 400 != 500 2016-07-23 10:56:05.221178 | == 2016-07-23 10:56:05.221211 | FAIL: midonet.neutron.tests.unit.test_midonet_plugin.TestMidonetL3NatDBIntTest.test_router_add_interface_ipv6_port_existing_network_returns_400 2016-07-23 10:56:05.221235 | -- 2016-07-23 10:56:05.221247 | Traceback (most recent call last): 2016-07-23 10:56:05.221281 | File "/tmp/openstack/neutron/neutron/tests/unit/extensions/test_l3.py", line 1316, in test_router_add_interface_ipv6_port_existing_network_returns_400 2016-07-23 10:56:05.221297 | expected_code=exp_code) 2016-07-23 10:56:05.221324 | File "/tmp/openstack/neutron/neutron/tests/unit/extensions/test_l3.py", line 403, in _router_interface_action 2016-07-23 10:56:05.221349 | self.assertEqual(expected_code, res.status_int, msg) 2016-07-23 10:56:05.221386 | File "/home/jenkins/workspace/gate-networking-midonet-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual 2016-07-23 10:56:05.221400 | self.assertThat(observed, matcher, message) 2016-07-23 10:56:05.221435 | File "/home/jenkins/workspace/gate-networking-midonet-python27/.tox/py27/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat 2016-07-23 10:56:05.221445 | raise mismatch_error 2016-07-23 10:56:05.221459 | testtools.matchers._impl.MismatchError: 400 != 500 2016-07-23 10:56:05.221477 | == 2016-07-23 10:56:05.221509 | FAIL: midonet.neutron.tests.unit.test_midonet_plugin.TestMidonetL3NatDBIntTest.test_router_add_interface_multiple_ipv4_subnet_port_returns_400 2016-07-23 10:56:05.221528 | -- 2016-07-23 10:56:05.221540 | Traceback (most recent call last): 2016-07-23 10:56:05.221574 | File "/tmp/openstack/neutron/neutron/tests/unit/extensions/test_l3.py", line 1287, in test_router_add_interface_multiple_ipv4_subnet_port_returns_4
[Yahoo-eng-team] [Bug 1611321] [NEW] HyperV: shelve vm deadlock
Public bug reported: At the moment, the instance snapshot operation is synchronized using the instance uuid. This was added some time ago, as the instance destroy operation was failing when an instance snapshot was in proggress. This is now causing a deadlock, as a similar lock was recently introduced in the manager for the shelve operation by this change: Id36b3b9516d72d28519c18c38d98b646b47d288d We can safely remove the lock from the HyperV driver as we now stop pending jobs when destroying instances. ** Affects: compute-hyperv Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Tags: hyper-v ** 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/1611321 Title: HyperV: shelve vm deadlock Status in compute-hyperv: New Status in OpenStack Compute (nova): New Bug description: At the moment, the instance snapshot operation is synchronized using the instance uuid. This was added some time ago, as the instance destroy operation was failing when an instance snapshot was in proggress. This is now causing a deadlock, as a similar lock was recently introduced in the manager for the shelve operation by this change: Id36b3b9516d72d28519c18c38d98b646b47d288d We can safely remove the lock from the HyperV driver as we now stop pending jobs when destroying instances. To manage notifications about this bug go to: https://bugs.launchpad.net/compute-hyperv/+bug/1611321/+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 1611309] [NEW] 'WARNING: document isn't included in any toctree' in building html docs
Public bug reported:
When running 'tox -e docs', the following warning occurs.
checking consistency... /tmp/nova/doc/source/vendordata.rst:: WARNING:
document isn't included in any toctree
The vendordata.rst has been added in the following patch.
But it has no content (TODO description only) and is not linked by other
documents.
https://review.openstack.org//317739/
So orphan metadata should be added temporarily in /vendordata.rst.
stack@devstack-master:/tmp/nova$ tox -e docs
(snipped...)
docs runtests: commands[1] | python setup.py build_sphinx
running build_sphinx
(snipped...)
building [html]: all source files
(snipped...)
checking consistency... /tmp/nova/doc/source/vendordata.rst:: WARNING: document
isn't included in any toctree
done
(snipped...)
checking consistency... /tmp/nova/doc/source/vendordata.rst:: WARNING: document
isn't included in any toctree
done
writing... nova-all.1 { } nova-api-metadata.1 { } nova-api-os-compute.1 { }
nova-api.1 { } nova-cells.1 { } nova-cert.1 { } nova-compute.1 { }
nova-console.1 { } nova-consoleauth.1 { } nova-dhcpbridge.1 { }
nova-idmapshift.1 { } nova-manage.1 { } nova-network.1 { } nova-novncproxy.1 {
} nova-spicehtml5proxy.1 { } nova-serialproxy.1 { } nova-rootwrap.1 { }
nova-scheduler.1 { } nova-xvpvncproxy.1 { } nova-conductor.1 { }
build succeeded, 1 warning.
[Environment]
OS: Ubuntu 14.04.4 LTS (64bit)
nova master(commit: e6a05382bd257e74a81a551f23dc86ccb9ee01c5)
** Affects: nova
Importance: Undecided
Assignee: Takashi NATSUME (natsume-takashi)
Status: New
** Tags: doc
--
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/1611309
Title:
'WARNING: document isn't included in any toctree' in building html
docs
Status in OpenStack Compute (nova):
New
Bug description:
When running 'tox -e docs', the following warning occurs.
checking consistency... /tmp/nova/doc/source/vendordata.rst:: WARNING:
document isn't included in any toctree
The vendordata.rst has been added in the following patch.
But it has no content (TODO description only) and is not linked by other
documents.
https://review.openstack.org//317739/
So orphan metadata should be added temporarily in /vendordata.rst.
stack@devstack-master:/tmp/nova$ tox -e docs
(snipped...)
docs runtests: commands[1] | python setup.py build_sphinx
running build_sphinx
(snipped...)
building [html]: all source files
(snipped...)
checking consistency... /tmp/nova/doc/source/vendordata.rst:: WARNING:
document isn't included in any toctree
done
(snipped...)
checking consistency... /tmp/nova/doc/source/vendordata.rst:: WARNING:
document isn't included in any toctree
done
writing... nova-all.1 { } nova-api-metadata.1 { } nova-api-os-compute.1 { }
nova-api.1 { } nova-cells.1 { } nova-cert.1 { } nova-compute.1 { }
nova-console.1 { } nova-consoleauth.1 { } nova-dhcpbridge.1 { }
nova-idmapshift.1 { } nova-manage.1 { } nova-network.1 { } nova-novncproxy.1 {
} nova-spicehtml5proxy.1 { } nova-serialproxy.1 { } nova-rootwrap.1 { }
nova-scheduler.1 { } nova-xvpvncproxy.1 { } nova-conductor.1 { }
build succeeded, 1 warning.
[Environment]
OS: Ubuntu 14.04.4 LTS (64bit)
nova master(commit: e6a05382bd257e74a81a551f23dc86ccb9ee01c5)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1611309/+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 1611308] [NEW] L2pop add_fdb_entries concurrency issue
Public bug reported: This is observed during live migration in a large scale env. ovs- agent+l2pop is used in the env. The oberserved issue is: If multiple vms live migrates at the same time, some host will have stale unicast information at table 20, which still points vm to the old host. After checking the code, there is a potential issue for [1], when concurrent call to it. Assuming there is 3 hosts, A, B, C. The VMs are being migrate from A to B and C. The VMs are in the same neutron network. and host B don't have any port of that neutron network before the migration. The scenario might be: 1) VM1 migrates from host A to host B. 2) When the port of VM1 is up in host B, neutron server will be informed, and all the fdb_entries of that neutron network will be generated and sent to host B. The code at [2] will be hit. Let's assume the neutron network has lots of ports in it. So, the call at [2] is expected to take long time. 3) In the middle of 2), another VM, called VM 2 migrate from host A to host C. 4) Let's assume host C already has ports in the neutron network of VM2. So, the code will not hit [2], and just go to [3]. [3] is a lightweight fanout rpc request. ovs-agent at host B might get this request when still processing 2). 5) 4) finished, but 2) is still ongoing. At this point, host B will have the new unicast information of VM2. However, the information at 2) contains stale information, which still thinks VM2 is at host A. 6) When 2) finished, the stale information of VM2 might cover the new information of VM2, which lead to the reported issue. [1] https://github.com/openstack/neutron/blob/fd401fe0a052a7103cb19d7385a1c702de05577f/neutron/plugins/ml2/drivers/l2pop/rpc_manager/l2population_rpc.py#L38 [2] https://github.com/openstack/neutron/blob/fd401fe0a052a7103cb19d7385a1c702de05577f/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L240 [3] https://github.com/openstack/neutron/blob/fd401fe0a052a7103cb19d7385a1c702de05577f/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L247 ** Affects: neutron Importance: Undecided Assignee: Hong Hui Xiao (xiaohhui) Status: New ** Changed in: neutron Assignee: (unassigned) => Hong Hui Xiao (xiaohhui) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611308 Title: L2pop add_fdb_entries concurrency issue Status in neutron: New Bug description: This is observed during live migration in a large scale env. ovs- agent+l2pop is used in the env. The oberserved issue is: If multiple vms live migrates at the same time, some host will have stale unicast information at table 20, which still points vm to the old host. After checking the code, there is a potential issue for [1], when concurrent call to it. Assuming there is 3 hosts, A, B, C. The VMs are being migrate from A to B and C. The VMs are in the same neutron network. and host B don't have any port of that neutron network before the migration. The scenario might be: 1) VM1 migrates from host A to host B. 2) When the port of VM1 is up in host B, neutron server will be informed, and all the fdb_entries of that neutron network will be generated and sent to host B. The code at [2] will be hit. Let's assume the neutron network has lots of ports in it. So, the call at [2] is expected to take long time. 3) In the middle of 2), another VM, called VM 2 migrate from host A to host C. 4) Let's assume host C already has ports in the neutron network of VM2. So, the code will not hit [2], and just go to [3]. [3] is a lightweight fanout rpc request. ovs-agent at host B might get this request when still processing 2). 5) 4) finished, but 2) is still ongoing. At this point, host B will have the new unicast information of VM2. However, the information at 2) contains stale information, which still thinks VM2 is at host A. 6) When 2) finished, the stale information of VM2 might cover the new information of VM2, which lead to the reported issue. [1] https://github.com/openstack/neutron/blob/fd401fe0a052a7103cb19d7385a1c702de05577f/neutron/plugins/ml2/drivers/l2pop/rpc_manager/l2population_rpc.py#L38 [2] https://github.com/openstack/neutron/blob/fd401fe0a052a7103cb19d7385a1c702de05577f/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L240 [3] https://github.com/openstack/neutron/blob/fd401fe0a052a7103cb19d7385a1c702de05577f/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L247 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611308/+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 1611302] [NEW] SR-IOV: deprecate supported_pci_vendor_devs
Public bug reported: To reduce complexity in configuring SR-IOV I want to deprecate the supported_pci_vendor_devs option. This option is doing extra validation that pci vendor id and product id provided by nova in the neutron port binding profile is matching to the vendor id and product id in supported_pci_vendor_devs. This is redundant, because nova-scheduler is the point to do validation and select a suitable hypervisor and The compute node is already validating this through the pci_passthrough_whitelist option in nova.conf see http://lists.openstack.org/pipermail/openstack-dev/2016-August/101108.html ** Affects: neutron Importance: Undecided Assignee: Moshe Levi (moshele) Status: In Progress ** Tags: sriov-pci-pt -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611302 Title: SR-IOV: deprecate supported_pci_vendor_devs Status in neutron: In Progress Bug description: To reduce complexity in configuring SR-IOV I want to deprecate the supported_pci_vendor_devs option. This option is doing extra validation that pci vendor id and product id provided by nova in the neutron port binding profile is matching to the vendor id and product id in supported_pci_vendor_devs. This is redundant, because nova-scheduler is the point to do validation and select a suitable hypervisor and The compute node is already validating this through the pci_passthrough_whitelist option in nova.conf see http://lists.openstack.org/pipermail/openstack-dev/2016-August/101108.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611302/+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 1611292] [NEW] api-ref: wrong parameters in os-volumes.inc
Public bug reported: API reference: http://developer.openstack.org/api-ref/compute/#volume-extension-os-volumes-os-snapshots-deprecated In os-snapshots APIs, the display name is the snapshot name, not the volume name. The display description is the snapshot description, not the volume description. They should be fixed. ** Affects: nova Importance: Undecided Assignee: Takashi NATSUME (natsume-takashi) Status: In Progress ** Tags: doc -- 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/1611292 Title: api-ref: wrong parameters in os-volumes.inc Status in OpenStack Compute (nova): In Progress Bug description: API reference: http://developer.openstack.org/api-ref/compute/#volume-extension-os-volumes-os-snapshots-deprecated In os-snapshots APIs, the display name is the snapshot name, not the volume name. The display description is the snapshot description, not the volume description. They should be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611292/+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 1602403] Re: OVS: Add support for IPv6 addresses as tunnel endpoints
Reviewed: https://review.openstack.org/352027 Committed: https://git.openstack.org/cgit/openstack/openstack-manuals/commit/?id=d9cafb7ab355c2376b3cc94376ac8823a8ee0bed Submitter: Jenkins Branch:master commit d9cafb7ab355c2376b3cc94376ac8823a8ee0bed Author: Sana Khan Date: Sat Aug 6 21:56:23 2016 +0530 Updates docs to add OVS support for IPv6 addresses as tunnel endpoints Fix in the 'OpenStack control & management network considerations' section. Previously it stated that Open vSwitch does not support IPv6. This commit updates the documentation now that Open vSwitch does support IPv6 endpoints. Change-Id: I3673d033aa4182d012c77f5c13afae692bfc07da Closes-Bug: #1602403 ** 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 neutron. https://bugs.launchpad.net/bugs/1602403 Title: OVS: Add support for IPv6 addresses as tunnel endpoints Status in neutron: Confirmed Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/318318 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 c3892e4df14c151d4f5ce3bf01f26b7807651dd0 Author: Frode Nordahl Date: Mon Dec 14 13:51:48 2015 +0100 OVS: Add support for IPv6 addresses as tunnel endpoints Remove IPv4 restriction for local_ip configuration statement. Check for IP version mismatch of local_ip and remote_ip before creating tunnel. Create hash of remote IPv6 address for OVS interface/port name with least posibility for collissions. Fix existing tests that fail because of the added check for IP version and subsequently valid IP addresses in _setup_tunnel_port. DocImpact Conflicts: neutron/tests/common/agents/ovs_agent.py Change-Id: I9ec137ef8c688b678a0c61f07e9a01382acbeb13 Closes-Bug: #1525895 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1602403/+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 1517839] Re: Make CONF.set_override with parameter enforce_type=True by default
Reviewed: https://review.openstack.org/325749 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=e6a05382bd257e74a81a551f23dc86ccb9ee01c5 Submitter: Jenkins Branch:master commit e6a05382bd257e74a81a551f23dc86ccb9ee01c5 Author: ChangBo Guo(gcb) Date: Mon Jun 6 14:47:12 2016 +0800 Set enforce_type=True in method flags Current Nova uses method CONF.set_override to change config option's value with designated value in unit test, but never check if the designated vaule is valid. Each config option has a type like strOpt, BoolOpt, etc. StrOpt with parameter choices only allows values in set of choices. In short word, each config option has limitation for type and value. In production code, oslo.conf can ensure user's input is valid, but in unit test, test methods can pass if we use method CONF.set_override without parameter enforce_type=True even we pass wrong type or wrong value to config option. This commit makes enforce_type=True in method flags in nova/test.py and fix related violations. Closes-Bug: #1517839 Change-Id: I105dabfec89b01d131257054fbb3669763af6ca9 ** 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 neutron. https://bugs.launchpad.net/bugs/1517839 Title: Make CONF.set_override with parameter enforce_type=True by default Status in Cinder: In Progress Status in cloudkitty: Fix Released Status in Designate: Fix Released Status in Glance: New Status in heat: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in Manila: Fix Released Status in Murano: Fix Released Status in neutron: Won't Fix Status in OpenStack Compute (nova): Fix Released Status in oslo.config: In Progress Status in oslo.messaging: Fix Released Status in Rally: Fix Released Status in watcher: Fix Released Bug description: 1. Problems : oslo_config provides method CONF.set_override[1] , developers usually use it to change config option's value in tests. That's convenient . By default parameter enforce_type=False, it doesn't check any type or value of override. If set enforce_type=True , will check parameter override's type and value. In production code(running time code), oslo_config always checks config option's value. In short, we test and run code in different ways. so there's gap: config option with wrong type or invalid value can pass tests when parameter enforce_type = False in consuming projects. that means some invalid or wrong tests are in our code base. [1] https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173 2. Proposal 1) Fix violations when enforce_type=True in each project. 2) Make method CONF.set_override with enforce_type=True by default in oslo_config You can find more details and comments in https://etherpad.openstack.org/p/enforce_type_true_by_default 3. How to find violations in your projects. 1. Run tox -e py27 2. then modify oslo.config with enforce_type=True cd .tox/py27/lib64/python2.7/site-packages/oslo_config edit cfg.py with enforce_type=True -def set_override(self, name, override, group=None, enforce_type=False): +def set_override(self, name, override, group=None, enforce_type=True): 3. Run tox -e py27 again, you will find violations. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1517839/+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 1611237] [NEW] Restart neutron-openvswitch-agent get ERROR "Switch connection timeout"
Public bug reported: Environment: devstack master, ubuntu 14.04 After ./stack.sh finished, kill the neutron-openvswitch-agent process and then start it by /usr/bin/python /usr/local/bin/neutron-openvswitch- agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini The log shows : 2016-08-08 11:02:06.346 ERROR ryu.lib.hub [-] hub: uncaught exception: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 54, in _launch return func(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 97, in __call__ self.ofp_ssl_listen_port) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 120, in server_loop datapath_connection_factory) File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 117, in __init__ self.server = eventlet.listen(listen_info) File "/usr/local/lib/python2.7/dist-packages/eventlet/convenience.py", line 43, in listen sock.bind(addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 98] Address already in use and ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch [-] Switch connection timeout In kilo I could start ovs-agent in this way correctly, I do not know it is right to start ovs-agent in master. ** 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/1611237 Title: Restart neutron-openvswitch-agent get ERROR "Switch connection timeout" Status in neutron: New Bug description: Environment: devstack master, ubuntu 14.04 After ./stack.sh finished, kill the neutron-openvswitch-agent process and then start it by /usr/bin/python /usr/local/bin/neutron- openvswitch-agent --config-file /etc/neutron/neutron.conf --config- file /etc/neutron/plugins/ml2/ml2_conf.ini The log shows : 2016-08-08 11:02:06.346 ERROR ryu.lib.hub [-] hub: uncaught exception: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 54, in _launch return func(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 97, in __call__ self.ofp_ssl_listen_port) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 120, in server_loop datapath_connection_factory) File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 117, in __init__ self.server = eventlet.listen(listen_info) File "/usr/local/lib/python2.7/dist-packages/eventlet/convenience.py", line 43, in listen sock.bind(addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 98] Address already in use and ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch [-] Switch connection timeout In kilo I could start ovs-agent in this way correctly, I do not know it is right to start ovs-agent in master. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611237/+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
