[Yahoo-eng-team] [Bug 1335744] [NEW] VMware: port group and vm are created in different exsi when using vlanDHCPmanage
Public bug reported: When using vlanDHCPmanage it is supposed to create a portgroup if the portgroups doesn't exist in the vCenter. I found that it is possible that the created portgroup and deployed vm are located in different exsis if there are more than 1 exsi under cluster. The deployment is shown as successful. Of course the IPs are not correct. ** Affects: nova Importance: Undecided Status: New ** Tags: vmware -- 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/1335744 Title: VMware: port group and vm are created in different exsi when using vlanDHCPmanage Status in OpenStack Compute (Nova): New Bug description: When using vlanDHCPmanage it is supposed to create a portgroup if the portgroups doesn't exist in the vCenter. I found that it is possible that the created portgroup and deployed vm are located in different exsis if there are more than 1 exsi under cluster. The deployment is shown as successful. Of course the IPs are not correct. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1335744/+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 1335821] [NEW] Unit tests use inconsistent default tenant id
Public bug reported: Meters and security groups use 'test_tenant' while all other resources use 'test-tenant'. This means that a test that creates multiple types of resources (While using the the default tenant id) would find that some resources were created under one tenant, and other resources under another tenant. For example, a test creates a network, subnet, port, security group and meter label + rule. Listing all resources that belong to the 'test- tenant' would return a partial list, leading to confusing results. ** Affects: neutron Importance: Undecided Assignee: Assaf Muller (amuller) Status: In Progress ** Tags: unittest ** Changed in: neutron Assignee: (unassigned) = Assaf Muller (amuller) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1335821 Title: Unit tests use inconsistent default tenant id Status in OpenStack Neutron (virtual network service): In Progress Bug description: Meters and security groups use 'test_tenant' while all other resources use 'test-tenant'. This means that a test that creates multiple types of resources (While using the the default tenant id) would find that some resources were created under one tenant, and other resources under another tenant. For example, a test creates a network, subnet, port, security group and meter label + rule. Listing all resources that belong to the 'test-tenant' would return a partial list, leading to confusing results. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335821/+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 1334297] Re: Strange response from os-server-groups with bad parameter
So in the end I don't think this is a Nova bug. The first line of the
request to the Nova API server looks like this:
DELETE /v2/f9cea8784d7245e5a8022a259bb92d90/os-server-
groups/{u'policies': [u'affinity'], u'name': u'server-group-1646113520',
u'id': u'b5316a4a-f6eb-4a7f-8b24-028b799bf6a9', u'members': [],
u'metadata': {}} HTTP/1.1
Which is not a valid header. It is so badly formatted that I believe a
reasonable parser implementation could not necessarily know that the
client is requesting a response in HTTP/1.1 format as the uri is so
corrupt. Looking from the end it can be clearly seen, but the request is
definitely corrupt. BaseHTTPServer by default responds in HTTP/0.9
protocol if its not sure.
So it does return a 400, but in HTTP/0.9 protocol:
titleError response/title
/head
body
h1Error response/h1
pError code 400.
pMessage: Bad request syntax (DELETE
/v2/f9cea8784d7245e5a8022a259bb92d90/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1646113520', u'id':
u'b5316a4a-f6eb-4a7f-8b24-028b799bf6a9', u'members': [], u'metadata': {}}
HTTP/1.1).
pError code explanation: 400 = Bad request syntax or unsupported method.
/body
httplib2 on the tempest side made the request in HTTP/1.1 protocol, but
does not appear to try to parse it in HTTP/0.9 format if it doesn't get
an HTTP/1.1 header. According to RFC 1945 it should be able to do so. So
technically its a tempest bug. Not sure if its worth fixing though
** Also affects: tempest
Importance: Undecided
Status: New
** Changed in: tempest
Importance: Undecided = Low
** Changed in: nova
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1334297
Title:
Strange response from os-server-groups with bad parameter
Status in OpenStack Compute (Nova):
Invalid
Status in Tempest:
New
Bug description:
There was a bug in tempest that caused a call to DELETE os-server-
groups with a bad id. Here is the call from the tempest log:
2014-06-25 12:07:03.162 25653 INFO tempest.common.rest_client [-]
Request (ServerGroupTestJSON:tearDownClass): 200 DELETE
http://127.0.0.1:8774/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-
groups/{u'policies': [u'affinity'], u'name': u'server-
group-1944635656', u'id': u'7c6a13c1-6d8b-4314-9d16-4eb6418a2170',
u'members': [], u'metadata': {}} 0.001s
Normally DELETE will return 204 and in this case I would have expected
400. But the call returns 200. What can be seen in the nova log seems
to indicate 400 but that is not what is actually getting sent back:
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1944635656', u'id':
u'7c6a13c1-6d8b-4314-9d16-4eb6418a2170', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1944635656', u'id':
u'7c6a13c1-6d8b-4314-9d16-4eb6418a2170', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'd361d100-fc59-4393-b61b-30a2d4b27b6e', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'd361d100-fc59-4393-b61b-30a2d4b27b6e', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'9f8574d7-78b9-4926-98ea-61f2da971478', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-1366165944', u'id':
u'9f8574d7-78b9-4926-98ea-61f2da971478', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03] code 400, message Bad request syntax
(DELETE /v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-2072440191', u'id':
u'01342594-9661-47fb-8816-e816ad2cae37', u'members': [], u'metadata': {}}
HTTP/1.1)
127.0.0.1 - - [25/Jun/2014 12:07:03] DELETE
/v2/2bc18b72010d455a9db7cbc583e1dcfc/os-server-groups/{u'policies':
[u'affinity'], u'name': u'server-group-2072440191', u'id':
u'01342594-9661-47fb-8816-e816ad2cae37', u'members': [], u'metadata': {}}
HTTP/1.1 400 -
127.0.0.1 - - [25/Jun/2014 12:07:03]
[Yahoo-eng-team] [Bug 1335859] [NEW] Wrong assert in nova.tests.virt.vmwareapi.test_vmops.py
Public bug reported: bad assertion in nova.tests.virt.vmwareapi.vmwareapi.test_vmops.py:640 self.assertTrue(3, len(mock_mkdir.mock_calls)) should be replaced with assertEqual ** Affects: nova Importance: Undecided Assignee: Sergey Nikitin (snikitin) Status: New ** Changed in: nova Assignee: (unassigned) = Sergey Nikitin (snikitin) -- 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/1335859 Title: Wrong assert in nova.tests.virt.vmwareapi.test_vmops.py Status in OpenStack Compute (Nova): New Bug description: bad assertion in nova.tests.virt.vmwareapi.vmwareapi.test_vmops.py:640 self.assertTrue(3, len(mock_mkdir.mock_calls)) should be replaced with assertEqual To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1335859/+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 1335878] [NEW] test_download_policy_when_cache_is_not_enabled fails with ECONNREFUSED
Public bug reported:
Failed in the gate:
http://logs.openstack.org/64/102664/2/gate/gate-glance-
python26/e19799f/console.html#_2014-06-30_05_00_48_142
2014-06-30 05:00:48.141 | FAIL:
glance.tests.functional.v2.test_images.TestImages.test_download_policy_when_cache_is_not_enabled
2014-06-30 05:00:48.141 | tags: worker-0
2014-06-30 05:00:48.141 |
--
2014-06-30 05:00:48.141 | Traceback (most recent call last):
2014-06-30 05:00:48.141 | File glance/tests/functional/v2/test_images.py,
line 468, in test_download_policy_when_cache_is_not_enabled
2014-06-30 05:00:48.141 | response = requests.post(path, headers=headers,
data=data)
2014-06-30 05:00:48.141 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/api.py,
line 88, in post
2014-06-30 05:00:48.141 | return request('post', url, data=data, **kwargs)
2014-06-30 05:00:48.141 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/api.py,
line 44, in request
2014-06-30 05:00:48.142 | return session.request(method=method, url=url,
**kwargs)
2014-06-30 05:00:48.142 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/sessions.py,
line 456, in request
2014-06-30 05:00:48.142 | resp = self.send(prep, **send_kwargs)
2014-06-30 05:00:48.142 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/sessions.py,
line 559, in send
2014-06-30 05:00:48.142 | r = adapter.send(request, **kwargs)
2014-06-30 05:00:48.142 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/adapters.py,
line 375, in send
2014-06-30 05:00:48.142 | raise ConnectionError(e, request=request)
2014-06-30 05:00:48.142 | ConnectionError: HTTPConnectionPool(host='127.0.0.1',
port=60936): Max retries exceeded with url: /v2/images (Caused by class
'socket.error': [Errno 111] ECONNREFUSED)
This appears to be a race.
** Affects: glance
Importance: Undecided
Status: New
** Tags: gate-failure testing
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1335878
Title:
test_download_policy_when_cache_is_not_enabled fails with ECONNREFUSED
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Bug description:
Failed in the gate:
http://logs.openstack.org/64/102664/2/gate/gate-glance-
python26/e19799f/console.html#_2014-06-30_05_00_48_142
2014-06-30 05:00:48.141 | FAIL:
glance.tests.functional.v2.test_images.TestImages.test_download_policy_when_cache_is_not_enabled
2014-06-30 05:00:48.141 | tags: worker-0
2014-06-30 05:00:48.141 |
--
2014-06-30 05:00:48.141 | Traceback (most recent call last):
2014-06-30 05:00:48.141 | File glance/tests/functional/v2/test_images.py,
line 468, in test_download_policy_when_cache_is_not_enabled
2014-06-30 05:00:48.141 | response = requests.post(path, headers=headers,
data=data)
2014-06-30 05:00:48.141 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/api.py,
line 88, in post
2014-06-30 05:00:48.141 | return request('post', url, data=data, **kwargs)
2014-06-30 05:00:48.141 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/api.py,
line 44, in request
2014-06-30 05:00:48.142 | return session.request(method=method, url=url,
**kwargs)
2014-06-30 05:00:48.142 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/sessions.py,
line 456, in request
2014-06-30 05:00:48.142 | resp = self.send(prep, **send_kwargs)
2014-06-30 05:00:48.142 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/sessions.py,
line 559, in send
2014-06-30 05:00:48.142 | r = adapter.send(request, **kwargs)
2014-06-30 05:00:48.142 | File
/home/jenkins/workspace/gate-glance-python26/.tox/py26/lib/python2.6/site-packages/requests/adapters.py,
line 375, in send
2014-06-30 05:00:48.142 | raise ConnectionError(e, request=request)
2014-06-30 05:00:48.142 | ConnectionError:
HTTPConnectionPool(host='127.0.0.1', port=60936): Max retries exceeded with
url: /v2/images (Caused by class 'socket.error': [Errno 111] ECONNREFUSED)
This appears to be a race.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1335878/+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 1334798] Re: Gate test is masking failure details
I think that's the behavior of the testr, but that's what needs to be verified.
I doubt we can do anything in neutron to address this
** Tags added: unittest
** Changed in: neutron
Importance: Undecided = Low
** Changed in: neutron
Status: New = Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1334798
Title:
Gate test is masking failure details
Status in OpenStack Neutron (virtual network service):
Opinion
Bug description:
Both the 2.6 and 2.7 gate tests are failing, console log indicating
two failures, but only showing one failure 'process-retcode'. When
looking at testr_results it shows a fail and only mentions:
ft1.12873:
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used_StringException
Here is 2.7 logs: http://logs.openstack.org/51/102351/4/check/gate-
neutron-python27/a757b36/
Upon future investigation, it was found that there was non-printable
characters in an oslo file. With manual testing, it shows the error:
$ python -m neutron.openstack.common.lockutils python -m unittest
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
F
==
FAIL: test_reference_driver_used
(neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection)
neutron.tests.unit.services.vpn.service_drivers.test_ipsec.TestValidatorSelection.test_reference_driver_used
--
_StringException: Empty attachments:
pythonlogging:''
pythonlogging:'neutron.api.extensions'
traceback-1: {{{
Traceback (most recent call last):
File neutron/common/rpc.py, line 63, in cleanup
assert TRANSPORT is not None
AssertionError
}}}
Traceback (most recent call last):
File neutron/tests/unit/services/vpn/service_drivers/test_ipsec.py, line
52, in setUp
super(TestValidatorSelection, self).setUp()
File neutron/tests/base.py, line 188, in setUp
n_rpc.init(CONF)
File neutron/common/rpc.py, line 56, in init
aliases=TRANSPORT_ALIASES)
File /opt/stack/oslo.messaging/oslo/messaging/transport.py, line 185, in
get_transport
invoke_kwds=kwargs)
File /opt/stack/stevedore/stevedore/driver.py, line 45, in __init__
verify_requirements=verify_requirements,
File /opt/stack/stevedore/stevedore/named.py, line 55, in __init__
verify_requirements)
File /opt/stack/stevedore/stevedore/extension.py, line 170, in
_load_plugins
self._on_load_failure_callback(self, ep, err)
File /opt/stack/stevedore/stevedore/driver.py, line 50, in
_default_on_load_failure
raise err
File /opt/stack/oslo.messaging/oslo/messaging/_drivers/impl_fake.py, line
48
SyntaxError: Non-ASCII character '\xc2' in file
/opt/stack/oslo.messaging/oslo/messaging/_drivers/impl_fake.py on line 48, but
no encoding declared; see http://www.python.org/peps/pep-0263.html for details
A fix will be done for the oslo error, but we need to investigate why
the gate test does not show any information on the error.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1334798/+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 1335897] [NEW] lockutils blocking issue on Windows due to fcntl
Public bug reported: lockutils is failing on Windows due to an import fcntl (unavailable on Windows). The issue has been introduced with this commit: https://github.com/openstack/oslo- incubator/commit/9b73c19b2e04e6db0dc70046e0ba5e5e22446996 ** Affects: nova Importance: Critical Status: New ** Affects: oslo Importance: Undecided Status: Confirmed ** Tags: hyper-v ** Changed in: oslo Status: New = Confirmed ** Also affects: nova Importance: Undecided Status: New ** Changed in: nova Importance: Undecided = High ** Changed in: nova Importance: High = Critical -- 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/1335897 Title: lockutils blocking issue on Windows due to fcntl Status in OpenStack Compute (Nova): New Status in Oslo - a Library of Common OpenStack Code: Confirmed Bug description: lockutils is failing on Windows due to an import fcntl (unavailable on Windows). The issue has been introduced with this commit: https://github.com/openstack/oslo- incubator/commit/9b73c19b2e04e6db0dc70046e0ba5e5e22446996 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1335897/+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 1335901] [NEW] Allow fine grained control on cells actions
Public bug reported: Operators will often have a need to fine grain control over what actions are allowed on an extension. For cells, potentially destructive (as in when done mistakenly) actions should have better access/policy control. The following actions therefore should get better policy control on cells extensions. -Create -Delete -Update ** Affects: nova Importance: Undecided Assignee: Sulochan Acharya (sulochan-acharya) Status: New ** Changed in: nova Assignee: (unassigned) = Sulochan Acharya (sulochan-acharya) -- 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/1335901 Title: Allow fine grained control on cells actions Status in OpenStack Compute (Nova): New Bug description: Operators will often have a need to fine grain control over what actions are allowed on an extension. For cells, potentially destructive (as in when done mistakenly) actions should have better access/policy control. The following actions therefore should get better policy control on cells extensions. -Create -Delete -Update To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1335901/+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 1335959] [NEW] Neutron dhcp agent variable 'mode' referenced before an assignment
Public bug reported: UnboundLocalError: local variable 'mode' referenced before assignment. This most likely is due to a recent commit: https://bugs.launchpad.net/neutron/+bug/1316190 ** Affects: neutron Importance: Undecided Status: New ** Tags: ipv6 ** Tags added: ipv6 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1335959 Title: Neutron dhcp agent variable 'mode' referenced before an assignment Status in OpenStack Neutron (virtual network service): New Bug description: UnboundLocalError: local variable 'mode' referenced before assignment. This most likely is due to a recent commit: https://bugs.launchpad.net/neutron/+bug/1316190 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335959/+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 1335973] [NEW] VPNaaS Cisco table not created
Public bug reported: When specifying the Cisco CSR VPNaaS driver, a cisco_csr_identifier_map table is used for mapping OpenStack VPN resource IDs to Cisco CSR IDs. This table is used by the service driver, but the table is not registered during init (the service driver is loaded after the plugin has already done configure_db). Need to register during __init__. ** Affects: neutron Importance: Undecided Assignee: Paul Michali (pcm) Status: In Progress ** Tags: vpnaas ** Changed in: neutron Assignee: (unassigned) = Paul Michali (pcm) ** Changed in: neutron Status: New = In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1335973 Title: VPNaaS Cisco table not created Status in OpenStack Neutron (virtual network service): In Progress Bug description: When specifying the Cisco CSR VPNaaS driver, a cisco_csr_identifier_map table is used for mapping OpenStack VPN resource IDs to Cisco CSR IDs. This table is used by the service driver, but the table is not registered during init (the service driver is loaded after the plugin has already done configure_db). Need to register during __init__. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335973/+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 1335984] [NEW] dhcpv6 address advertised but vm not getting it
Public bug reported: Launching a VM on a network with both ipv4 and ipv6. After the VM is booted successfully, login to it. Issuing ifconfig -a, no IPv6 address is configured. However, dnsmasq is running properly on the host and address for the VM has been advertised, which can be found from either the syslog msg or packet dump. Flushing ip6tables by 'ip6tables -F' and rebooting the VM, ipv6 address can be seen configured in the vm. ** Affects: neutron Importance: Undecided Status: New ** Tags: ipv6 ** Tags added: ipv6 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1335984 Title: dhcpv6 address advertised but vm not getting it Status in OpenStack Neutron (virtual network service): New Bug description: Launching a VM on a network with both ipv4 and ipv6. After the VM is booted successfully, login to it. Issuing ifconfig -a, no IPv6 address is configured. However, dnsmasq is running properly on the host and address for the VM has been advertised, which can be found from either the syslog msg or packet dump. Flushing ip6tables by 'ip6tables -F' and rebooting the VM, ipv6 address can be seen configured in the vm. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1335984/+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 1335999] [NEW] live migration choosing wrong host names
Public bug reported: Horizon's admin interface recently gained a feature to trigger a live migration from the UI. It requires a destination host to be specified (which is wrong, as the destination host is optional in the API), and it allows to preselect from a list of given names. However, the list that is chosen is coming from os-hypervisor-list. These host names might not match os-hosts, which is the one that the nova scheduler expects. Consequently if hypervisor names do not match the host names, the live migration from the UI fails. ** 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/1335999 Title: live migration choosing wrong host names Status in OpenStack Dashboard (Horizon): New Bug description: Horizon's admin interface recently gained a feature to trigger a live migration from the UI. It requires a destination host to be specified (which is wrong, as the destination host is optional in the API), and it allows to preselect from a list of given names. However, the list that is chosen is coming from os-hypervisor-list. These host names might not match os-hosts, which is the one that the nova scheduler expects. Consequently if hypervisor names do not match the host names, the live migration from the UI fails. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1335999/+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 1336028] [NEW] [data processing] Add start/end times for job execution
Public bug reported: This is a bug that needs to be ported from the sahara-dashboard repo to the merged horizon [+ data processing] codebase. Priority *wishlist* On the data processing page for job execution details, start/end time is not shown for each job execution. Given that start and end time are important details of a job execution. It should be shown on the page. See also: https://review.openstack.org/#/c/99804/ ** Affects: horizon Importance: Undecided Assignee: Chad Roberts (croberts) Status: New ** Changed in: horizon Assignee: (unassigned) = Chad Roberts (croberts) -- 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/1336028 Title: [data processing] Add start/end times for job execution Status in OpenStack Dashboard (Horizon): New Bug description: This is a bug that needs to be ported from the sahara-dashboard repo to the merged horizon [+ data processing] codebase. Priority *wishlist* On the data processing page for job execution details, start/end time is not shown for each job execution. Given that start and end time are important details of a job execution. It should be shown on the page. See also: https://review.openstack.org/#/c/99804/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1336028/+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 1315922] Re: Updation of IPSEC Policy after the site creation fails
Closing as invalid per Paul's comment
** Changed in: neutron
Status: New = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1315922
Title:
Updation of IPSEC Policy after the site creation fails
Status in OpenStack Neutron (virtual network service):
Invalid
Bug description:
Create a site to site connection .
Now try to update any parameter of the IPSECPolicy .
Error will be thrown:
{u'NeutronError': {u'message': u'IPSECPolicy $Id still in use', u'type':
u'IKEPolicyInUse', u'detail': u''}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1315922/+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 1336048] [NEW] hosts added to the wrong host aggregate in DB sync
Public bug reported: This issue was found in stable/havana when we upgraded nova DB from folsom to havana. When there are multiple host aggregates associated with an availability zone, the migration logic add all hosts belong to the availability zone to the first host aggregate. The code at line 41 of /nova/nova/db/sqlalchemy/migrate_repo/versions/147_no_service_zones.py ** Affects: nova Importance: Undecided Assignee: wei tian (weitian) Status: New ** Changed in: nova Assignee: (unassigned) = wei tian (weitian) -- 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/1336048 Title: hosts added to the wrong host aggregate in DB sync Status in OpenStack Compute (Nova): New Bug description: This issue was found in stable/havana when we upgraded nova DB from folsom to havana. When there are multiple host aggregates associated with an availability zone, the migration logic add all hosts belong to the availability zone to the first host aggregate. The code at line 41 of /nova/nova/db/sqlalchemy/migrate_repo/versions/147_no_service_zones.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1336048/+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 1336071] [NEW] add IMAGE related settings to documentation
Public bug reported: There are some new settings being used in patches that have no documentation anywhere. = would be helpful to add to http://docs.openstack.org/developer/horizon/topics/settings.html IMAGE_CUSTOM_PROPERTY_TITLES https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L204 HORIZON_IMAGES_ALLOW_UPLOAD https://github.com/Mirantis/openstack-horizon/blob/master/doc/source/topics/deployment.rst == Defined as: Deployments are able to disable the ability to upload images through Horizon by setting HORIZON_IMAGES_ALLOW_UPLOAD to False in your local_settings.py file. ** 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/1336071 Title: add IMAGE related settings to documentation Status in OpenStack Dashboard (Horizon): New Bug description: There are some new settings being used in patches that have no documentation anywhere. = would be helpful to add to http://docs.openstack.org/developer/horizon/topics/settings.html IMAGE_CUSTOM_PROPERTY_TITLES https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L204 HORIZON_IMAGES_ALLOW_UPLOAD https://github.com/Mirantis/openstack-horizon/blob/master/doc/source/topics/deployment.rst == Defined as: Deployments are able to disable the ability to upload images through Horizon by setting HORIZON_IMAGES_ALLOW_UPLOAD to False in your local_settings.py file. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1336071/+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 1336077] [NEW] file permission wrong on /etc/nova/release
Public bug reported: On Service start up nova-compute.log reports: 2014-06-30 14:47:49.705 13222 ERROR nova.version [-] Failed to load /etc/nova/release: No section: 'Nova' ls -l on /etc/nova shows other configuration files are owned and readable by nova while release is only readable by root -rw-r- 1 root nova 3120 Jun 24 13:01 api-paste.ini -rw-r- 1 root nova 98937 Jun 30 14:33 nova.conf -rw-r- 1 root nova 16793 Jun 24 13:01 policy.json -rw--- 1 root root 112 Jun 27 04:37 release Nova Version : 2014.1.2-2014.1.2.dev7.gf92af88 Workaround: chown -R nova:nova /etc/nova/release chmod 640 /etc/nova/release Prior to openstack-nova-compute service start. ** 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/1336077 Title: file permission wrong on /etc/nova/release Status in OpenStack Compute (Nova): New Bug description: On Service start up nova-compute.log reports: 2014-06-30 14:47:49.705 13222 ERROR nova.version [-] Failed to load /etc/nova/release: No section: 'Nova' ls -l on /etc/nova shows other configuration files are owned and readable by nova while release is only readable by root -rw-r- 1 root nova 3120 Jun 24 13:01 api-paste.ini -rw-r- 1 root nova 98937 Jun 30 14:33 nova.conf -rw-r- 1 root nova 16793 Jun 24 13:01 policy.json -rw--- 1 root root 112 Jun 27 04:37 release Nova Version : 2014.1.2-2014.1.2.dev7.gf92af88 Workaround: chown -R nova:nova /etc/nova/release chmod 640 /etc/nova/release Prior to openstack-nova-compute service start. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1336077/+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 1336080] [NEW] deleting instance doesn't update scheduler immediately
Public bug reported: Previously deleting an instance would update the scheduler resources fairly quickly. There is now a delay when deleting an instance until the scheduler makes the resources available again. This appears to be due to the fact that the delete code path used to call resource tracker to update the compute_node record but this no longer happens. ** Affects: nova Importance: High Status: Triaged ** Tags: havana-backport-potential icehouse-backport-potential -- 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/1336080 Title: deleting instance doesn't update scheduler immediately Status in OpenStack Compute (Nova): Triaged Bug description: Previously deleting an instance would update the scheduler resources fairly quickly. There is now a delay when deleting an instance until the scheduler makes the resources available again. This appears to be due to the fact that the delete code path used to call resource tracker to update the compute_node record but this no longer happens. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1336080/+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 1336088] [NEW] Disabling a domain does not disable the previous issued tokens in that domain
Public bug reported: Tokens are still valid although the domain has already been disable. Steps to reproduce. 1. create domain domainA 2. create user userA under domain domainA 3. authenticate to get a token tokenA for user userA 4. disable domainA 6. validate tokenA and it is still a valid token which is supposed to be invalid. Looks like the fix would be when disabling the domain, all the un- expired tokens for this domain should also be disable. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1336088 Title: Disabling a domain does not disable the previous issued tokens in that domain Status in OpenStack Identity (Keystone): New Bug description: Tokens are still valid although the domain has already been disable. Steps to reproduce. 1. create domain domainA 2. create user userA under domain domainA 3. authenticate to get a token tokenA for user userA 4. disable domainA 6. validate tokenA and it is still a valid token which is supposed to be invalid. Looks like the fix would be when disabling the domain, all the un- expired tokens for this domain should also be disable. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1336088/+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 1335366] Re: swift Object Details should clarify that it is UTC time
** Changed in: horizon Status: New = 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/1335366 Title: swift Object Details should clarify that it is UTC time Status in OpenStack Dashboard (Horizon): Invalid Bug description: If you look at the Object Details modal, It is currently showing UTC time. We should clarify this by appending UTC Related: https://bugs.launchpad.net/horizon/+bug/1326595 = I agree with the comments mentioned there. Would it be useful to have a *global* local time/UTC toggle so that user can decide what he/she wants to see? To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1335366/+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 1336094] [NEW] fake_network_cache_model doesn't support ipv6
Public bug reported: Currently, the functions in fake_network_cache_model all default to building a fake ipv4 network, and so the easiest way to test against a fake ipv6 network is to manually create ipv6 components (subnets, routes, ips) and plug them into the default fake VIF. This makes testing ipv6 functionality rather error-prone and laborious. There should be some option in the fake_network_cache_model functions that creates ipv6 models instead of ipv4 models. ** 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/1336094 Title: fake_network_cache_model doesn't support ipv6 Status in OpenStack Compute (Nova): New Bug description: Currently, the functions in fake_network_cache_model all default to building a fake ipv4 network, and so the easiest way to test against a fake ipv6 network is to manually create ipv6 components (subnets, routes, ips) and plug them into the default fake VIF. This makes testing ipv6 functionality rather error-prone and laborious. There should be some option in the fake_network_cache_model functions that creates ipv6 models instead of ipv4 models. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1336094/+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 1336120] [NEW] specified valid floating IP address doen't work when creating a floating IP
Public bug reported:
In the neutron API doument http://developer.openstack.org/api-ref-
networking-v2.html, floating_ip_address could be set in the
POST/v2.0/{tenant_id}/floatingips request. the floating_ip_address is
not handled in the source code except checking to see if the
floating_ip_address is in the external network or not.
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py
the valid specified floating_ip_address is not used during creating port
in the external network:
external_port = self._core_plugin.create_port(context.elevated(), {
'port':
{'tenant_id': '', # tenant intentionally not set
'network_id': f_net_id,
'mac_address': attributes.ATTR_NOT_SPECIFIED,
'fixed_ips': attributes.ATTR_NOT_SPECIFIED,
if the floating_ip_address is valid ip address, it should be used here
to create the port in the external network
'admin_state_up': True,
'device_id': fip_id,
'device_owner': DEVICE_OWNER_FLOATINGIP,
'name': ''}})
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1336120
Title:
specified valid floating IP address doen't work when creating a
floating IP
Status in OpenStack Neutron (virtual network service):
New
Bug description:
In the neutron API doument http://developer.openstack.org/api-ref-
networking-v2.html, floating_ip_address could be set in the
POST/v2.0/{tenant_id}/floatingips request. the floating_ip_address
is not handled in the source code except checking to see if the
floating_ip_address is in the external network or not.
https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py
the valid specified floating_ip_address is not used during creating
port in the external network:
external_port = self._core_plugin.create_port(context.elevated(), {
'port':
{'tenant_id': '', # tenant intentionally not set
'network_id': f_net_id,
'mac_address': attributes.ATTR_NOT_SPECIFIED,
'fixed_ips': attributes.ATTR_NOT_SPECIFIED,
if the floating_ip_address is valid ip address, it should be used
here to create the port in the external network
'admin_state_up': True,
'device_id': fip_id,
'device_owner': DEVICE_OWNER_FLOATINGIP,
'name': ''}})
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1336120/+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 1336127] [NEW] the boot volume will be deleted when creating a virtual machine fails with the parameter delete_on_termination being set true
Public bug reported: when specifying a volume to create a virtual machine, if the virtual machine fails to be created for the first time with the parameter delete_on_termination being set “true”, the specified volume will be deleted, which causes that the rescheduling fails. for example: 1. upload a image | 62aa6627-0a07-4ab4-a99f-2d99110db03e | cirros-0.3.2-x86_64-uec | ACTIVE 2.create a boot volume by the above image cinder create --image-id 62aa6627-0a07-4ab4-a99f-2d99110db03e --availability-zone nova 1 | b821313a-9edb-474f-abb0-585a211589a6 | available | None | 1 | None | true | | 3. create a virtual machine nova boot --flavor m1.tiny --nic net-id=28216e1d-f1c2-463b-8ae2-330a87e800d2 tralon_disk1 --block-device-mapping vda=b821313a-9edb-474f-abb0-585a211589a6::1:1 ERROR (BadRequest): Block Device Mapping is Invalid: failed to get volume b821313a-9edb-474f-abb0-585a211589a6. (HTTP 400) (Request-ID: req-486f7ab5-dc08-404e-8d4c-ac570d4f4aa1) 4. use the cinder list to find that the volume b821313a-9edb-474f-abb0-585a211589a6 has been deleted +++--+--+-+--+-+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +++--+--+-+--+-+ +++--+--+-+--+-+ ** Affects: nova Importance: Undecided Assignee: zhangtralon (zhangchunlong1) Status: New ** Changed in: nova Assignee: (unassigned) = zhangtralon (zhangchunlong1) -- 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/1336127 Title: the boot volume will be deleted when creating a virtual machine fails with the parameter delete_on_termination being set true Status in OpenStack Compute (Nova): New Bug description: when specifying a volume to create a virtual machine, if the virtual machine fails to be created for the first time with the parameter delete_on_termination being set “true”, the specified volume will be deleted, which causes that the rescheduling fails. for example: 1. upload a image | 62aa6627-0a07-4ab4-a99f-2d99110db03e | cirros-0.3.2-x86_64-uec | ACTIVE 2.create a boot volume by the above image cinder create --image-id 62aa6627-0a07-4ab4-a99f-2d99110db03e --availability-zone nova 1 | b821313a-9edb-474f-abb0-585a211589a6 | available | None | 1 | None | true | | 3. create a virtual machine nova boot --flavor m1.tiny --nic net-id=28216e1d-f1c2-463b-8ae2-330a87e800d2 tralon_disk1 --block-device-mapping vda=b821313a-9edb-474f-abb0-585a211589a6::1:1 ERROR (BadRequest): Block Device Mapping is Invalid: failed to get volume b821313a-9edb-474f-abb0-585a211589a6. (HTTP 400) (Request-ID: req-486f7ab5-dc08-404e-8d4c-ac570d4f4aa1) 4. use the cinder list to find that the volume b821313a-9edb-474f-abb0-585a211589a6 has been deleted +++--+--+-+--+-+ | ID | Status | Name | Size | Volume Type | Bootable | Attached to | +++--+--+-+--+-+ +++--+--+-+--+-+ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1336127/+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 1335688] Re: Inconsistent capitalization on Networks tab under Launch Instance
we have already fixed the inconsistent capitalization in j1. see: https://bugs.launchpad.net/horizon/+bug/1325684 ** Changed in: horizon Status: In Progress = 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/1335688 Title: Inconsistent capitalization on Networks tab under Launch Instance Status in OpenStack Dashboard (Horizon): Invalid Bug description: Under Launch Instance - Networks, the two options are Selected Networks and Available networks. Capitalization of networks should probably be consistent. Obviously minor and doesn't affect usability. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1335688/+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
