date:20161014

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)

2016-10-14 Thread LIU Yulong

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

2016-10-14 Thread Will Bryant

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 Liu 
Date:   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 Chen 
Date:   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 Davidge 
Date:   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

2016-10-14 Thread Carl Baldwin

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 Baldwin 
  Date:   Tue Feb 9 16:39:01 2016 -0700

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

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

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

[Yahoo-eng-team] [Bug 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_Vakati 
Date:   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 Liu 
Date:   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

2016-10-14 Thread Rohan Arora

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 Haley 
  Date:   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

2016-10-14 Thread work.kul...@gmail.com

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 Ohmichi 
Date:   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

2016-10-14 Thread Eddie Ramirez

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)

2016-10-14 Thread John Schwarz

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

2016-10-14 Thread Lee Yarwood

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

2016-10-14 Thread sanaz

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

2016-10-14 Thread Launchpad Bug Tracker

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

2016-10-14 Thread Lee Yarwood

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

2016-10-14 Thread Thiago Carreira

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 Ferdjaoui 
Date:   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.kant 
Date:   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 Srinivas 
Date:   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

2016-10-14 Thread Derek Higgins

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

2016-10-14 Thread Martin Pitt

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

2016-10-14 Thread Andrey Pavlov

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

2016-10-14 Thread iswarya vakati

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

2016-10-14 Thread sean redmond

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

2016-10-14 Thread zhaobo

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

2016-10-14 Thread abdul nizamuddin

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

2016-10-14 Thread Duan Jiong

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

2016-10-14 Thread Vishal

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

2016-10-14 Thread YAMAMOTO Takashi

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

2016-10-14 Thread Alex Xu

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