[Yahoo-eng-team] [Bug 1603979] [NEW] context tests failed because missing parameter "is_admin_project"
Public bug reported:
Description
===
The following 3 tests failed:
1.
nova.tests.unit.test_context.ContextTestCase.test_convert_from_dict_then_to_dict
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/test_context.py", line 230, in
test_convert_from_dict_then_to_dict
self.assertEqual(values, values2)
File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {
..
'is_admin': True,
..}
actual= {
..
'is_admin': True,
'is_admin_project': True,
..}
2. nova.tests.unit.test_context.ContextTestCase.test_convert_from_rc_to_dict
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/test_context.py", line 203, in
test_convert_from_rc_to_dict
self.assertEqual(expected_values, values2)
File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {
..
'is_admin': True,
..}
actual= {
..
'is_admin': True,
'is_admin_project': True,
..}
3. nova.tests.unit.test_context.ContextTestCase.test_to_dict_from_dict_no_log
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/test_context.py", line 144, in
test_to_dict_from_dict_no_log
self.assertEqual(0, len(warns), warns)
File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: 0 != 1: ["Arguments dropped when
creating context: {'is_admin_project': True}"]
Steps to reproduce
==
Just run the context tests:
tox -e py27 test_context
This is because we missed to pass "is_admin_project" parameter to
__init__() of oslo.context.ResourceContext when initializing a nova
ResourceContext object.
In nova/context.py
@enginefacade.transaction_context_provider
class RequestContext(context.RequestContext):
"""Security context and request information.
Represents the user taking a given action within the system.
"""
def __init__(self, user_id=None, project_id=None,
is_admin=None, read_deleted="no",
roles=None, remote_address=None, timestamp=None,
request_id=None, auth_token=None, overwrite=True,
quota_class=None, user_name=None, project_name=None,
service_catalog=None, instance_lock_checked=False,
user_auth_plugin=None, **kwargs):
..
super(RequestContext, self).__init__(
..
is_admin=is_admin,
..)
But in oslo_context/context.py,
class RequestContext(object):
..
def __init__(..
is_admin=False,
..
is_admin_project=True):
** Affects: nova
Importance: Undecided
Assignee: Tang Chen (tangchen)
Status: New
** Changed in: nova
Assignee: (unassigned) => Tang Chen (tangchen)
** Description changed:
Description
===
The following 3 tests failed:
1.
nova.tests.unit.test_context.ContextTestCase.test_convert_from_dict_then_to_dict
Captured traceback:
~~~
- Traceback (most recent call last):
- File "nova/tests/unit/test_context.py", line 230, in
test_convert_from_dict_then_to_dict
- self.assertEqual(values, values2)
- File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 411, in assertEqual
- self.assertThat(observed, matcher, message)
- File
"/opt/stack/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py",
line 498, in assertThat
- raise mismatch_error
- testtools.matchers._impl.MismatchError: !=:
- reference = {
- ..
- 'is_admin': True,
- ..}
- actual= {
- ..
- 'is_admin': True,
- 'is_admin_project': Tru
[Yahoo-eng-team] [Bug 1556379] Re: dict.keys() compatibility in Python 2 and 3
** Changed in: neutron Status: In Progress => 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/1556379 Title: dict.keys() compatibility in Python 2 and 3 Status in neutron: Opinion Bug description: In Python 2, dict.keys() will return a list. But in Python 3, it will return an iterable. So we need to fix all the assumptions that assuming dict.keys() is a list. They may be: 1. A function's return value which is expected to be a list 2. Anywhere dict.keys() is used as a list We don't need to fix: 1. for xxx in dict.keys: 2. if dict.keys(): 3. dict.keys() as a parameter of set.difference(), filter(), and so on. 4. Anywhere dict.keys() has been transformed to a set, or any other iterable. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1556379/+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 1556379] [NEW] dict.keys() compatibility in Python 2 and 3
Public bug reported: In Python 2, dict.keys() will return a list. But in Python 3, it will return an iterable. So we need to fix all the assumptions that assuming dict.keys() is a list. They may be: 1. A function's return value which is expected to be a list 2. Anywhere dict.keys() is used as a list We don't need to fix: 1. for xxx in dict.keys: 2. if dict.keys(): 3. dict.keys() as a parameter of set.difference(), filter(), and so on. 4. Anywhere dict.keys() has been transformed to a set, or any other iterable. ** Affects: neutron Importance: Undecided Assignee: Tang Chen (tangchen) Status: New ** Changed in: neutron Assignee: (unassigned) => Tang Chen (tangchen) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1556379 Title: dict.keys() compatibility in Python 2 and 3 Status in neutron: New Bug description: In Python 2, dict.keys() will return a list. But in Python 3, it will return an iterable. So we need to fix all the assumptions that assuming dict.keys() is a list. They may be: 1. A function's return value which is expected to be a list 2. Anywhere dict.keys() is used as a list We don't need to fix: 1. for xxx in dict.keys: 2. if dict.keys(): 3. dict.keys() as a parameter of set.difference(), filter(), and so on. 4. Anywhere dict.keys() has been transformed to a set, or any other iterable. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1556379/+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 1544522] Re: Don't use Mock.called_once_with that does not exist
** Also affects: python-openstackclient Importance: Undecided Status: New ** Changed in: python-openstackclient Assignee: (unassigned) => Tang Chen (tangchen) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1544522 Title: Don't use Mock.called_once_with that does not exist Status in Cinder: Fix Released Status in neutron: In Progress Status in octavia: In Progress Status in python-designateclient: In Progress Status in python-openstackclient: New Status in Rally: Fix Released Status in Sahara: Fix Released Status in Trove: In Progress Bug description: class mock.Mock does not exist method "called_once_with", it just exists method "assert_called_once_with". Currently there are still some places where we use called_once_with method, we should correct it. NOTE: called_once_with() does nothing because it's a mock object. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1544522/+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 1521491] [NEW] OSC doesn't support list server by searching flavor and image name.
Public bug reported: Nova API only supports list servers searching by flavor and image ID. So OSC only supports this. But the doc of the command help doesn't tell the user that they can only specify the ID. ** Affects: nova Importance: Undecided Status: 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/1521491 Title: OSC doesn't support list server by searching flavor and image name. Status in OpenStack Compute (nova): Invalid Bug description: Nova API only supports list servers searching by flavor and image ID. So OSC only supports this. But the doc of the command help doesn't tell the user that they can only specify the ID. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1521491/+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 1521491] Re: OSC doesn't support list server by searching flavor and image name.
Well, sorry. Wrong place... Please ignore this. It should be sent to OSC. :) ** Changed in: nova Status: New => Confirmed ** 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/1521491 Title: OSC doesn't support list server by searching flavor and image name. Status in OpenStack Compute (nova): Invalid Bug description: Nova API only supports list servers searching by flavor and image ID. So OSC only supports this. But the doc of the command help doesn't tell the user that they can only specify the ID. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1521491/+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 1465176] Re: Host maintenance mode unavailable in Libvirt.
Has posted a BP for this functionality. Please refer to: https://blueprints.launchpad.net/nova/+spec/host- maintenance-mode ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1465176 Title: Host maintenance mode unavailable in Libvirt. Status in OpenStack Compute (nova): Invalid Bug description: When executing the following command on a KVM box with the latest version of Nova: nova host-update XXX --maintenance enable it returns the following error: ERROR (HTTPNotImplemented): Virt driver does not implement host maintenance mode. The libvirt driver has not implemented host maintenance mode. In a workload cloud, nova compute nodes need to be maintained (such as system or hardware upgrade) from time to time. But the service or VMs running on the nodes cannot be paused to minimize the effect to users. So we need a functionality to put a compute node to maintenance mode so that no VM will be scheduled to run on this node and no new instance will be create on this node. This topic has been discussed since 2013 here (https://blueprints.launchpad.net/nova/+spec/host-maintenance). In the previous discussion, Oshrit Feder explained why the current implementation is not enough, and how to improve it. And after some discussions, the basic idea came to (IIUC): 1.CLI (nova host-update –maintenance enable/disable) or API (set_host_maintenance) should not target the request directly to the compute node to be put in maintenance itself. Instead, nova conductor is responsible for the orchestration. 2.When the operation starts, nova disables the target host (disable nova-compute) so that no new instance will be created on this host. 3.Live migrate all instances on this host. The nova conductor delivers the request to nova scheduler, and the scheduler picks suitable destination hosts for the migration. 4.Rebuild all not-running instances on destination hosts if necessary. 5.Set the host mode to maintenance. And according to the source code, I think step1 has been implemented by merging live-migrate and migrate operations, and move the orchestration to nova conductor, providing all basic functionalities for the other steps. So to enable KVM host maintenance mode, we need to finish step 2,3,4,5 in libvirt driver. The basic implementation will be like this: 1.When user calls “nova host-update XXX maintenance --enable”, disable nova-compute service on host XXX. 2.The command request should be handled in nova/virt/libvirt/host.py. So implement host_maintenance_mode() in host.py, and call it through libvirt driver. 3.Deliver the request to nova conductor, and the conductor is able to list up all the instances on the host. 4.List up all running instances, find the Instance objects of them, and live migrate them. 5.Rebuild all not-running instances on destination hosts. 6.When all the above have been done successfully, set the host mode to maintenance mode. 7.Reenable nova-compute service on error. The first version of patch will come soon. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1465176/+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
