[Yahoo-eng-team] [Bug 1633671] [NEW] Pecan: Compute scenario tests fail on security group rules
Public bug reported: http://logs.openstack.org/48/386848/2/experimental/gate-tempest-dsvm- neutron-pecan/b70ec4c/console.html#_2016-10-15_00_23_38_299635 2016-10-15 00:23:38.301293 | Captured traceback: 2016-10-15 00:23:38.301302 | ~~~ 2016-10-15 00:23:38.301315 | Traceback (most recent call last): 2016-10-15 00:23:38.301332 | File "tempest/test.py", line 100, in wrapper 2016-10-15 00:23:38.301347 | return f(self, *func_args, **func_kwargs) 2016-10-15 00:23:38.301375 | File "tempest/api/compute/security_groups/test_security_group_rules.py", line 76, in test_security_group_rules_create 2016-10-15 00:23:38.301391 | to_port=self.to_port)['security_group_rule'] 2016-10-15 00:23:38.301417 | File "tempest/lib/services/compute/security_group_rules_client.py", line 34, in create_security_group_rule 2016-10-15 00:23:38.301434 | resp, body = self.post(url, post_body) 2016-10-15 00:23:38.301451 | File "tempest/lib/common/rest_client.py", line 276, in post 2016-10-15 00:23:38.301471 | return self.request('POST', url, extra_headers, headers, body, chunked) 2016-10-15 00:23:38.301492 | File "tempest/lib/services/compute/base_compute_client.py", line 48, in request 2016-10-15 00:23:38.301509 | method, url, extra_headers, headers, body, chunked) 2016-10-15 00:23:38.301544 | File "tempest/lib/common/rest_client.py", line 665, in request 2016-10-15 00:23:38.301557 | resp, resp_body) 2016-10-15 00:23:38.301577 | File "tempest/lib/common/rest_client.py", line 829, in _error_checker 2016-10-15 00:23:38.301586 | message=message) 2016-10-15 00:23:38.301602 | tempest.lib.exceptions.ServerFault: Got server fault 2016-10-15 00:23:38.301631 | Details: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2016-10-15 00:23:38.301643 | ** Affects: neutron Importance: High Status: New ** Tags: api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633671 Title: Pecan: Compute scenario tests fail on security group rules Status in neutron: New Bug description: http://logs.openstack.org/48/386848/2/experimental/gate-tempest-dsvm- neutron-pecan/b70ec4c/console.html#_2016-10-15_00_23_38_299635 2016-10-15 00:23:38.301293 | Captured traceback: 2016-10-15 00:23:38.301302 | ~~~ 2016-10-15 00:23:38.301315 | Traceback (most recent call last): 2016-10-15 00:23:38.301332 | File "tempest/test.py", line 100, in wrapper 2016-10-15 00:23:38.301347 | return f(self, *func_args, **func_kwargs) 2016-10-15 00:23:38.301375 | File "tempest/api/compute/security_groups/test_security_group_rules.py", line 76, in test_security_group_rules_create 2016-10-15 00:23:38.301391 | to_port=self.to_port)['security_group_rule'] 2016-10-15 00:23:38.301417 | File "tempest/lib/services/compute/security_group_rules_client.py", line 34, in create_security_group_rule 2016-10-15 00:23:38.301434 | resp, body = self.post(url, post_body) 2016-10-15 00:23:38.301451 | File "tempest/lib/common/rest_client.py", line 276, in post 2016-10-15 00:23:38.301471 | return self.request('POST', url, extra_headers, headers, body, chunked) 2016-10-15 00:23:38.301492 | File "tempest/lib/services/compute/base_compute_client.py", line 48, in request 2016-10-15 00:23:38.301509 | method, url, extra_headers, headers, body, chunked) 2016-10-15 00:23:38.301544 | File "tempest/lib/common/rest_client.py", line 665, in request 2016-10-15 00:23:38.301557 | resp, resp_body) 2016-10-15 00:23:38.301577 | File "tempest/lib/common/rest_client.py", line 829, in _error_checker 2016-10-15 00:23:38.301586 | message=message) 2016-10-15 00:23:38.301602 | tempest.lib.exceptions.ServerFault: Got server fault 2016-10-15 00:23:38.301631 | Details: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. 2016-10-15 00:23:38.301643 | To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633671/+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 1633669] [NEW] Pecan: Tempest API tests fail for RoutersSearchCriteriaTest
Public bug reported: neutron.tests.tempest.api.test_routers.RoutersSearchCriteriaTest.test_list_pagination_with_href_links Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_routers.py", line 295, in test_list_pagination_with_href_links self._test_list_pagination_with_href_links() File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 503, in inner return f(self, *args, **kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 494, in inner return f(self, *args, **kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 681, in _test_list_pagination_with_href_links self._test_list_pagination_iteratively(self._list_all_with_hrefs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 610, in _test_list_pagination_iteratively len(expected_resources), sort_args File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 653, in _list_all_with_hrefs self.assertEqual(1, len(resources_)) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 1 != 0 neutron.tests.tempest.api.test_routers.RoutersSearchCriteriaTest.test_list_pagination_with_marker Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_routers.py", line 291, in test_list_pagination_with_marker self._test_list_pagination_with_marker() File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 503, in inner return f(self, *args, **kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 494, in inner return f(self, *args, **kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 635, in _test_list_pagination_with_marker self._test_list_pagination_iteratively(self._list_all_with_marker) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 615, in _test_list_pagination_iteratively self.assertSameOrder(expected_resources, resources) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 533, in assertSameOrder self.assertEqual(expected[self.field], res[self.field]) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: u'test10' != u'test1' ** Affects: neutron Importance: High Status: New ** Tags: api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633669 Title: Pecan: Tempest API tests fail for RoutersSearchCriteriaTest Status in neutron: New Bug description: neutron.tests.tempest.api.test_routers.RoutersSearchCriteriaTest.test_list_pagination_with_href_links Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_routers.py", line 295, in test_list_pagination_with_href_links self._test_list_pagination_with_href_links() File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 503, in inner return f(self, *args, **kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 494, in inner return f(self, *args, **kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 681, in _test_list_pagination_with_href_links self._test_list_pagination_iteratively(self._list_all_with_hrefs) File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 610, in _test_list_pagination_iteratively len(expected_resources), sort_args File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 653, in _list_all_with_hrefs self.assertEqual(1, len(resources_)) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: 1 != 0 neutron.tests.tempest.api.test_routers.RoutersSearchCriteriaTest.test_list_pagination_with_marker Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_routers.py", line 291, in test_list_pagination_with_marker self._test_list_pagination_with_marker() File "/opt/stack/new/neutron/neutron/tests/tempest/api/base.py", line 503, in inner return f(self, *args, **kwargs) File
[Yahoo-eng-team] [Bug 1633668] [NEW] Pecan: Tempest API test fails QosBandwidthLimitRuleTestJSON
Public bug reported: neutron.tests.tempest.api.test_qos.QosBandwidthLimitRuleTestJSON.test_rule_update_forbidden_for_regular_tenants_own_policy Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_qos.py", line 476, in test_rule_update_forbidden_for_regular_tenants_own_policy policy['id'], rule['id'], max_kbps=2, max_burst_kbps=4) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 485, in assertRaises self.assertThat(our_callable, matcher) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 496, in assertThat mismatch_error = self._matchHelper(matchee, matcher, message, verbose) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 547, in _matchHelper mismatch = matcher.match(matchee) File "/usr/local/lib/python2.7/dist-packages/testtools/matchers/_exception.py", line 108, in match mismatch = self.exception_matcher.match(exc_info) File "/usr/local/lib/python2.7/dist-packages/testtools/matchers/_higherorder.py", line 62, in match mismatch = matcher.match(matchee) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 475, in match reraise(*matchee) File "/usr/local/lib/python2.7/dist-packages/testtools/matchers/_exception.py", line 101, in match result = matchee() File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 1049, in __call__ return self._callable_object(*self._args, **self._kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 599, in update_bandwidth_limit_rule resp, body = self.put(uri, jsonutils.dumps(post_data)) File "tempest/lib/common/rest_client.py", line 340, in put return self.request('PUT', url, extra_headers, headers, body, chunked) File "tempest/lib/common/rest_client.py", line 665, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 829, in _error_checker message=message) tempest.lib.exceptions.ServerFault: Got server fault Details: Request Failed: internal server error while processing your request. ** Affects: neutron Importance: High Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633668 Title: Pecan: Tempest API test fails QosBandwidthLimitRuleTestJSON Status in neutron: New Bug description: neutron.tests.tempest.api.test_qos.QosBandwidthLimitRuleTestJSON.test_rule_update_forbidden_for_regular_tenants_own_policy Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_qos.py", line 476, in test_rule_update_forbidden_for_regular_tenants_own_policy policy['id'], rule['id'], max_kbps=2, max_burst_kbps=4) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 485, in assertRaises self.assertThat(our_callable, matcher) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 496, in assertThat mismatch_error = self._matchHelper(matchee, matcher, message, verbose) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 547, in _matchHelper mismatch = matcher.match(matchee) File "/usr/local/lib/python2.7/dist-packages/testtools/matchers/_exception.py", line 108, in match mismatch = self.exception_matcher.match(exc_info) File "/usr/local/lib/python2.7/dist-packages/testtools/matchers/_higherorder.py", line 62, in match mismatch = matcher.match(matchee) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 475, in match reraise(*matchee) File "/usr/local/lib/python2.7/dist-packages/testtools/matchers/_exception.py", line 101, in match result = matchee() File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 1049, in __call__ return self._callable_object(*self._args, **self._kwargs) File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 599, in update_bandwidth_limit_rule resp, body = self.put(uri, jsonutils.dumps(post_data)) File "tempest/lib/common/rest_client.py", line 340, in put return self.request('PUT', url, extra_headers, headers, body, chunked) File "tempest/lib/common/rest_client.py", line 665, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 829, in _error_checker message=message) tempest.lib.exceptions.ServerFault: Got server fault Details: Request Failed: internal server error while processing your request. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633668/+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
[Yahoo-eng-team] [Bug 1633665] [NEW] Pecan: Router Flavor tempest API tests fail
Public bug reported: Fails in the setUpClass method setUpClass(neutron.tests.tempest.api.admin.test_routers_flavors.RoutersFlavorTestCase) ft2.1: setUpClass (neutron.tests.tempest.api.admin.test_routers_flavors.RoutersFlavorTestCase)_StringException: Traceback (most recent call last): File "tempest/test.py", line 267, in setUpClass six.reraise(etype, value, trace) File "tempest/test.py", line 260, in setUpClass cls.resource_setup() File "/opt/stack/new/neutron/neutron/tests/tempest/api/admin/test_routers_flavors.py", line 44, in resource_setup cls.flavor['id'], sp['service_profile']['id']) File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 801, in create_flavor_service_profile resp, body = self.post(uri, body) File "tempest/lib/common/rest_client.py", line 276, in post return self.request('POST', url, extra_headers, headers, body, chunked) File "tempest/lib/common/rest_client.py", line 665, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 768, 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"Attribute 'id' not allowed in POST"} ** Affects: neutron Importance: High Status: New ** Tags: api ** Summary changed: - Pecan: Router Flavor tests fail + Pecan: Router Flavor tempest API tests fail -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633665 Title: Pecan: Router Flavor tempest API tests fail Status in neutron: New Bug description: Fails in the setUpClass method setUpClass(neutron.tests.tempest.api.admin.test_routers_flavors.RoutersFlavorTestCase) ft2.1: setUpClass (neutron.tests.tempest.api.admin.test_routers_flavors.RoutersFlavorTestCase)_StringException: Traceback (most recent call last): File "tempest/test.py", line 267, in setUpClass six.reraise(etype, value, trace) File "tempest/test.py", line 260, in setUpClass cls.resource_setup() File "/opt/stack/new/neutron/neutron/tests/tempest/api/admin/test_routers_flavors.py", line 44, in resource_setup cls.flavor['id'], sp['service_profile']['id']) File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 801, in create_flavor_service_profile resp, body = self.post(uri, body) File "tempest/lib/common/rest_client.py", line 276, in post return self.request('POST', url, extra_headers, headers, body, chunked) File "tempest/lib/common/rest_client.py", line 665, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 768, 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"Attribute 'id' not allowed in POST"} To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633665/+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 1633664] [NEW] Pecan: Auto allocate topology tempestapi tests fail
Public bug reported: These tests currently fail: neutron.tests.tempest.api.test_auto_allocated_topology.TestAutoAllocatedTopology.test_delete_allocated_net_topology_as_tenant Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_auto_allocated_topology.py", line 115, in test_delete_allocated_net_topology_as_tenant self.client.delete_auto_allocated_topology() File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 794, in delete_auto_allocated_topology resp, body = self.delete(uri) File "tempest/lib/common/rest_client.py", line 307, in delete return self.request('DELETE', url, extra_headers, headers, body) File "tempest/lib/common/rest_client.py", line 665, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 768, in _error_checker raise exceptions.BadRequest(resp_body, resp=resp) tempest.lib.exceptions.BadRequest: Bad request Details: {u'type': u'BadRequest', u'detail': u'', u'message': u'Bad auto_allocate request: Unrecognized field.'} neutron.tests.tempest.api.test_auto_allocated_topology.TestAutoAllocatedTopology.test_get_allocated_net_topology_as_tenant Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_auto_allocated_topology.py", line 85, in test_get_allocated_net_topology_as_tenant self.assertEqual((0, 0, 0), resources_before) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: (0, 0, 0) != (1, 2, 1) ** Affects: neutron Importance: Undecided Assignee: Brandon Logan (brandon-logan) Status: New ** Tags: api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633664 Title: Pecan: Auto allocate topology tempestapi tests fail Status in neutron: New Bug description: These tests currently fail: neutron.tests.tempest.api.test_auto_allocated_topology.TestAutoAllocatedTopology.test_delete_allocated_net_topology_as_tenant Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_auto_allocated_topology.py", line 115, in test_delete_allocated_net_topology_as_tenant self.client.delete_auto_allocated_topology() File "/opt/stack/new/neutron/neutron/tests/tempest/services/network/json/network_client.py", line 794, in delete_auto_allocated_topology resp, body = self.delete(uri) File "tempest/lib/common/rest_client.py", line 307, in delete return self.request('DELETE', url, extra_headers, headers, body) File "tempest/lib/common/rest_client.py", line 665, in request resp, resp_body) File "tempest/lib/common/rest_client.py", line 768, in _error_checker raise exceptions.BadRequest(resp_body, resp=resp) tempest.lib.exceptions.BadRequest: Bad request Details: {u'type': u'BadRequest', u'detail': u'', u'message': u'Bad auto_allocate request: Unrecognized field.'} neutron.tests.tempest.api.test_auto_allocated_topology.TestAutoAllocatedTopology.test_get_allocated_net_topology_as_tenant Traceback (most recent call last): File "/opt/stack/new/neutron/neutron/tests/tempest/api/test_auto_allocated_topology.py", line 85, in test_get_allocated_net_topology_as_tenant self.assertEqual((0, 0, 0), resources_before) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/usr/local/lib/python2.7/dist-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: (0, 0, 0) != (1, 2, 1) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633664/+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 1633306] Re: Partial HA network causing HA router creation failed (race conditon)
** Changed in: neutron Status: Invalid => 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/1633306 Title: Partial HA network causing HA router creation failed (race conditon) Status in neutron: New Bug description: ENV: stable/mitaka,VXLAN Neutron API: two neutron-servers behind a HA proxy VIP. Exception log: [1] http://paste.openstack.org/show/585669/ [2] http://paste.openstack.org/show/585670/ Log [1] shows that the subnet of HA network is concurrently deleted while a new HA router create API comes. Seems the race conditon described in this bug is till exists : https://bugs.launchpad.net/neutron/+bug/1533440, where has description said: """ Some known exceptions: ... 2. IpAddressGenerationFailure: (HA port created failed due to the concurrently HA subnet deletion) ... """ Log [2] has a very strange behavior that those 3 APIs have a same request-id [req-780b1f6e-2b3c-4303-a1de-a5fb4c7ea31e]. Test scenario: Just create one HA router for a tenant, and then quickly delete it. For now, our mitaka ENV use VxLAN as tenant network type. So there is a very large range of VNI. So don't save that, and temporarily solution, we add a new config to decide whether delete the HA network every time. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633306/+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 1633656] [NEW] Can't disable DHCP network config on xenial
Public bug reported: Using uvtool, I am trying to bring up a xenial VM with a bridge to my LAN, and a static network address which I inject using write-files and some bootcmd & runcmd steps (details below). Following the instructions in /etc/network/interfaces.d/50-cloud- init.cfg, I have written "network: {config: disabled}" to /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg in a bootcmd step. For a trusty VM, this works: ubuntu@test-nwtn2:~$ ip address list ... 2: eth0:mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:e1:8b:c3 brd ff:ff:ff:ff:ff:ff inet 10.42.20.4/16 brd 10.42.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fee1:8bc3/64 scope link valid_lft forever preferred_lft forever But for a xenial VM, I find that the VM has two IP addresses: my statically assigned one and another which turns out to have come from DHCP (checked using DHCP logs). ubuntu@test-nwtn2:~$ ip address list ... 2: ens3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:1d:e9:17 brd ff:ff:ff:ff:ff:ff inet 10.42.0.60/16 brd 10.42.255.255 scope global ens3 valid_lft forever preferred_lft forever inet 10.42.20.4/16 brd 10.42.255.255 scope global secondary ens3 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fe1d:e917/64 scope link valid_lft forever preferred_lft forever My host is running 16.04: will@host-nwtn25:~$ uname -a Linux host-nwtn25 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux will@host-nwtn25:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.1 LTS Release:16.04 Codename: xenial will@host-nwtn25:~$ dpkg -l|grep cloud ii cloud-image-utils 0.27-0ubuntu24 all cloud image management utilities ii ubuntu-cloudimage-keyring 2013.11.11 all GnuPG keys of the Ubuntu Cloud Image builder will@host-nwtn25:~$ dpkg -l|grep uvt ii uvtool-libvirt0~bzr99-0ubuntu1 all Library and tools for using Ubuntu Cloud Images with libvirt My command is: sudo uvt-kvm create test-nwtn2 release=xenial arch=amd64 --bridge br0 --cpu 2 --memory 2048 --disk 16384 --user-data cloud-config.yml --log- console-output And cloud-config.yml has: #cloud-config ... bootcmd: - "echo 'network: {config: disabled}' >/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg" write_files: - path: /etc/network/interfaces content: | auto lo iface lo inet loopback auto ens3 iface ens3 inet static address 10.42.20.4 network 10.42.0.0 broadcast 10.42.255.255 netmask 255.255.0.0 gateway 10.42.0.1 dns-nameservers 10.42.0.1 runcmd: - ifdown -a && ifup -a I've also tried removing /etc/network/interfaces.d/50-cloud-init.cfg in my bootcmd step, which didn't seem to change anything. (For trusty, the write_files talked about eth0 instead of ens3.) ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1633656 Title: Can't disable DHCP network config on xenial Status in cloud-init: New Bug description: Using uvtool, I am trying to bring up a xenial VM with a bridge to my LAN, and a static network address which I inject using write-files and some bootcmd & runcmd steps (details below). Following the instructions in /etc/network/interfaces.d/50-cloud- init.cfg, I have written "network: {config: disabled}" to /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg in a bootcmd step. For a trusty VM, this works: ubuntu@test-nwtn2:~$ ip address list ... 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:e1:8b:c3 brd ff:ff:ff:ff:ff:ff inet 10.42.20.4/16 brd 10.42.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:fee1:8bc3/64 scope link valid_lft forever preferred_lft forever But for a xenial VM, I find that the VM has two IP addresses: my statically assigned one and another which turns out to have come from DHCP (checked using DHCP logs). ubuntu@test-nwtn2:~$ ip address list ... 2: ens3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 52:54:00:1d:e9:17 brd ff:ff:ff:ff:ff:ff inet 10.42.0.60/16 brd 10.42.255.255 scope global ens3 valid_lft forever preferred_lft forever inet 10.42.20.4/16 brd 10.42.255.255 scope global secondary ens3 valid_lft forever
[Yahoo-eng-team] [Bug 1614361] Re: tox.ini needs to be updated as openstack infra now supports upper constraints
Reviewed: https://review.openstack.org/384256 Committed: https://git.openstack.org/cgit/openstack/castellan/commit/?id=c6875035ea4ee7bb670054d133fb9d9143df9789 Submitter: Jenkins Branch:master commit c6875035ea4ee7bb670054d133fb9d9143df9789 Author: Jeremy LiuDate: Mon Oct 10 10:02:11 2016 +0800 Support upper-constraints in tox.ini Since the castellan itself is in upper-constraints.txt now, in CI job, we should remove it from the constraints file before applying it, otherwise pip will fail due to castellan version conflict. Change-Id: I5d58303b7f76e0e92083e14d3cff009c02c9fc14 Closes-bug: #1614361 ** Changed in: castellan Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1614361 Title: tox.ini needs to be updated as openstack infra now supports upper constraints Status in castellan: Fix Released Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in Designate: Fix Released Status in Freezer: Fix Released Status in Glance: In Progress Status in heat: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic Inspector: Fix Released Status in Mistral: Fix Released Status in networking-ovn: Invalid Status in octavia: Fix Released Status in python-barbicanclient: Fix Released Status in python-mistralclient: In Progress Status in python-muranoclient: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tacker: Fix Released Status in OpenStack DBaaS (Trove): Invalid Status in vmware-nsx: Fix Released Status in zaqar: Fix Released Status in Zaqar-ui: Fix Released Bug description: Openstack infra now supports upper constraints for releasenotes, cover, venv targets. tox.ini uses install_command for these targets, which can now be safely removed. Reference for mail that details this support: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101474.html To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1614361/+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 1622310] Re: trust still exist in the DB when the trustor/trustee/project is deleted
Reviewed: https://review.openstack.org/38 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=f0319c752aab6241b0b2aa52e4e91c17878f98d9 Submitter: Jenkins Branch:master commit f0319c752aab6241b0b2aa52e4e91c17878f98d9 Author: Dave ChenDate: Mon Oct 10 19:29:31 2016 +0800 Invalidate trust when the related project is deleted The trust without a valid project is useless and will no longer be active since the id of project is a random number and only assigned when it created. The patch invalidate the trust if the related project is deleted. Change-Id: I51214c46ef5332c159b1e18bbd7046d12aba4a65 Closes-Bug: #1622310 ** 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/1622310 Title: trust still exist in the DB when the trustor/trustee/project is deleted Status in OpenStack Identity (keystone): Fix Released Bug description: When a trust is created, it requires trustee, trustor exist in the DB, but when the associated user or project is deleted trust still exist in DB. The trust left in the DB is useless, and won't be used any longer since either id of user/project is a random number when it got created it not likely the trust will be effective in the future. How to reproduce: $ openstack user create trustor --password abc123 $ openstack user create trustee --password abc123 $ openstack project create trust_project $ openstack role add 9cf8420ea5324f79b9d740e3ce5f0e04 --project 2c455f8756d04b9485ec0b344c0e2089 --user 3e56ae62d1c94ead9fe9a4b31aaee070 (Add role service to project trust with user trustor) curl -g -i -X POST -H "Accept: application/json" -H "X-Auth-Token: 94d06939e65243f99cbfcf331bdf3e0b" -H "Content-Type: application/json" -d '{ "trust": { "expires_at": "2017-02-27T18:30:59.99Z", "impersonation": true, "allow_redelegation": true, "project_id": "2c455f8756d04b9485ec0b344c0e2089", "roles": [ { "name": "admin" } ], "trustee_user_id": "9147c64ef0624477bfc9dba818aa569c", "trustor_user_id": "3e56ae62d1c94ead9fe9a4b31aaee070", "redelegation_count": 3 } }' http://10.239.159.68:5000/v3/OS-TRUST/trusts $ openstack user delete trustor $ openstack trust list +---+---+---+---+---+---+ | ID| Expires At| Impersonation | Project ID| Trustee User ID | Trustor User ID | +---+---+---+---+---+---+ | e7491ab063e247b6ad072b562 | 2017-02-27T18:30:59.0 | True | 2c455f8756d04b9485ec0b344 | 9147c64ef0624477bfc9dba81 | 3e56ae62d1c94ead9fe9a4b31 | | b32e37e | 0Z| | c0e2089 | 8aa569c | aaee070 | +---+---+---+---+---+---+ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1622310/+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 1631693] Re: prefix delegation does not work in newton
Reviewed: https://review.openstack.org/384577 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=14ffea985eb041181d1bdef9af53ccb4d9f9 Submitter: Jenkins Branch:master commit 14ffea985eb041181d1bdef9af53ccb4d9f9 Author: John DavidgeDate: Mon Oct 10 14:05:03 2016 +0100 Fix IPv6 PD with pluggable IPAM A PD-sepcific check that was present in the non-pluggable IPAM backend was missing from the pluggable version, causing router interfaces to be created with a '::1' IP (equal to the gateway on PD subnets). The resulting command: ip netns exec ip -6 addr add ::1/64 would then fail. This patch restores the check to ensure that '::1' is not used for router interface ports, and introduces a test to protect against future regressions. Change-Id: I6a2e7cd60dd42d92b900a57bd8f3ffbc5909908e Closes-Bug: 1631693 ** 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/1631693 Title: prefix delegation does not work in newton Status in neutron: Fix Released Bug description: Using a provider network, set up and tested working as laid out here: http://docs.openstack.org/newton/install-guide-ubuntu/launch-instance-networks-selfservice.html Using the prefix delegation as defined here: http://docs.openstack.org/newton/networking-guide/config-ipv6.html Neutron tries to add the prefix_delegated network directly as just '::1/64', which fails. subnet-show ipv6-pd-1 +---+--+ | Field | Value| +---+--+ | allocation_pools | {"start": "::2", "end": ":::::"} | | cidr | ::/64| | created_at| 2016-10-09T03:39:31Z | | description | | | dns_nameservers | | | enable_dhcp | True | | gateway_ip| ::1 | | host_routes | | | id| 7aca0fbc-2700-4956-9ecf-25eb40923377 | | ip_version| 6| | ipv6_address_mode | slaac| | ipv6_ra_mode | slaac| | name | ipv6-pd-1| | network_id| 642b292f-3dee--be52-04520eaed9d1 | | project_id| e88db48bc6f0406593d0fcb8b648babe | | revision_number | 2| | service_types | | | subnetpool_id | prefix_delegation| | tenant_id | e88db48bc6f0406593d0fcb8b648babe | | updated_at| 2016-10-09T03:39:31Z | +---+--+ 2016-10-08 22:46:48.389 19498 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter- 85e10e09-a9a5-4568-ada3-534bd38f66b4', 'ip', '-6', 'addr', 'add', '::1/64', 'scope', 'global', 'dev', 'qr-76a5d305-56'] create_process /usr/lib64/python2.7/site-packages/neutron/agent/linux/utils.py:83 2016-10-08 22:46:48.969 19498 DEBUG oslo_messaging._drivers.amqpdriver [-] received message with unique_id: ebe5ebeb036842258fddf3a9958928de __call__ /usr/lib64/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:196 2016-10-08 22:46:48.974 19498 DEBUG neutron.agent.l3.agent [req-66fe2ee5-2cbf-4d0f-892d-e48c50a1d562 user project - - -] Got routers updated notification :[u'85e10e09-a9a5-4568-ada3-534bd38f66b4'] routers_updated /usr/lib64/python2.7/site-packages/neutron/agent/l3/agent.py:400 2016-10-08 22:46:49.441 19498 ERROR neutron.agent.linux.utils [-] Exit code: 2; Stdin: ; Stdout: ; Stderr: RTNETLINK answers: Cannot assign requested address 2016-10-08 22:46:49.442 19498 ERROR neutron.agent.l3.router_info [-] Exit code: 2; Stdin: ; Stdout: ; Stderr: RTNETLINK answers: Cannot assign requested address 2016-10-08 22:46:49.442 19498 ERROR neutron.agent.l3.router_info Traceback (most recent call last): 2016-10-08 22:46:49.442 19498 ERROR neutron.agent.l3.router_info File "/usr/lib64/python2.7/site-packages/neutron/common/utils.py", line 239, in call 2016-10-08
[Yahoo-eng-team] [Bug 1580780] Re: Associate subnets to segments through subnet API
I just realized I never linked the patch to this bug. https://review.openstack.org/#/c/374434/ ** Changed in: neutron Status: Confirmed => Invalid ** Changed in: openstack-manuals Status: Confirmed => 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/1580780 Title: Associate subnets to segments through subnet API Status in neutron: Invalid Status in openstack-manuals: Fix Released Bug description: https://review.openstack.org/288774 Dear bug triager. This bug was created since a commit was marked with DOCIMPACT. Your project "openstack/neutron" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to. commit f494de47fcef7776f7d29d5ceb2cc4db96bd1efd Author: Carl BaldwinDate: Tue Feb 9 16:39:01 2016 -0700 Associate subnets to segments through subnet API Change-Id: Ia1084a94ac659332c126eb9d4787b04a89a4ba90 DocImpact: Need to add segment_id to API docs Partially-Implements: blueprint routed-networks To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1580780/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
Reviewed: https://review.openstack.org/385939 Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=12f53b746dacb3aa7a246d0fbca4feb844dd735b Submitter: Jenkins Branch:master commit 12f53b746dacb3aa7a246d0fbca4feb844dd735b Author: Iswarya_VakatiDate: Thu Oct 13 17:15:03 2016 +0530 Drop MANIFEST.in - it's not needed by pbr Trove already uses PBR:- setuptools.setup( setup_requires=['pbr>=1.8'], pbr=True) This patch removes `MANIFEST.in` file as pbr generates a sensible manifest from git files and some standard files and it removes the need for an explicit `MANIFEST.in` file. Change-Id: Ib37dde9c9fa0abe43a326ed2476effee04734daa Closes-Bug:#1608980 ** Changed in: trove 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: Fix Released Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in python-searchlightclient: In Progress Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in Swift Authentication: In Progress Status in OpenStack Object Storage (swift): In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): Fix Released Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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
** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Importance: Undecided => Medium ** Changed in: nova/newton Status: New => In Progress ** Changed in: nova/newton Assignee: (unassigned) => Lee Yarwood (lyarwood) ** Changed in: nova Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1611171 Title: re-runs self via sudo Status in Cinder: Fix Released Status in Designate: In Progress Status in ec2-api: In Progress Status in gce-api: In Progress Status in Manila: In Progress Status in masakari: Fix Released Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Status in OpenStack Security Advisory: Won't Fix Status in Rally: In Progress 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 1475652] Re: libvirt, rbd imagebackend, disk.rescue not deleted when unrescued
** Changed in: nova Importance: Undecided => Medium ** Also affects: nova/newton 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/1475652 Title: libvirt, rbd imagebackend, disk.rescue not deleted when unrescued Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Bug description: Reproduced on juno version (actually tested on a fork from 2014.2.3, sorry in advance if invalid but i think the legacy version is also concerned by it) not tested on younger versions, but looking at the code they seem impacted too For Rbd imagebackend only, when unrescuing an instance the disk.rescue file is actually not deleted on remote storage (only the rbd session is destroyed) Consequence: when rescuing instance once again, it simply ignores the new rescue image and takes the old _disk.rescue image Reproduce: 1. nova rescue instance (take care that you are booted to the vda rescue disk -> when rescuing an instance from the same image it was spawned from (case by default), since fs uuid is the same, according to your image fstab (if entry UUID=) you can actually boot from the image you are actually trying to rescue, but this is another matter that concerns template building -> see https://bugs.launchpad.net/nova/+bug/1460536) edit rescue image disk 2. nova unrescue instance 3. nova rescue instance -> you get back the disk.rescue spawned in 1 if confirmed, fix coming soon Concerning fix several possibilities: - nova.virt.libvirt.driver :LibvirtDriver-> unrescue method, not deleting the correct files or - nova.virt.libvirt.imagebackend:Rbd -> erase disk.rescue in create image method if already existing Rebuild not concerned by issue, delete instance correctly deletes files on remote storage To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1475652/+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 1610679] Re: race conditions between compute and schedule disk report
** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Assignee: (unassigned) => Rajesh Tailor (ratailor) ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova/newton Status: New => In Progress ** Changed in: nova/newton Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1610679 Title: race conditions between compute and schedule disk report Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Bug description: devstack recently built and *not* with in-tree virt layer but I think it's not related to it got following error in conductor log 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 "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 199, in inner return func(*args, **kwargs) File "/opt/stack/new/nova/nova/scheduler/manager.py", line 104, in select_destinations dests = self.driver.select_destinations(ctxt, spec_obj) File "/opt/stack/new/nova/nova/scheduler/filter_scheduler.py", line 53, in select_destinations selected_hosts = self._schedule(context, spec_obj) File "/opt/stack/new/nova/nova/scheduler/filter_scheduler.py", line 104, in _schedule hosts = self._get_all_host_states(elevated) File "/opt/stack/new/nova/nova/scheduler/filter_scheduler.py", line 145, in _get_all_host_states return self.host_manager.get_all_host_states(context) File "/opt/stack/new/nova/nova/scheduler/host_manager.py", line 597, in get_all_host_states self._get_instance_info(context, compute)) File "/opt/stack/new/nova/nova/scheduler/host_manager.py", line 180, in update return _locked_update(self, compute, service, aggregates, inst_dict) File "/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 271, in inner return f(*args, **kwargs) File "/opt/stack/new/nova/nova/scheduler/host_manager.py", line 169, in _locked_update self._update_from_compute_node(compute) File "/opt/stack/new/nova/nova/scheduler/host_manager.py", line 201, in _update_from_compute_node free_disk_mb = free_gb * 1024 TypeError: unsupported operand type(s) for *: 'NoneType' and 'int' scheduler log shows following 2016-07-27 13:45:00.934 21123 DEBUG oslo_concurrency.lockutils [req-fc02af23-3279-4c93-8732-9b4f9f3a0b8d tempest-ServersTestJSON-2014112056 tempest-ServersTestJSON-2014112056] Lock "(u'opnssi1', u'OPNSSI1')" acquired by "nova.scheduler.host_manager._locked_update" :: waited 0.000s inner /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:270 2016-07-27 13:45:00.935 21123 DEBUG nova.scheduler.host_manager [req-fc02af23-3279-4c93-8732-9b4f9f3a0b8d tempest-ServersTestJSON-2014112056 tempest-ServersTestJSON-2014112056] Update host state from compute node: ComputeNode(cpu_allocation_ratio=16.0,cpu_info='{"cec_model": "2827", "architecture": "s390x"}',created_at=2016-07-27T13:45:00Z,current_workload=None,deleted=False,deleted_at=None,disk_allocation_ratio=1.0,disk_available_least=432,free_disk_gb=None,free_ram_mb=None,host='opnssi1',host_ip=10.32.201.222,hypervisor_hostname='OPNSSI1',hypervisor_type='zvm',hypervisor_version=630,id=2,local_gb=556,local_gb_used=124,memory_mb=24576,memory_mb_used=0,metrics=None,numa_topology=None,pci_device_pools=None,ram_allocation_ratio=10.0,running_vms=None,service_id=None,stats={},supported_hv_specs=[HVSpec],updated_at=None,uuid=366d9b37-8570-4188-8aab-bc9819cb2312,vcpus=8,vcpus_used=8) _locked_update /opt/stack/new/nova/nova/scheduler/host_manager.py:168 2016-07-27 13:45:00.936 21123 WARNING nova.scheduler.host_manager [req-fc02af23-3279-4c93-8732-9b4f9f3a0b8d tempest-ServersTestJSON-2014112056 tempest-ServersTestJSON-2014112056] Host OPNSSI1 has more disk space than database expected (432 GB > None GB) and compute logs shows the compute node was created first time here 2016-07-27 13:45:00.396 21125 WARNING nova.compute.resource_tracker [req-1ec17be4-cc14-494b-8f88-8bce1999fba1 - -] No compute node record for opnssi1:OPNSSI1 2016-07-27 13:45:01.009 21125 INFO nova.compute.resource_tracker [req- 1ec17be4-cc14-494b-8f88-8bce1999fba1 - -] Compute_service record updated for opnssi1:OPNSSI1 To manage notifications about this bug go to:
[Yahoo-eng-team] [Bug 1555320] Re: "Migration for instance 0763227e-e192-4e0b-a49d-0ea0b181fca6 refers to another host's instance!" should not be an error
** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Assignee: (unassigned) => Roman Podoliaka (rpodolyaka) ** Changed in: nova/newton Importance: Undecided => Low ** Changed in: nova/newton Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1555320 Title: "Migration for instance 0763227e-e192-4e0b-a49d-0ea0b181fca6 refers to another host's instance!" should not be an error Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Bug description: This happens in a periodic task after migrations complete: http://logs.openstack.org/15/290715/1/check/gate-tempest-dsvm- multinode- full/03f92ff/logs/screen-n-cpu.txt.gz?level=INFO#_2016-03-09_18_09_00_775 http://logs.openstack.org/15/290715/1/check/gate-tempest-dsvm- multinode- full/03f92ff/logs/screen-n-cpu.txt.gz?level=INFO#_2016-03-09_18_09_01_748 It shouldn't be an error log since it's normal, see how many times it hits in multinode gate runs: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Migration%20for%20instance%5C%22%20AND%20message%3A%5C%22refers%20to%20another%20host's%20instance!%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22=7d There are over 2500 hits in 7 days on this error message. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1555320/+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 1632513] Re: Nova returns HTTP500 if attaching the attached volume
** Changed in: nova Importance: Undecided => Medium ** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Status: New => In Progress ** Changed in: nova/newton Importance: Undecided => Medium ** Changed in: nova/newton Assignee: (unassigned) => Ken'ichi Ohmichi (oomichi) -- 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/1632513 Title: Nova returns HTTP500 if attaching the attached volume Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Bug description: We tried to add some negative test case to Tempest for the other bug. However, Nova still returns HTTP500 error if attaching the already attached volume like: http://logs.openstack.org/83/382083/12/check/gate-tempest-dsvm- neutron-full-ubuntu- xenial/66f700f/logs/screen-n-api.txt.gz#_2016-10-11_19_28_54_097 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions [req-3a860748-ab8f-4ce7-8412-90f787dd151d tempest-AttachVolumeNegativeTest-1404533522 tempest-AttachVolumeNegativeTest-1404533522] Unexpected exception in API method 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/extensions.py", line 338, in wrapped 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/compute/volumes.py", line 325, in create 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions volume_id, device) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 164, in inner 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 145, in inner 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return f(self, context, instance, *args, **kw) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3481, in attach_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions disk_bus, device_type) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3424, in _attach_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions volume_bdm.destroy() 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions self.force_reraise() 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions six.reraise(self.type_, self.value, self.tb) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3420, in _attach_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions self._check_attach_and_reserve_volume(context, volume_id, instance) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3407, in _check_attach_and_reserve_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions self.volume_api.reserve_volume(context, volume_id) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/volume/cinder.py", line 196, in wrapper 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions _reraise(exception.InvalidInput(reason=err_msg)) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/volume/cinder.py", line 246, in _reraise 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions six.reraise(type(desired_exc), desired_exc, sys.exc_info()[2]) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/volume/cinder.py", line 188, in wrapper 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions
[Yahoo-eng-team] [Bug 1579664] Re: Nova-compute raise exception when vcpu_pin_set is set to None or"".
** Also affects: nova/newton Importance: Undecided Status: New ** Changed in: nova/newton Status: New => In Progress ** Changed in: nova Importance: Undecided => Medium ** Changed in: nova/newton Importance: Undecided => Medium ** Changed in: nova/newton Assignee: (unassigned) => Lee Yarwood (lyarwood) -- 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/1579664 Title: Nova-compute raise exception when vcpu_pin_set is set to None or"". Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) newton series: In Progress Bug description: Description === In Mitaka, Nova-compute raise exception when vcpu_pin_set is set to None or"".And nova-compute fails to start. Steps to reproduce == Edit vcpu_pin_set=None or vcpu_pin_set="" then restart nova-compute service Expected result === Get_vcpu_total returns total_pcpus, and nova-compute service starts successfully. Actual result = When set vcpu_pin_set to None, raise following exception and nova-compute service fails to start: 2016-05-10 09:00:02.835 TRACE nova.compute.manager Traceback (most recent call last): 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 6460, in update_available_resource 2016-05-10 09:00:02.835 TRACE nova.compute.manager rt.update_available_resource(context) 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 500, in update_available_resource 2016-05-10 09:00:02.835 TRACE nova.compute.manager resources = self.driver.get_available_resource(self.nodename) 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5363, in get_available_resource 2016-05-10 09:00:02.835 TRACE nova.compute.manager data["vcpus"] = self._get_vcpu_total() 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4958, in _get_vcpu_total 2016-05-10 09:00:02.835 TRACE nova.compute.manager available_ids = hardware.get_vcpu_pin_set() 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/hardware.py", line 50, in get_vcpu_pin_set 2016-05-10 09:00:02.835 TRACE nova.compute.manager cpuset_ids = parse_cpu_spec(CONF.vcpu_pin_set) 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/hardware.py", line 113, in parse_cpu_spec 2016-05-10 09:00:02.835 TRACE nova.compute.manager "expression %r") % rule) 2016-05-10 09:00:02.835 TRACE nova.compute.manager Invalid: Invalid inclusion expression 'None' When set vcpu_pin_set to "", raise following exception and nova-compute service fails to start: 2016-05-10 08:55:18.558 TRACE nova.compute.manager Traceback (most recent call last): 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 6460, in update_available_resource 2016-05-10 08:55:18.558 TRACE nova.compute.manager rt.update_available_resource(context) 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 500, in update_available_resource 2016-05-10 08:55:18.558 TRACE nova.compute.manager resources = self.driver.get_available_resource(self.nodename) 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5363, in get_available_resource 2016-05-10 08:55:18.558 TRACE nova.compute.manager data["vcpus"] = self._get_vcpu_total() 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4971, in _get_vcpu_total 2016-05-10 08:55:18.558 TRACE nova.compute.manager if not (available_ids <= online_pcpus): 2016-05-10 08:55:18.558 TRACE nova.compute.manager TypeError: can only compare to a set Environment === Mitaka version and KVM driver To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1579664/+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 1614361] Re: tox.ini needs to be updated as openstack infra now supports upper constraints
Reviewed: https://review.openstack.org/384258 Committed: https://git.openstack.org/cgit/openstack/python-barbicanclient/commit/?id=0a3b995d17cb56586138bd2ecb85a932125c1d42 Submitter: Jenkins Branch:master commit 0a3b995d17cb56586138bd2ecb85a932125c1d42 Author: Jeremy LiuDate: Mon Oct 10 10:08:01 2016 +0800 Support upper-constraints in tox.ini Since the python-barbicanclient itself is in upper-constraints.txt now, in CI job, we should remove it from the constraints file before applying it, otherwise pip will fail due to python-barbicanclient version conflict. Change-Id: I980a85a3b5cc21d2a5029b0e9d8ac2932aa15ba6 Closes-bug: #1614361 ** Changed in: python-barbicanclient Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1614361 Title: tox.ini needs to be updated as openstack infra now supports upper constraints Status in castellan: In Progress Status in Ceilometer: Invalid Status in Cinder: Fix Released Status in Designate: Fix Released Status in Freezer: Fix Released Status in Glance: In Progress Status in heat: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic Inspector: Fix Released Status in Mistral: Fix Released Status in networking-ovn: Invalid Status in octavia: Fix Released Status in python-barbicanclient: Fix Released Status in python-mistralclient: In Progress Status in python-muranoclient: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in OpenStack Object Storage (swift): In Progress Status in tacker: Fix Released Status in OpenStack DBaaS (Trove): Invalid Status in vmware-nsx: Fix Released Status in zaqar: Fix Released Status in Zaqar-ui: Fix Released Bug description: Openstack infra now supports upper constraints for releasenotes, cover, venv targets. tox.ini uses install_command for these targets, which can now be safely removed. Reference for mail that details this support: http://lists.openstack.org/pipermail/openstack-dev/2016-August/101474.html To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1614361/+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 1599889] Re: Change tunnel MTU calculation to support IPv6
Bug was fixed in a general neutron documentation update. ** Changed in: neutron Status: Confirmed => Fix Released ** Changed in: neutron Assignee: Rohan Arora (ra271w) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1599889 Title: Change tunnel MTU calculation to support IPv6 Status in neutron: Fix Released Bug description: https://review.openstack.org/320121 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 51a697817da849c8f9dae9651f17cd863e170fdc Author: Brian HaleyDate: Mon May 23 15:50:06 2016 -0400 Change tunnel MTU calculation to support IPv6 The IPv6 header is twice the size of the IPv4 header, 40 vs 20 bytes, but the tunnel overhead constants are static, only accounting for an IPv4 header in all cases. In order to be correct it needs to treat the tunnel overhead different from the IP overhead at L3. This required removing the 20 byte IP overhead from the tunnel type overhead constants and creating a new option, ml2.overlay_ip_version, in order for the server to know which version will be used, since it calculates the MTU for the network. A version mis-match will now cause a tunnel sync to fail on the server. Moved all MTU tests to a common location to remove duplication. DocImpact Change-Id: Ia2546c4c71ff48b9fe2817fbad22b1fbf85f325b Closes-bug: #1584940 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1599889/+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 1633561] [NEW] Downloaded latest devstack. Did stack.sh and getting glance error
Public bug reported: 2016-10-14 16:09:36.506 | 2016-10-14 12:09:36.506 INFO migrate.versioning.api [-] done 2016-10-14 16:09:36.506 | 2016-10-14 12:09:36.506 INFO migrate.versioning.api [-] 6 -> 7... 2016-10-14 16:09:37.325 | 2016-10-14 12:09:37.325 INFO migrate.versioning.api [-] done 2016-10-14 16:09:37.325 | 2016-10-14 12:09:37.325 INFO migrate.versioning.api [-] 7 -> 8... 2016-10-14 16:09:37.349 | 2016-10-14 12:09:37.334 INFO glance.db.sqlalchemy.migrate_repo.schema [-] creating table image_members 2016-10-14 16:09:39.162 | 2016-10-14 12:09:39.162 INFO migrate.versioning.api [-] done 2016-10-14 16:09:39.162 | 2016-10-14 12:09:39.162 INFO migrate.versioning.api [-] 8 -> 9... 2016-10-14 16:09:40.765 | 2016-10-14 12:09:40.765 INFO migrate.versioning.api [-] done 2016-10-14 16:09:40.765 | 2016-10-14 12:09:40.765 INFO migrate.versioning.api [-] 9 -> 10... 2016-10-14 16:09:40.830 | 2016-10-14 12:09:40.830 INFO migrate.versioning.api [-] done 2016-10-14 16:09:40.831 | 2016-10-14 12:09:40.830 INFO migrate.versioning.api [-] 10 -> 11... 2016-10-14 16:09:42.522 | 2016-10-14 12:09:42.522 INFO migrate.versioning.api [-] done 2016-10-14 16:09:42.522 | 2016-10-14 12:09:42.522 INFO migrate.versioning.api [-] 11 -> 12... 2016-10-14 16:09:42.580 | 2016-10-14 12:09:42.524 CRITICAL glance [-] File "/opt/stack/glance/glance/db/sqlalchemy/migrate_repo/versions/012_id_to_uuid.py", line 123 2016-10-14 16:09:42.580 | SyntaxError: Non-ASCII character '\x94' in file /opt/stack/glance/glance/db/sqlalchemy/migrate_repo/versions/012_id_to_uuid.py on line 123, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details 2016-10-14 16:09:42.580 | 2016-10-14 16:09:42.580 | 2016-10-14 12:09:42.524 TRACE glance Traceback (most recent call last): 2016-10-14 16:09:42.580 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/bin/glance-manage", line 10, in 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance sys.exit(main()) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/opt/stack/glance/glance/cmd/manage.py", line 330, in main 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance return CONF.command.action_fn() 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/opt/stack/glance/glance/cmd/manage.py", line 190, in sync 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance CONF.command.current_version) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/opt/stack/glance/glance/cmd/manage.py", line 108, in sync 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance version) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/migration.py", line 78, in db_sync 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance migration = versioning_api.upgrade(engine, repository, version) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 186, in upgrade 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance return _migrate(url, repository, version, upgrade=True, err=err, **opts) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "", line 2, in _migrate 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py", line 160, in with_engine 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance return f(*a, **kw) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 366, in _migrate 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance schema.runchange(ver, change, changeset.step) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 93, in runchange 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance change.run(self.engine, step) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/script/py.py", line 141, in run 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance script_func = self._func(funcname) 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/script/py.py", line 160, in _func 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance if not hasattr(self.module, funcname): 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance File "/usr/local/lib/python2.7/dist-packages/migrate/versioning/script/py.py", line 156, in module 2016-10-14 16:09:42.581 | 2016-10-14 12:09:42.524 TRACE glance self._module = self.verify_module(self.path) 2016-10-14 16:09:42.581
[Yahoo-eng-team] [Bug 1632513] Re: Nova returns HTTP500 if attaching the attached volume
Reviewed: https://review.openstack.org/385200 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=21961e7bc5c9c9650597a9ed7f15a913fcab09d9 Submitter: Jenkins Branch:master commit 21961e7bc5c9c9650597a9ed7f15a913fcab09d9 Author: Ken'ichi OhmichiDate: Tue Oct 11 16:27:10 2016 -0700 Add InvalidInput handling for attach-volume If attaching the already attached volume to a server, Cinder returns HTTP400 response to Nova but Nova didn't except the response. Then Nova returned HTTP500 response to a client. Tempest test I594566704b9794457d224031802d9cbf132e765f reproduces this error case. Closes-Bug: #1632513 Change-Id: I6718883cb6b42d9b816e3799324a166cbfe92b40 ** 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/1632513 Title: Nova returns HTTP500 if attaching the attached volume Status in OpenStack Compute (nova): Fix Released Bug description: We tried to add some negative test case to Tempest for the other bug. However, Nova still returns HTTP500 error if attaching the already attached volume like: http://logs.openstack.org/83/382083/12/check/gate-tempest-dsvm- neutron-full-ubuntu- xenial/66f700f/logs/screen-n-api.txt.gz#_2016-10-11_19_28_54_097 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions [req-3a860748-ab8f-4ce7-8412-90f787dd151d tempest-AttachVolumeNegativeTest-1404533522 tempest-AttachVolumeNegativeTest-1404533522] Unexpected exception in API method 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/extensions.py", line 338, in wrapped 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/api/openstack/compute/volumes.py", line 325, in create 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions volume_id, device) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 164, in inner 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 145, in inner 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions return f(self, context, instance, *args, **kw) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3481, in attach_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions disk_bus, device_type) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3424, in _attach_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions volume_bdm.destroy() 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions self.force_reraise() 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions six.reraise(self.type_, self.value, self.tb) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3420, in _attach_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions self._check_attach_and_reserve_volume(context, volume_id, instance) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/compute/api.py", line 3407, in _check_attach_and_reserve_volume 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions self.volume_api.reserve_volume(context, volume_id) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions File "/opt/stack/new/nova/nova/volume/cinder.py", line 196, in wrapper 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions _reraise(exception.InvalidInput(reason=err_msg)) 2016-10-11 19:28:54.097 3865 ERROR nova.api.openstack.extensions
[Yahoo-eng-team] [Bug 1329415] Re: pagination and fixed filter will not work together
Bug not valid in Newton, now using ngImages. ** Changed in: horizon Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1329415 Title: pagination and fixed filter will not work together Status in OpenStack Dashboard (Horizon): Invalid Bug description: Steps to Reproduce: 1. Have several images I have 2 Public and 5 Project images as displayed in Admin > Images. Please see (A) in attachment. 2. Now if you go to Project > Images, you will see at the top 3 buttons. For me it says: Project (5), Shared With Me (0) and Public (2) 3. If you click on those, they will show you the images in those categories (see (B) in attachment) 4. Now, check-out this patch: https://bugs.launchpad.net/horizon/+bug/1252649 to enable pagination on Project > Images 5. Go to Settings and set Items Per Page to 2 6. On Project > Images, it says Project (2), Shared With Me (0) and Public (1) (see (C) in attachment) => This is not accurate though. This is applying those filters on the *current items* displayed on the page. With pagination enabled those are only 2 items. DRF Added: the Prev and Next buttons don't work quite as expected here either. I've included my scenario and notes in comments below. Questions: Do we want to pagination and fixed filter to work together? Or just stick with what we have now (even though Glance supports pagination)? Possible solution: I don't think we should use the FixedFilter. It seems like we plan on eventually supporting filtering by column and if we have both FixedFilter and Filter - that would be confusing. Maybe we can add a 'Category' column and have Project, Shared with Me and Public as entries. Then have a dropdown menu with the choice 'Category.' This would be align with the Admin > Instances filter. Something like this? To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1329415/+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 1633306] Re: Partial HA network causing HA router creation failed (race conditon)
Adding a new configuration option is almost never temporary as deleting config options is rarely backward-compatible. The race condition, as I understand it, is as following: 1. Create HA router, have worker1 send 'router_updated' to agent1. 2. Delete HA router (done by worker2). worker2 will now detect that there are no more HA routers and will delete the HA network for the tenant. 3. agent1 issues a 'sync_router', which triggers auto_schedule_routers. create_ha_port_and_bind will try to create the HA port but there are no more IP addresses available, causing add_ha_port to fail as specified in the first paste. Point #3 is a bit weird to me, as it looks like IPAM is detecting a "network deleted during function run" as "no more IP addresses". In addition, this should be caught by [2], forcing a silent retrigger of this issue. Aside from the issue that isn't clear to me, I'd like to point out that the latest stable/mitaka [1] doesn't even trigger auto_schedule_routers on sync_router (not since [3] - perhaps you're missing this backport?) - hence the trace received in the first paste can't be reproduced. For this reason, I'm closing this as Invalid. Liu, feel free to reopen if you disagree with my assessment :) [1]: https://github.com/openstack/neutron/blob/5860fb21e966ab8f1e011654dd477d7af35f7a27/neutron/api/rpc/handlers/l3_rpc.py#L79 [2]: https://github.com/openstack/neutron/blob/5860fb21e966ab8f1e011654dd477d7af35f7a27/neutron/common/utils.py#L726 [3]: https://github.com/openstack/neutron/commit/33650bf1d1994a96eff993af0bfdaa62588f08a4 (5860fb21e966ab8f1e011654dd477d7af35f7a27 is the latest stable/mitaka hash that github.com provided.) ** Changed in: neutron Importance: High => Undecided ** Changed in: neutron Status: Confirmed => Invalid ** Changed in: neutron Milestone: ocata-1 => None -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633306 Title: Partial HA network causing HA router creation failed (race conditon) Status in neutron: Invalid Bug description: ENV: stable/mitaka,VXLAN Neutron API: two neutron-servers behind a HA proxy VIP. Exception log: [1] http://paste.openstack.org/show/585669/ [2] http://paste.openstack.org/show/585670/ Log [1] shows that the subnet of HA network is concurrently deleted while a new HA router create API comes. Seems the race conditon described in this bug is till exists : https://bugs.launchpad.net/neutron/+bug/1533440, where has description said: """ Some known exceptions: ... 2. IpAddressGenerationFailure: (HA port created failed due to the concurrently HA subnet deletion) ... """ Log [2] has a very strange behavior that those 3 APIs have a same request-id [req-780b1f6e-2b3c-4303-a1de-a5fb4c7ea31e]. Test scenario: Just create one HA router for a tenant, and then quickly delete it. For now, our mitaka ENV use VxLAN as tenant network type. So there is a very large range of VNI. So don't save that, and temporarily solution, we add a new config to decide whether delete the HA network every time. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633306/+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 1633518] Re: The passphrase used to encrypt or decrypt volumes was mangled prior to Newton
This also impacts os-brick that has recently copied the encryptor codebase with change : Copy encryptors from Nova to os-brick https://review.openstack.org/#/c/247372/ We should really try to remove the Nova encryptors this cycle I guess ** Also affects: os-brick 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/1633518 Title: The passphrase used to encrypt or decrypt volumes was mangled prior to Newton Status in OpenStack Compute (nova): In Progress Status in os-brick: New Bug description: Description === tl;dr hex(x) previously stripped leading 0's from individual hex numbers while encoding the passphrase back to a hex string before use to encrypt/decrypt a luks volume. Prior to Newton the following method was used to encode passphrases when attempting to use or create a luks volume : def _get_passphrase(self, key): """Convert raw key to string.""" return ''.join(hex(x).replace('0x', '') for x in key) https://github.com/openstack/nova/blob/82190bdd283dda37f7517fd9a268b5e55183f06c/nova/volume/encryptors/cryptsetup.py#L92-L94 This was replaced in Newton with the move to Castellan in the following change that altered both the decoding and encoding steps : Replace key manager with Castellan https://review.openstack.org/#/c/309614/ The original method used the built-in hex() call to convert individual unsigned ints back to hex. This would strip the leading 0 from each hex digit pair, altering the eventual passphrase used to encrypt or decrypt the volume. For example, the following one liner represents both the initial decode step preformed by ConfKeyManager and the step above to encode the passphrase in the LuksEncryptor class : >>> ''.join(hex(x).replace('0x', '') for x in array.array('B', '752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'.decode('hex')).tolist()) '752523eb50c3bf2ba3ff639c2545805fd4e779894ef536e15e081696a' Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a New string : 752523eb50c3bf2ba3ff639c25 4 5805fd4e779894ef536 e15e081696a The returned string is missing various 0's that have been stripped by the hex() call : >>> hex(14) '0xe' >>> int(0x0e) 14 >>> int(0xe) 14 >>> hex(4) '0x4' >>> int(0x04) 4 >>> int(0x4) 4 The following one liner represents the current decode and encode steps, producing the same string as is entered : >>> import binascii >>> binascii.hexlify(bytes(binascii.unhexlify('752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'))).decode('utf-8') u'752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a' Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a New string : 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a IMHO the way to handle this is to add a simple retry in master and stable/newton when we fail due to a bad passphrase using the mangled passphrase. We should also improve the testing in this area as it appears all previous testing used zero based passphrases, missing this issue when it landed in Newton. More notes available downstream in the following bug : Nova encryption alters the key used https://bugzilla.redhat.com/show_bug.cgi?id=1382415 Steps to reproduce == - Encrypt a volume in Mitaka or earlier. - Upgrade to Newton or later. - Attempt to use the volume. Expected result === Volume is decrypted and usable. Actual result = Unable to decrypt the volume due to the use of an modified passphrase during initial formatting and use prior to Newton. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Newton and later. 2. Which hypervisor did you use? Libvirt 2. Which storage type did you use? N/A 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs == N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633518/+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 1633254] Re: Add tag extension to Neutron-Lbaas Resources
** Project changed: ironic => neutron ** Tags added: lbaas ** Summary changed: - Add tag extension to Neutron-Lbaas Resources + [RFE]Add tag extension to Neutron-Lbaas Resources ** Changed in: neutron Assignee: sanaz (s.zakeri) => (unassigned) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633254 Title: [RFE]Add tag extension to Neutron-Lbaas Resources Status in neutron: New Bug description: [Use-cases] - Supporting tag functionality as part of LBaaSv2 Implement tag extension support for LBaaSv2 objects such as Listener, Pool and PoolMember objects. [Limitations] In the Mitaka release Neutron was introduced with the tag extension but unfortunately tags are limited to Neutron project. From the documentation and and comments in the implementation code it is clear that the intent is to extend tags to other Neutron modeled objects. [Enhancement] - Add tag support to LBaaSv2 Objects Extend the tag supported resources of Neutron to LBaaSv2 objects such as Listener, Pool and PoolMember. - Extend existing API Add the support for tags to the Neutron-Lbaas objects API. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633254/+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 1633254] [NEW] Add tag extension to Neutron-Lbaas Resources
You have been subscribed to a public bug: [Use-cases] - Supporting tag functionality as part of LBaaSv2 Implement tag extension support for LBaaSv2 objects such as Listener, Pool and PoolMember objects. [Limitations] In the Mitaka release Neutron was introduced with the tag extension but unfortunately tags are limited to Neutron project. From the documentation and and comments in the implementation code it is clear that the intent is to extend tags to other Neutron modeled objects. [Enhancement] - Add tag support to LBaaSv2 Objects Extend the tag supported resources of Neutron to LBaaSv2 objects such as Listener, Pool and PoolMember. - Extend existing API Add the support for tags to the Neutron-Lbaas objects API. ** Affects: neutron Importance: Undecided Assignee: sanaz (s.zakeri) Status: New ** Tags: rfe -- Add tag extension to Neutron-Lbaas Resources https://bugs.launchpad.net/bugs/1633254 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. -- 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 1633518] [NEW] The passphrase used to encrypt or decrypt volumes was mangled prior to Newton
Public bug reported: Description === tl;dr hex(x) previously stripped leading 0's from individual hex numbers while encoding the passphrase back to a hex string before use to encrypt/decrypt a luks volume. Prior to Newton the following method was used to encode passphrases when attempting to use or create a luks volume : def _get_passphrase(self, key): """Convert raw key to string.""" return ''.join(hex(x).replace('0x', '') for x in key) https://github.com/openstack/nova/blob/82190bdd283dda37f7517fd9a268b5e55183f06c/nova/volume/encryptors/cryptsetup.py#L92-L94 This was replaced in Newton with the move to Castellan in the following change that altered both the decoding and encoding steps : Replace key manager with Castellan https://review.openstack.org/#/c/309614/ The original method used the built-in hex() call to convert individual unsigned ints back to hex. This would strip the leading 0 from each hex digit pair, altering the eventual passphrase used to encrypt or decrypt the volume. For example, the following one liner represents both the initial decode step preformed by ConfKeyManager and the step above to encode the passphrase in the LuksEncryptor class : >>> ''.join(hex(x).replace('0x', '') for x in array.array('B', >>> '752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'.decode('hex')).tolist()) '752523eb50c3bf2ba3ff639c2545805fd4e779894ef536e15e081696a' Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a New string : 752523eb50c3bf2ba3ff639c25 4 5805fd4e779894ef536 e15e081696a The returned string is missing various 0's that have been stripped by the hex() call : >>> hex(14) '0xe' >>> int(0x0e) 14 >>> int(0xe) 14 >>> hex(4) '0x4' >>> int(0x04) 4 >>> int(0x4) 4 The following one liner represents the current decode and encode steps, producing the same string as is entered : >>> import binascii >>> binascii.hexlify(bytes(binascii.unhexlify('752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a'))).decode('utf-8') u'752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a' Original string: 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a New string : 752523eb50c3bf2ba3ff639c250405805fd4e779894ef5360e15e081696a IMHO the way to handle this is to add a simple retry in master and stable/newton when we fail due to a bad passphrase using the mangled passphrase. We should also improve the testing in this area as it appears all previous testing used zero based passphrases, missing this issue when it landed in Newton. More notes available downstream in the following bug : Nova encryption alters the key used https://bugzilla.redhat.com/show_bug.cgi?id=1382415 Steps to reproduce == - Encrypt a volume in Mitaka or earlier. - Upgrade to Newton or later. - Attempt to use the volume. Expected result === Volume is decrypted and usable. Actual result = Unable to decrypt the volume due to the use of an modified passphrase during initial formatting and use prior to Newton. Environment === 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ Newton and later. 2. Which hypervisor did you use? Libvirt 2. Which storage type did you use? N/A 3. Which networking type did you use? (For example: nova-network, Neutron with OpenVSwitch, ...) N/A Logs & Configs == N/A ** Affects: nova Importance: Undecided Status: New ** Summary changed: - Passphrase change + The passphrase used to encrypt or decrypt volumes was mangled prior to Newton -- 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/1633518 Title: The passphrase used to encrypt or decrypt volumes was mangled prior to Newton Status in OpenStack Compute (nova): New Bug description: Description === tl;dr hex(x) previously stripped leading 0's from individual hex numbers while encoding the passphrase back to a hex string before use to encrypt/decrypt a luks volume. Prior to Newton the following method was used to encode passphrases when attempting to use or create a luks volume : def _get_passphrase(self, key): """Convert raw key to string.""" return ''.join(hex(x).replace('0x', '') for x in key) https://github.com/openstack/nova/blob/82190bdd283dda37f7517fd9a268b5e55183f06c/nova/volume/encryptors/cryptsetup.py#L92-L94 This was replaced in Newton with the move to Castellan in the following change that altered both the decoding and encoding steps : Replace key manager with Castellan https://review.openstack.org/#/c/309614/ The original method used the built-in hex() call to convert individual unsigned ints back to hex. This would strip the leading 0 from each hex digit pair, altering the
[Yahoo-eng-team] [Bug 1633514] [NEW] Unable to upload volume data to image on Unified SDK
Public bug reported: This feature is available and works on old SDK (Cinder), but does not on Unified SDK. The image service have an "upload_image" method (on unified SDK) but I cannot get the data to upload it, as the data is stored as a volume in the block store service, and the only way to download it is through glance - which is what I am trying to achieve. Here follows some code sample: --- UNIFIED SDK --- from openstack import connection import glanceclient.v2.client as glance_client from keystoneclient.auth.identity import v3 from keystoneauth1 import session import cinderclient.v3.client as cinder_client import sys import os import time import getopt import json import subprocess def get_connection_to_services(auth_url, username, password, user_domain_name, project_name, project_domain_name): conn = connection.Connection( auth_url=auth_url, project_name=project_name, project_domain_name=project_domain_name, username=username, user_domain_name=user_domain_name, password=password) return conn inputfile = 'credentials.json' with open(inputfile) as json_file: json_string = json_file.read() json_obj = json.loads(json_string) username= json_obj["username"] password= json_obj["password"] auth_url_sdk= json_obj["auth_url_sdk"] user_domain_name= json_obj["user_domain_name"] project_domain_name = json_obj["project_domain_name"] project_name= json_obj["project_name"] conn = get_connection_to_services( auth_url=auth_url_sdk, project_name=project_name, project_domain_name=project_domain_name, username=username, user_domain_name=user_domain_name, password=password) compute_service = conn.compute network_service = conn.network image_service = conn.image block_service = conn.block_store # id of desired volume to upload to glance. id = 'e5b40f95-0e24-46d0-a405-6759b4167f97' # type of volume: openstack.block_store.v2.volume.Volume volume = block_service.get_volume(id) #cinder volume url data = 'http://10.32.135.74:8776/v2/8136b8ab6da346ed8c342022a91aa975/volumes/e5b40f95-0e24-46d0-a405-6759b4167f97' # this throws an error image_service.upload_image('bare', 'raw', volume) # instead of volume, if we use data, it upload the url string bytes image_service.upload_image('bare', 'raw', data) Cinder SDK def get_session(auth_url, username, password, user_domain_name, project_name, project_domain_name): auth = v3.Password( auth_url=auth_url, username=username, password=password, user_domain_name=user_domain_name, project_name=project_name, project_domain_name=project_domain_name) return session.Session(auth=auth) old_session = get_session( auth_url_sdk, username, password, user_domain_name, project_name, project_domain_name) cinder = cinder_client.Client(session=old_session) # type of volume2 = cinderclient.v3.volumes.Volume volume2 = cinder.volumes.get(id) body = {'force': 'false','image_name': 'volume2', 'container_format': 'bare', 'disk_format': 'raw'} # works like a charm :D volume2.upload_to_image(**body) ** Affects: python-openstacksdk Importance: Undecided Status: New ** Tags: cinder image-upload volumes ** Project changed: nova => cinder ** Project changed: cinder => python-openstacksdk -- 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/1633514 Title: Unable to upload volume data to image on Unified SDK Status in OpenStack SDK: New Bug description: This feature is available and works on old SDK (Cinder), but does not on Unified SDK. The image service have an "upload_image" method (on unified SDK) but I cannot get the data to upload it, as the data is stored as a volume in the block store service, and the only way to download it is through glance - which is what I am trying to achieve. Here follows some code sample: --- UNIFIED SDK --- from openstack import connection import glanceclient.v2.client as glance_client from keystoneclient.auth.identity import v3 from keystoneauth1 import session import cinderclient.v3.client as cinder_client import sys import os import time import getopt import json import subprocess def get_connection_to_services(auth_url, username, password, user_domain_name, project_name, project_domain_name): conn = connection.Connection( auth_url=auth_url, project_name=project_name, project_domain_name=project_domain_name, username=username,
[Yahoo-eng-team] [Bug 1614019] Re: Instances lose its serial ports during soft-reboot after live-migration
Reviewed: https://review.openstack.org/356335 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=dccaf9cb88705b2a635c5b54433c5e6187557849 Submitter: Jenkins Branch:master commit dccaf9cb88705b2a635c5b54433c5e6187557849 Author: Sahid Orentino FerdjaouiDate: Wed Aug 17 05:18:45 2016 -0400 libvirt: fix serial console not correctly defined after live-migration During post live migration the XML defined in libvirt does not contain the definition of serial ports. That is because we call the method get_guest_config_xml to retrieve the XML definition which is not going to return a definition of serial ports because the instance already define them. Actually calling this method to retrieve domain XML of an instance is not good in every cases because the aim of that method is to define a domain XML not to return a domain XML, for that purpose we prefer to call XMLDesc(0). Also that commit is removing the process to write into a file the domain XML which is not used anymore. libvirtd is storing the XML definition of domains by itself (see: guest.write_instance_config()) Closes-Bug: #1614019 Change-Id: I230031bba3926171a80ae773a98280ac5c61058b ** 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/1614019 Title: Instances lose its serial ports during soft-reboot after live- migration Status in OpenStack Compute (nova): Fix Released Bug description: Instances lose its serial ports during soft-reboot if the instances experienced live-migration just before. Therefore we cannot access to the instance from serial console after soft-reboot. That is because the method post_live_migration which defines the domain XML to libvirt on the destination host is calling the method get_guest_config instead of just retrieving the domain XML of the migrated and running guest. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1614019/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
Reviewed: https://review.openstack.org/385901 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=43f5b5912f91d04ea9abcc8ea386b0ad2448da7b Submitter: Jenkins Branch:master commit 43f5b5912f91d04ea9abcc8ea386b0ad2448da7b Author: shashi.kantDate: Thu Oct 13 16:12:42 2016 +0530 Drop MANIFEST.in - it's not needed by pbr Neutron already uses PBR:- setuptools.setup( setup_requires=['pbr>=1.8'], pbr=True) This patch removes `MANIFEST.in` file as pbr generates a sensible manifest from git files and some standard files and it removes the need for an explicit `MANIFEST.in` file. Change-Id: I902f29fedb4b756af978af52927bd32a51270dc8 Closes-Bug: #1608980 ** 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: Fix Released Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in python-searchlightclient: In Progress Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in Swift Authentication: In Progress Status in OpenStack Object Storage (swift): In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1579664] Re: Nova-compute raise exception when vcpu_pin_set is set to None or"".
Reviewed: https://review.openstack.org/314076 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=8b199c6dff4c61169a9eb916511b716d8f20c015 Submitter: Jenkins Branch:master commit 8b199c6dff4c61169a9eb916511b716d8f20c015 Author: Davanum SrinivasDate: Mon May 9 08:23:25 2016 -0400 Fix exception when vcpu_pin_set is set to "" We should treat vcpu_pin_set="", same as vcpu_pin_set=None and avoid the problem mentioned in the bug report. Closes-Bug: #1579664 Change-Id: Ifa2b960aa74072ba668c9d028df108af6156fe40 ** 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/1579664 Title: Nova-compute raise exception when vcpu_pin_set is set to None or"". Status in OpenStack Compute (nova): Fix Released Bug description: Description === In Mitaka, Nova-compute raise exception when vcpu_pin_set is set to None or"".And nova-compute fails to start. Steps to reproduce == Edit vcpu_pin_set=None or vcpu_pin_set="" then restart nova-compute service Expected result === Get_vcpu_total returns total_pcpus, and nova-compute service starts successfully. Actual result = When set vcpu_pin_set to None, raise following exception and nova-compute service fails to start: 2016-05-10 09:00:02.835 TRACE nova.compute.manager Traceback (most recent call last): 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 6460, in update_available_resource 2016-05-10 09:00:02.835 TRACE nova.compute.manager rt.update_available_resource(context) 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 500, in update_available_resource 2016-05-10 09:00:02.835 TRACE nova.compute.manager resources = self.driver.get_available_resource(self.nodename) 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5363, in get_available_resource 2016-05-10 09:00:02.835 TRACE nova.compute.manager data["vcpus"] = self._get_vcpu_total() 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4958, in _get_vcpu_total 2016-05-10 09:00:02.835 TRACE nova.compute.manager available_ids = hardware.get_vcpu_pin_set() 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/hardware.py", line 50, in get_vcpu_pin_set 2016-05-10 09:00:02.835 TRACE nova.compute.manager cpuset_ids = parse_cpu_spec(CONF.vcpu_pin_set) 2016-05-10 09:00:02.835 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/hardware.py", line 113, in parse_cpu_spec 2016-05-10 09:00:02.835 TRACE nova.compute.manager "expression %r") % rule) 2016-05-10 09:00:02.835 TRACE nova.compute.manager Invalid: Invalid inclusion expression 'None' When set vcpu_pin_set to "", raise following exception and nova-compute service fails to start: 2016-05-10 08:55:18.558 TRACE nova.compute.manager Traceback (most recent call last): 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/manager.py", line 6460, in update_available_resource 2016-05-10 08:55:18.558 TRACE nova.compute.manager rt.update_available_resource(context) 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/compute/resource_tracker.py", line 500, in update_available_resource 2016-05-10 08:55:18.558 TRACE nova.compute.manager resources = self.driver.get_available_resource(self.nodename) 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5363, in get_available_resource 2016-05-10 08:55:18.558 TRACE nova.compute.manager data["vcpus"] = self._get_vcpu_total() 2016-05-10 08:55:18.558 TRACE nova.compute.manager File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4971, in _get_vcpu_total 2016-05-10 08:55:18.558 TRACE nova.compute.manager if not (available_ids <= online_pcpus): 2016-05-10 08:55:18.558 TRACE nova.compute.manager TypeError: can only compare to a set Environment === Mitaka version and KVM driver To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1579664/+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 1633447] [NEW] nova stop/start or reboot --hard rests uefi nvram
Public bug reported: Using nova to boot UEFI instances in certain circumstances the nvram is cleared e.g. on a deployed node my nvram is set too boot from the grub installed on the EFI partition [root@t1 boot]# efibootmgr Timeout: 0 seconds BootOrder: 0004,0002,,0001,0003 Boot* EFI Floppy Boot0001* EFI Floppy 1 Boot0002* EFI Hard Drive Boot0003* EFI Network Boot0004* centos This is working I can run > nova reboot dbdc6b36-1f17-4722-89e5-117986b10059 but if I run a nova reboot --hard or a combination of nova stop/start then the libvirt domain is redefined, as part of this process the nvram is reset, the boot process stalls at the boot menu and I have to select boot from file [root@t1 boot]# efibootmgr Timeout: 0 seconds BootOrder: 0002,,0001,0003 Boot* EFI Floppy Boot0001* EFI Floppy 1 Boot0002* EFI Hard Drive Boot0003* EFI Network ** 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/1633447 Title: nova stop/start or reboot --hard rests uefi nvram Status in OpenStack Compute (nova): New Bug description: Using nova to boot UEFI instances in certain circumstances the nvram is cleared e.g. on a deployed node my nvram is set too boot from the grub installed on the EFI partition [root@t1 boot]# efibootmgr Timeout: 0 seconds BootOrder: 0004,0002,,0001,0003 Boot* EFI Floppy Boot0001* EFI Floppy 1 Boot0002* EFI Hard Drive Boot0003* EFI Network Boot0004* centos This is working I can run > nova reboot dbdc6b36-1f17-4722-89e5-117986b10059 but if I run a nova reboot --hard or a combination of nova stop/start then the libvirt domain is redefined, as part of this process the nvram is reset, the boot process stalls at the boot menu and I have to select boot from file [root@t1 boot]# efibootmgr Timeout: 0 seconds BootOrder: 0002,,0001,0003 Boot* EFI Floppy Boot0001* EFI Floppy 1 Boot0002* EFI Hard Drive Boot0003* EFI Network To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1633447/+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 1629797] Re: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up
** Bug watch added: freedesktop.org Bugzilla #98254 https://bugs.freedesktop.org/show_bug.cgi?id=98254 ** Also affects: dbus via https://bugs.freedesktop.org/show_bug.cgi?id=98254 Importance: Unknown Status: Unknown ** Changed in: dbus (Ubuntu) Status: Triaged => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1629797 Title: resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up Status in cloud-init: Fix Committed Status in D-Bus: Unknown Status in cloud-init package in Ubuntu: Fix Released Status in dbus package in Ubuntu: In Progress Bug description: During boot, cloud-init does DNS resolution checks to if particular metadata services are available (in order to determine which cloud it is running on). These checks happen before systemd-resolved is up[0] and if they resolve unsuccessfully they take 25 seconds to complete. This has substantial impact on boot time in all contexts, because cloud-init attempts to resolve three known-invalid addresses ("does- not-exist.example.com.", "example.invalid." and a random string) to enable it to detect when it's running in an environment where a DNS server will always return some sort of redirect. As such, we're talking a minimum impact of 75 seconds in all environments. This increases when cloud-init is configured to check for multiple environments. This means that yakkety is consistently taking 2-3 minutes to boot on EC2 and GCE, compared to the ~30 seconds of the first boot and ~10 seconds thereafter in xenial. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1629797/+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 1631319] Re: Can't deploy overcloud of Mitaka on CentOS
verified. now it works. ** Changed in: tripleo Status: Triaged => 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/1631319 Title: Can't deploy overcloud of Mitaka on CentOS Status in OpenStack Identity (keystone): Invalid Status in tripleo: Fix Released Bug description: CentOS 7.2 Undercloud deployed normally by tripleo instructions. keystone - Version : 9.2.1 Release : 0.20161007011449.012bc3d.el7.centos heat-api - Version : 6.0.1 Release : 0.20160829124409.ed46562.el7.centos These numbers tell us that undercloud installed from Mitaka repository But overcloud deploy fails with error - [stack@myhost ~]$ openstack overcloud deploy --templates --neutron-tunnel-types vxlan --neutron-network-type vxlan --ntp-server pool.ntp.org --control-scale 1 --compute-scale 1 --block-storage-scale 3 --control-flavor control --compute-flavor compute --block-storage-flavor block-storage -e overcloud/scaleio-env.yaml Deploying templates in the directory /usr/share/openstack-tripleo-heat-templates ERROR: Authorization failed. keystone logs contains error: domain Default can not be found workaround - change domain from 'Default' to 'default' in heat-api.conf and then overcloud deploy can be started... To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1631319/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: python-searchlightclient Importance: Undecided Status: New ** Changed in: python-searchlightclient Assignee: (unassigned) => iswarya vakati (v-iswarya) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in python-searchlightclient: In Progress Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in Swift Authentication: In Progress Status in OpenStack Object Storage (swift): In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633405] [NEW] Lock/Unlock status not visible in dashboard or action log
Public bug reported: It appears that when the Lock Instance / Unlock Instance options are used on a compute instance, nothing is indicated within the dashboard or action log to suggest this is the case. Steps to repeat: Log into dashboard Click instances >From the drop down on the right of a given instance, select Lock instance Try to power on/off/restart the instance, You will get the error: Error: Unable to shut off instance: , with no indication of the reason. Click into the instance and click the action log, there is no record there of the instance being locked. This makes it difficult for an end user to determine why they cannot interact with their instance. Version info: ii python-django-horizon 2:9.1.0-0ubuntu1all Django module providing web based interaction with OpenStack ii openstack-dashboard-ubuntu-theme 2:9.1.0-0ubuntu1all Ubuntu theme for the OpenStack dashboard ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1633405 Title: Lock/Unlock status not visible in dashboard or action log Status in OpenStack Dashboard (Horizon): New Bug description: It appears that when the Lock Instance / Unlock Instance options are used on a compute instance, nothing is indicated within the dashboard or action log to suggest this is the case. Steps to repeat: Log into dashboard Click instances From the drop down on the right of a given instance, select Lock instance Try to power on/off/restart the instance, You will get the error: Error: Unable to shut off instance: , with no indication of the reason. Click into the instance and click the action log, there is no record there of the instance being locked. This makes it difficult for an end user to determine why they cannot interact with their instance. Version info: ii python-django-horizon 2:9.1.0-0ubuntu1all Django module providing web based interaction with OpenStack ii openstack-dashboard-ubuntu-theme 2:9.1.0-0ubuntu1all Ubuntu theme for the OpenStack dashboard To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1633405/+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 1633385] [NEW] fwaas v2 installation with devstack set the wrong plugin class path in neutron.conf
Public bug reported: This issue will be hit during devstack installation if we use q-fwaas-v2. The neutron.conf genarated automaticly will set the fwaas v2 service plugin with the wrong class path. neutron.conf --- [DEFAULT] . service_plugins = neutron_fwaas.services.firewall.fwaas_plugin_v2.FirewallPluginV2 endpoint.txt --- [neutron.service_plugins] firewall = neutron_fwaas.services.firewall.fwaas_plugin:FirewallPlugin firewall_v2 = neutron_fwaas.services.firewall.fwaas_plugin_v2:FirewallPluginV2 neutron.services.firewall.fwaas_plugin.FirewallPlugin = neutron_fwaas.services.firewall.fwaas_plugin:FirewallPlugin ** Affects: neutron Importance: Undecided Assignee: zhaobo (zhaobo6) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => zhaobo (zhaobo6) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633385 Title: fwaas v2 installation with devstack set the wrong plugin class path in neutron.conf Status in neutron: In Progress Bug description: This issue will be hit during devstack installation if we use q-fwaas-v2. The neutron.conf genarated automaticly will set the fwaas v2 service plugin with the wrong class path. neutron.conf --- [DEFAULT] . service_plugins = neutron_fwaas.services.firewall.fwaas_plugin_v2.FirewallPluginV2 endpoint.txt --- [neutron.service_plugins] firewall = neutron_fwaas.services.firewall.fwaas_plugin:FirewallPlugin firewall_v2 = neutron_fwaas.services.firewall.fwaas_plugin_v2:FirewallPluginV2 neutron.services.firewall.fwaas_plugin.FirewallPlugin = neutron_fwaas.services.firewall.fwaas_plugin:FirewallPlugin To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633385/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
** Also affects: swauth Importance: Undecided Status: New ** Changed in: swauth Assignee: (unassigned) => abdul nizamuddin (abdul-nizamuddin) ** Changed in: swauth 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in Swift Authentication: In Progress Status in OpenStack Object Storage (swift): In Progress Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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 1633343] [NEW] agent/linux/utils.py: string match will fail in the i18n situation
Public bug reported: In function execute(), exception RuntimeError may be raised. The users of execute() may match the return code or other message, but this will be wrong in i18n. ** Affects: neutron Importance: Undecided Assignee: Duan Jiong (duanjiong) Status: New ** Tags: utils ** Changed in: neutron Assignee: (unassigned) => Duan Jiong (duanjiong) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1633343 Title: agent/linux/utils.py: string match will fail in the i18n situation Status in neutron: New Bug description: In function execute(), exception RuntimeError may be raised. The users of execute() may match the return code or other message, but this will be wrong in i18n. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1633343/+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 1629227] Re: Floating-ip-creation
** Changed in: neutron Status: Opinion => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629227 Title: Floating-ip-creation Status in neutron: Incomplete Bug description: On network node a floating ip is being created by assigning a range of floating ip address to external network pool on routers, where gateway addresses and dhcp is disabled, but here neutronclient/v2_0/client.py returns an empty list to ceilometer which is wrong it should return a floating ip status or something meaningful. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1629227/+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 1633339] [NEW] test_routers_flavors is assuming the reference l3 plugin
Public bug reported: test_routers_flavors is assuming the reference l3 plugin. specifically it assumes specific service profile drivers. ** Affects: neutron Importance: Undecided Assignee: YAMAMOTO Takashi (yamamoto) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => YAMAMOTO Takashi (yamamoto) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/169 Title: test_routers_flavors is assuming the reference l3 plugin Status in neutron: In Progress Bug description: test_routers_flavors is assuming the reference l3 plugin. specifically it assumes specific service profile drivers. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/169/+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 1633337] [NEW] There is no event send out when floating updated
Public bug reported: We register the event with this constant https://github.com/openstack/neutron/blob/master/neutron/callbacks/resources.py#L16, It is the string 'floating_ip'. But from the log message "Notify callbacks [] for floatingip, before_response", the resource name is 'floatingip'. There is no '_'. Due to this different name for the resource, there is no event send out when floating ip updated. ** Affects: neutron Importance: Undecided Assignee: Alex Xu (xuhj) Status: New ** Changed in: neutron Assignee: (unassigned) => Alex Xu (xuhj) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/167 Title: There is no event send out when floating updated Status in neutron: New Bug description: We register the event with this constant https://github.com/openstack/neutron/blob/master/neutron/callbacks/resources.py#L16, It is the string 'floating_ip'. But from the log message "Notify callbacks [] for floatingip, before_response", the resource name is 'floatingip'. There is no '_'. Due to this different name for the resource, there is no event send out when floating ip updated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/167/+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 1608980] Re: Remove MANIFEST.in as it is not explicitly needed by PBR
Fix proposed to branch: master Review: https://review.openstack.org/386386 ** Changed in: searchlight Status: New => In Progress ** Changed in: gce-api 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/1608980 Title: Remove MANIFEST.in as it is not explicitly needed by PBR Status in craton: In Progress Status in ec2-api: In Progress Status in gce-api: Fix Released Status in Karbor: In Progress Status in OpenStack Identity (keystone): In Progress Status in Kosmos: New Status in Magnum: Fix Released Status in masakari: In Progress Status in neutron: In Progress Status in Neutron LBaaS Dashboard: Confirmed Status in octavia: Fix Released Status in OpenStack Search (Searchlight): In Progress Status in Solum: In Progress Status in OpenStack Object Storage (swift): New Status in Tricircle: Fix Released Status in OpenStack DBaaS (Trove): In Progress Status in watcher: In Progress Status in Zun: Fix Released Bug description: PBR do not explicitly require MANIFEST.in, so it can be removed. Snippet from: http://docs.openstack.org/infra/manual/developers.html Manifest Just like AUTHORS and ChangeLog, why keep a list of files you wish to include when you can find many of these in git. MANIFEST.in generation ensures almost all files stored in git, with the exception of .gitignore, .gitreview and .pyc files, are automatically included in your distribution. In addition, the generated AUTHORS and ChangeLog files are also included. In many cases, this removes the need for an explicit ‘MANIFEST.in’ file To manage notifications about this bug go to: https://bugs.launchpad.net/craton/+bug/1608980/+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