[Yahoo-eng-team] [Bug 1746747] [NEW] Clean up UUID usage in tests
Public bug reported: Bug #1606647 [0] was created because there were many places in our tests, where the test authors entered values for UUID fields that were not UUID-like, such as 'fake-id'. Since oslo.versionedobjects now enforces UUID validity in any field declared to be a UUIDField, we had to update these tests to use proper UUIDs. During that process, it was clear that there were many other places where UUIDs were either invalid, or hard-coded to values such as '----', which, while valid, is not a best practice for testing. Instead, tests should use nova.tests.uuidsentinel instead, which will create a named unique UUID for each UUID required for the tests. As a start, a list of many of these cases is in the reviews for the bug fix patches for #1606647: https://review.openstack.org/#/c/531479/ https://review.openstack.org/#/c/539254/ As this bug is being filed after the end of Feature Freeze for Queens, and is not critical for Queens, it should be corrected in Rocky at the earliest. [0] https://launchpad.net/bugs/1606647 ** Affects: nova Importance: Low Status: Confirmed ** Tags: low-hanging-fruit -- 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/1746747 Title: Clean up UUID usage in tests Status in OpenStack Compute (nova): Confirmed Bug description: Bug #1606647 [0] was created because there were many places in our tests, where the test authors entered values for UUID fields that were not UUID-like, such as 'fake-id'. Since oslo.versionedobjects now enforces UUID validity in any field declared to be a UUIDField, we had to update these tests to use proper UUIDs. During that process, it was clear that there were many other places where UUIDs were either invalid, or hard-coded to values such as '----', which, while valid, is not a best practice for testing. Instead, tests should use nova.tests.uuidsentinel instead, which will create a named unique UUID for each UUID required for the tests. As a start, a list of many of these cases is in the reviews for the bug fix patches for #1606647: https://review.openstack.org/#/c/531479/ https://review.openstack.org/#/c/539254/ As this bug is being filed after the end of Feature Freeze for Queens, and is not critical for Queens, it should be corrected in Rocky at the earliest. [0] https://launchpad.net/bugs/1606647 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1746747/+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 1742760] [NEW] InstanceMapping uses invalid UUID
Public bug reported:
The InstanceMapping class contains the 'instance_uuid' field. When
mapping instances, they can be done in batches, and in order to do this,
a marker containing the UUID of the last mapped instance is created in
the table. However, since the instance_uuid column has a unique
constraint, the value is munged by replacing the dashes ('-') with
spaces.
The oslo_versionedobjects module was recently updated to enforce the
validity of all values in UUID fields. As a transition, it only emits
warnings, but in the future, it will raise ValueErrors. Tests of the
mapping marker behavior show the warning:
oslo_versionedobjects/fields.py:348: FutureWarning: 655662b2 6573 42f9
abbf de92533e20a8 is an invalid UUID. Using UUIDFields with invalid
UUIDs is no longer supported, and will be removed in a future release.
Please update your code to input valid UUIDs or accept ValueErrors for
invalid UUIDs.
We need to update the InstanceMapping marker code to avoid creating
invalid UUIDs.
** Affects: nova
Importance: Medium
Assignee: Ed Leafe (ed-leafe)
Status: New
** Tags: instancemapping uuid
--
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/1742760
Title:
InstanceMapping uses invalid UUID
Status in OpenStack Compute (nova):
New
Bug description:
The InstanceMapping class contains the 'instance_uuid' field. When
mapping instances, they can be done in batches, and in order to do
this, a marker containing the UUID of the last mapped instance is
created in the table. However, since the instance_uuid column has a
unique constraint, the value is munged by replacing the dashes ('-')
with spaces.
The oslo_versionedobjects module was recently updated to enforce the
validity of all values in UUID fields. As a transition, it only emits
warnings, but in the future, it will raise ValueErrors. Tests of the
mapping marker behavior show the warning:
oslo_versionedobjects/fields.py:348: FutureWarning: 655662b2 6573 42f9
abbf de92533e20a8 is an invalid UUID. Using UUIDFields with invalid
UUIDs is no longer supported, and will be removed in a future release.
Please update your code to input valid UUIDs or accept ValueErrors for
invalid UUIDs.
We need to update the InstanceMapping marker code to avoid creating
invalid UUIDs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1742760/+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 1741125] [NEW] Instance resize always fails when rescheduling
Public bug reported:
When resizing an instance, the migration task calls
"replace_allocation_with_migration()', which checks to verify that the instance
has allocations against the source compute node [0]. It then replaces the
instance's allocation with the migration, using it's UUID as the consumer
instead of the instance's. However, if the first attempt at migrating fails and
the resize is rescheduled, when "replace_allocation_with_migration()" is called
again, the allocations now have the migration UUID as the consumer, and so the
check that the instance has allocations on the source compute node will fail,
and the migration is put in an ERROR state.
[0]
https://github.com/openstack/nova/blob/f95f165b49fbc0efe29450b0e858a3ccadecedea/nova/conductor/tasks/migrate.py#L47-L48
** Affects: nova
Importance: High
Assignee: Ed Leafe (ed-leafe)
Status: Confirmed
** Tags: migration placement queens-rc-potential resize
--
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/1741125
Title:
Instance resize always fails when rescheduling
Status in OpenStack Compute (nova):
Confirmed
Bug description:
When resizing an instance, the migration task calls
"replace_allocation_with_migration()', which checks to verify that the instance
has allocations against the source compute node [0]. It then replaces the
instance's allocation with the migration, using it's UUID as the consumer
instead of the instance's. However, if the first attempt at migrating fails and
the resize is rescheduled, when "replace_allocation_with_migration()" is called
again, the allocations now have the migration UUID as the consumer, and so the
check that the instance has allocations on the source compute node will fail,
and the migration is put in an ERROR state.
[0]
https://github.com/openstack/nova/blob/f95f165b49fbc0efe29450b0e858a3ccadecedea/nova/conductor/tasks/migrate.py#L47-L48
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1741125/+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 1707021] [NEW] Ironic Flavor Migration can miss instances
Public bug reported: The recently merged patch (https://review.openstack.org/484949) runs the migration in the driver's init_host() method. It has since been pointed out that if there are multiple computes handling ironic, some instances can get skipped if the hash ring is refreshed and an unmigrated instance is placed on a compute whose init_host has already run. While a rare thing, this should be corrected to ensure that all instances have their flavors migrated in Pike. ** Affects: nova Importance: Medium Assignee: Ed Leafe (ed-leafe) Status: In Progress ** Tags: ironic note-to-self -- 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/1707021 Title: Ironic Flavor Migration can miss instances Status in OpenStack Compute (nova): In Progress Bug description: The recently merged patch (https://review.openstack.org/484949) runs the migration in the driver's init_host() method. It has since been pointed out that if there are multiple computes handling ironic, some instances can get skipped if the hash ring is refreshed and an unmigrated instance is placed on a compute whose init_host has already run. While a rare thing, this should be corrected to ensure that all instances have their flavors migrated in Pike. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1707021/+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 1704231] [NEW] Ironic driver calling _get_node() with nodename
Public bug reported: The _get_node() method in the Ironic virt driver has the following signature and docstring: def _get_node(self, node_uuid): """Get a node by its UUID.""" However, there are 4 places in the code where this method is called that passes the string for the nodename instead: node_is_available() _node_from_cache() plug_vifs() unplug_vifs() I don't know how any of these are working, but I guess the periodic update that correctly calls _get_node() with a UUID keeps the node cache current. ** Affects: nova Importance: Low Status: New ** Tags: ironic virt -- 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/1704231 Title: Ironic driver calling _get_node() with nodename Status in OpenStack Compute (nova): New Bug description: The _get_node() method in the Ironic virt driver has the following signature and docstring: def _get_node(self, node_uuid): """Get a node by its UUID.""" However, there are 4 places in the code where this method is called that passes the string for the nodename instead: node_is_available() _node_from_cache() plug_vifs() unplug_vifs() I don't know how any of these are working, but I guess the periodic update that correctly calls _get_node() with a UUID keeps the node cache current. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1704231/+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 1701035] [NEW] Standard traits are not always available in tests
Public bug reported: Several tests use the Database fixture, which cleans up the DB tables after the tests are run. Some functional tests for traits, though, were failing because standard traits were not found in the DB. Traits have a flag so that standard traits from the os_traits library are only loaded once at startup. So the problem is that one test would use the fixture, loading the standard traits, and then clean up by removing the db entries. The next test would use the fixture, but since the flag had been set by the first test, the standard traits were not re-loaded, causing failures. ** Affects: nova Importance: Medium Assignee: Ed Leafe (ed-leafe) Status: In Progress ** Tags: placement traits -- 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/1701035 Title: Standard traits are not always available in tests Status in OpenStack Compute (nova): In Progress Bug description: Several tests use the Database fixture, which cleans up the DB tables after the tests are run. Some functional tests for traits, though, were failing because standard traits were not found in the DB. Traits have a flag so that standard traits from the os_traits library are only loaded once at startup. So the problem is that one test would use the fixture, loading the standard traits, and then clean up by removing the db entries. The next test would use the fixture, but since the flag had been set by the first test, the standard traits were not re-loaded, causing failures. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1701035/+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 1689339] [NEW] Filter Scheduler doc claims filters can be specified in the request
Public bug reported: On https://docs.openstack.org/developer/nova/filter_scheduler.html, it says that with the configuration set to: --filter_scheduler.enabled_filters=RamFilter,ComputeFilter,MyFilter that the following is true: "With these settings, nova will use the FilterScheduler for the scheduler driver. The standard nova filters and MyFilter are available to the FilterScheduler. The RamFilter, ComputeFilter, and MyFilter are used by default when no filters are specified in the request." There is no ability to specify filters in a request. The text of this page should be changed to reflect that. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: In Progress ** Tags: doc scheduler -- 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/1689339 Title: Filter Scheduler doc claims filters can be specified in the request Status in OpenStack Compute (nova): In Progress Bug description: On https://docs.openstack.org/developer/nova/filter_scheduler.html, it says that with the configuration set to: --filter_scheduler.enabled_filters=RamFilter,ComputeFilter,MyFilter that the following is true: "With these settings, nova will use the FilterScheduler for the scheduler driver. The standard nova filters and MyFilter are available to the FilterScheduler. The RamFilter, ComputeFilter, and MyFilter are used by default when no filters are specified in the request." There is no ability to specify filters in a request. The text of this page should be changed to reflect that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1689339/+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 1655761] [NEW] Resource Provider generation update missing
Public bug reported: Most of the methods that increase the generation for a resource provider also update the value of `generation` in the object that calls it, but there is one place where it was missing: the _set_allocations() method of the AllocationList class. This resulted in some ResourceProvider references having stale values for `generation`, which would cause a ConcurrentUpdateDetected exception to be raised. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: In Progress ** Tags: placement -- 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/1655761 Title: Resource Provider generation update missing Status in OpenStack Compute (nova): In Progress Bug description: Most of the methods that increase the generation for a resource provider also update the value of `generation` in the object that calls it, but there is one place where it was missing: the _set_allocations() method of the AllocationList class. This resulted in some ResourceProvider references having stale values for `generation`, which would cause a ConcurrentUpdateDetected exception to be raised. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1655761/+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 1648197] [NEW] ResourceProvider column 'can_host' is too Nova-specific
Public bug reported: There is a column in the ResourceProvider table named 'can_host'. It is used to distinguish compute nodes (can_host=1) from shared storage providers (can_host=0) for queries that need to distinguish those different types of providers. However, the name is very Nova-specific, and when the Placement engine is extended to support a variety of resource allocation requirements, it will probably cause confusion. After a discussion on IRC, we decided to change the name to "shared", and reverse any logic using can_host, since can_host=1 will now be shared=0, and vice-versa. ** Affects: nova Importance: Low Assignee: Ed Leafe (ed-leafe) Status: Triaged ** Tags: db placement -- 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/1648197 Title: ResourceProvider column 'can_host' is too Nova-specific Status in OpenStack Compute (nova): Triaged Bug description: There is a column in the ResourceProvider table named 'can_host'. It is used to distinguish compute nodes (can_host=1) from shared storage providers (can_host=0) for queries that need to distinguish those different types of providers. However, the name is very Nova-specific, and when the Placement engine is extended to support a variety of resource allocation requirements, it will probably cause confusion. After a discussion on IRC, we decided to change the name to "shared", and reverse any logic using can_host, since can_host=1 will now be shared=0, and vice-versa. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1648197/+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 1632856] [NEW] Incorrect datatype for Python 3 in api-samples functional test
Public bug reported:
The nova/tests/functional/api_sample_tests/test_servers.py contains the
ServersSampleBase class, and in its class definition creates user data
by base64 encoding a string. However, this will not work in Python 3, as
the base64.b64encode() method requires bytes, not a string.
This can be seen by simply running 'tox -e functional' under Python 3,
which then emits a series of errors, most of which look like:
Failed to import test module:
nova.tests.functional.api_sample_tests.test_servers
Traceback (most recent call last):
File
"/home/ed/projects/nova/.tox/functional/lib/python3.4/site-packages/unittest2/loader.py",
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
"/home/ed/projects/nova/.tox/functional/lib/python3.4/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name
__import__(name)
File
"/home/ed/projects/nova/nova/tests/functional/api_sample_tests/test_servers.py",
line 24, in
class ServersSampleBase(api_sample_base.ApiSampleTestBaseV21):
File
"/home/ed/projects/nova/nova/tests/functional/api_sample_tests/test_servers.py",
line 29, in ServersSampleBase
user_data = base64.b64encode(user_data_contents)
File "/home/ed/projects/nova/.tox/functional/lib/python3.4/base64.py", line
62, in b64encode
encoded = binascii.b2a_base64(s)[:-1]
TypeError: 'str' does not support the buffer interface
This was reported in https://bugs.launchpad.net/nova/+bug/1632521, and a fix
was issued that simply forced tox to use py27.
** Affects: nova
Importance: Undecided
Assignee: Ed Leafe (ed-leafe)
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/1632856
Title:
Incorrect datatype for Python 3 in api-samples functional test
Status in OpenStack Compute (nova):
New
Bug description:
The nova/tests/functional/api_sample_tests/test_servers.py contains
the ServersSampleBase class, and in its class definition creates user
data by base64 encoding a string. However, this will not work in
Python 3, as the base64.b64encode() method requires bytes, not a
string.
This can be seen by simply running 'tox -e functional' under Python 3,
which then emits a series of errors, most of which look like:
Failed to import test module:
nova.tests.functional.api_sample_tests.test_servers
Traceback (most recent call last):
File
"/home/ed/projects/nova/.tox/functional/lib/python3.4/site-packages/unittest2/loader.py",
line 456, in _find_test_path
module = self._get_module_from_name(name)
File
"/home/ed/projects/nova/.tox/functional/lib/python3.4/site-packages/unittest2/loader.py",
line 395, in _get_module_from_name
__import__(name)
File
"/home/ed/projects/nova/nova/tests/functional/api_sample_tests/test_servers.py",
line 24, in
class ServersSampleBase(api_sample_base.ApiSampleTestBaseV21):
File
"/home/ed/projects/nova/nova/tests/functional/api_sample_tests/test_servers.py",
line 29, in ServersSampleBase
user_data = base64.b64encode(user_data_contents)
File "/home/ed/projects/nova/.tox/functional/lib/python3.4/base64.py", line
62, in b64encode
encoded = binascii.b2a_base64(s)[:-1]
TypeError: 'str' does not support the buffer interface
This was reported in https://bugs.launchpad.net/nova/+bug/1632521, and a fix
was issued that simply forced tox to use py27.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1632856/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1611458] [NEW] MIgration incorrectly compares None as greater than any time
Public bug reported: Description === The code in nova/compute/resource_tracker.py was updated in commit e5269b3a8f95c41283a9e6109835142586fe62a6 to better handle the comparison of potential None values in order to make the code Python 3 compatible. Unfortunately, the logic is incorrect, and will consider a migration with a None value for updated_at as more recent than a migration with a non-None datetime value. Steps to reproduce == The easiest way to reproduce is to run the unit test here: https://review.openstack.org/#/c/350319/8/nova/tests/unit/compute/test_tracker.py@1827 Note that it now has to *expect* the None value to be preferred over an actual value Expected result === Any migration that has been updated is always more recent than one that hasn't, so I would expect that any None-valued migration would not be selected over an actual date. Actual result = The None value is selected over one that has been updated. Environment === Nova master ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) => Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1611458 Title: MIgration incorrectly compares None as greater than any time Status in OpenStack Compute (nova): New Bug description: Description === The code in nova/compute/resource_tracker.py was updated in commit e5269b3a8f95c41283a9e6109835142586fe62a6 to better handle the comparison of potential None values in order to make the code Python 3 compatible. Unfortunately, the logic is incorrect, and will consider a migration with a None value for updated_at as more recent than a migration with a non-None datetime value. Steps to reproduce == The easiest way to reproduce is to run the unit test here: https://review.openstack.org/#/c/350319/8/nova/tests/unit/compute/test_tracker.py@1827 Note that it now has to *expect* the None value to be preferred over an actual value Expected result === Any migration that has been updated is always more recent than one that hasn't, so I would expect that any None-valued migration would not be selected over an actual date. Actual result = The None value is selected over one that has been updated. Environment === Nova master To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1611458/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1408908] Re: Nova API secgroup-list doesn't support all_tenants
Cannot reproduce in current dev master branch. Using a newly-installed devstack: ed@newstack:~(master)$ source demo.rc ed@newstack:~(master)$ nova secgroup-list ++-+-+ | Id | Name| Description | ++-+-+ | 1 | default | default | ++-+-+ ed@newstack:~(master)$ source nova.rc ed@newstack:~(master)$ nova secgroup-list ++-+-+ | Id | Name| Description | ++-+-+ | 2 | default | default | ++-+-+ ed@newstack:~(master)$ nova secgroup-list --all-tenants ++-+-+--+ | Id | Name| Description | Tenant_ID| ++-+-+--+ | 1 | default | default | 4181746562734419913fdbcc05409e0e | | 2 | default | default | 5a76dc40f9814fb692e45f5511e5057f | ++-+-+--+ ** 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/1408908 Title: Nova API secgroup-list doesn't support all_tenants Status in OpenStack Compute (nova): Invalid Bug description: When nova secgroup-list --all-tenants is given with sourcing admin, it is returning secgroups of only admin tenant. It should actually list secgroups of all the tenants present. This bug is reproduced in stable/icehouse and stable/juno Steps to reproduce this bug: ubuntu@ubuntu-ThinkCentre-M92p:~/devstack$ source openrc rem REMEMBER ubuntu@ubuntu-ThinkCentre-M92p:~/devstack$ nova secgroup-list +--+-+-+ | Id | Name| Description | +--+-+-+ | 4a00a598-e125-41c3-80ab-d9a6055d9a21 | default | default | +--+-+-+ ubuntu@ubuntu-ThinkCentre-M92p:~/devstack$ source openrc admin admin ubuntu@ubuntu-ThinkCentre-M92p:~/devstack$ nova secgroup-list +--+-+-+ | Id | Name| Description | +--+-+-+ | 51df59f5-1a05-4e99-9cbd-867114017e65 | default | default | +--+-+-+ ubuntu@ubuntu-ThinkCentre-M92p:~/devstack$ nova secgroup-list --all-tenants +--+-+-+--+ | Id | Name| Description | Tenant_ID | +--+-+-+--+ | 51df59f5-1a05-4e99-9cbd-867114017e65 | default | default | d6c7a334353c4613900bfe822ac93d0e | +--+-+-+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1408908/+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 1410651] Re: wrong output when trying to delete a default security group of admin tenant
No longer able to reproduce using development master branch ** 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/1410651 Title: wrong output when trying to delete a default security group of admin tenant Status in OpenStack Compute (nova): Invalid Bug description: When we are trying to delete a default security group from admin tenant then the wrong output displayed to the user. Steps to replicate : in admin tenant: 1. nova secgroup-list +--+-+-+ | Id | Name| Description | +--+-+-+ | 2d504a0f-b8c6-4ae5-b7f0-7184d43a998a| default | default | +--+-+-+ 2. nova secgroup-delete default +--+-+-+ | Id | Name| Description | +--+-+-+ | 2d504a0f-b8c6-4ae5-b7f0-7184d43a998a | default | default | +--+-+-+ 3. again list the security group you will found the same list nova secgroup-list +--+-+-+ | Id | Name| Description | +--+-+-+ | 2d504a0f-b8c6-4ae5-b7f0-7184d43a998a| default | default | +--+-+-+ delete command successfully runs but did not delete the default security group. Expected result : Removing default security group not allowed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1410651/+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 1523723] Re: nova scheduler utils parse_option needs more sanity check
Not a bug, as `parse_options` takes an optional `sep` argument. If you
wish to use '>=', pass that in as the `sep` named parameter.
** 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/1523723
Title:
nova scheduler utils parse_option needs more sanity check
Status in OpenStack Compute (nova):
Invalid
Bug description:
nova/scheduler/utils - parse_options() needs to do more sanity
check.[1]
>>> from nova.scheduler import utils
>>> utils.parse_options(['a>=5', 'b>3'])
[('a>', '5')]
>>>
The default separator is '='. So '>' gets filtered out but '>=' gets
allowed. This is even worse as it pollutes the key for the config opt.
One possible solution is to apply a grammar compatibility, what can be
an accepted opt-name, like variable name in a language. for the
LeftHandSide of the opt expression, the way it applies 'converter' to
the RightHandSide.
reported version of nova
[suro@oxy-dev nova (master)]$ git log -1
commit 78db34c0b59cc04883e1ffa215313092c15ce7c8
[1] -
https://github.com/openstack/nova/blob/stable/liberty/nova/scheduler/utils.py#L222
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1523723/+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 1547068] Re: Configuration option 'fake_call' is not used
** Changed in: nova Status: Invalid => 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/1547068 Title: Configuration option 'fake_call' is not used Status in OpenStack Compute (nova): New Bug description: As of stable/liberty there is a configuration option named 'fake_call', defined in nova/network/manager.py, and has been moved in Mitaka to nova/conf/network.py as part of the config option cleanup. Running grep on this name shows no usage of this option anywhere in the nova code base. Since it is not used, it should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1547068/+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 1547068] Re: Configuration option 'fake_call' is not used
** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1547068 Title: Configuration option 'fake_call' is not used Status in OpenStack Compute (nova): Invalid Bug description: As of stable/liberty there is a configuration option named 'fake_call', defined in nova/network/manager.py, and has been moved in Mitaka to nova/conf/network.py as part of the config option cleanup. Running grep on this name shows no usage of this option anywhere in the nova code base. Since it is not used, it should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1547068/+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 1547068] [NEW] Configuration option 'fake_call' is not used
Public bug reported: As of stable/liberty there is a configuration option named 'fake_call', defined in nova/network/manager.py, and has been moved in Mitaka to nova/conf/network.py as part of the config option cleanup. Running grep on this name shows no usage of this option anywhere in the nova code base. Since it is not used, it should be removed. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) => Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1547068 Title: Configuration option 'fake_call' is not used Status in OpenStack Compute (nova): New Bug description: As of stable/liberty there is a configuration option named 'fake_call', defined in nova/network/manager.py, and has been moved in Mitaka to nova/conf/network.py as part of the config option cleanup. Running grep on this name shows no usage of this option anywhere in the nova code base. Since it is not used, it should be removed. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1547068/+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 1524421] [NEW] Host Manager reads deleted instance info on startup
Public bug reported: In Kilo we added the ability of the HostManager to track information about the instances on compute nodes, so that filters that needed this information didn't have to constantly make database calls to get it. However, the call that is used by HostManager will return deleted instance records, which is not useful information and degrades the performance. In a large deployment, the overhead of loading the records for thousands of deleted instances is causing serious performance issues. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Tags: scheduler -- 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/1524421 Title: Host Manager reads deleted instance info on startup Status in OpenStack Compute (nova): New Bug description: In Kilo we added the ability of the HostManager to track information about the instances on compute nodes, so that filters that needed this information didn't have to constantly make database calls to get it. However, the call that is used by HostManager will return deleted instance records, which is not useful information and degrades the performance. In a large deployment, the overhead of loading the records for thousands of deleted instances is causing serious performance issues. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1524421/+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 1494289] [NEW] Docstring for validators._soft_validate_additional_properties is incomplete
Public bug reported: The recent change to validators.py to allow for varying scheduler hints added the parameter 'additional_properties_value', which strongly affects the behavior of the method, but this behavior was not explained in the method's docstring. It was felt that we should merge the change and fix this later, so this bug report is to ensure that we don't forget. https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L78-L98 ** Affects: nova Importance: Low Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Importance: Undecided => Low ** Changed in: nova Assignee: (unassigned) => Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1494289 Title: Docstring for validators._soft_validate_additional_properties is incomplete Status in OpenStack Compute (nova): New Bug description: The recent change to validators.py to allow for varying scheduler hints added the parameter 'additional_properties_value', which strongly affects the behavior of the method, but this behavior was not explained in the method's docstring. It was felt that we should merge the change and fix this later, so this bug report is to ensure that we don't forget. https://github.com/openstack/nova/blob/master/nova/api/validation/validators.py#L78-L98 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1494289/+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 1489627] [NEW] Incorrect use of os.path.join() in nova/api/openstack/common.py
Public bug reported: Three of the link manipulation methods in nova/api/openstack/common.py rejoin the URL parts by using os.path.join(). This is incorrect, as it is OS-dependent, and can result in invalid URLs under Windows. Generally the urlparse module would be the best choice, but since these URL fragments aren't created with urlparse.urlparse() or urlparse.urlsplit(), the equivalent reconstruction methods in that module won't work. It is simpler and cleaner to just use /.join(). Additionally, there are no unit tests for these methods, so tests will have to be added first before we can fix the methods, so that we have some assurance that we are not breaking anything. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) = Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1489627 Title: Incorrect use of os.path.join() in nova/api/openstack/common.py Status in OpenStack Compute (nova): New Bug description: Three of the link manipulation methods in nova/api/openstack/common.py rejoin the URL parts by using os.path.join(). This is incorrect, as it is OS-dependent, and can result in invalid URLs under Windows. Generally the urlparse module would be the best choice, but since these URL fragments aren't created with urlparse.urlparse() or urlparse.urlsplit(), the equivalent reconstruction methods in that module won't work. It is simpler and cleaner to just use /.join(). Additionally, there are no unit tests for these methods, so tests will have to be added first before we can fix the methods, so that we have some assurance that we are not breaking anything. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1489627/+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 1459826] [NEW] Use of the builtin name 'filter' as variable name
Public bug reported: A few programs, most notably nova/filters.py, that deal with the filtering aspect of the nova scheduler use the name 'filter' for variables, which conflicts with the builtin function 'filter'. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) = Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1459826 Title: Use of the builtin name 'filter' as variable name Status in OpenStack Compute (Nova): New Bug description: A few programs, most notably nova/filters.py, that deal with the filtering aspect of the nova scheduler use the name 'filter' for variables, which conflicts with the builtin function 'filter'. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459826/+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 1434112] [NEW] Optimize periodic call to get_by_host
Public bug reported: A recent change (https://review.openstack.org/#/c/160513) added a periodic task to the compute manager that retrieves a list of instances. During review it was suggested that the call could be optimized, but that it could be done as a later bugfix. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) = Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1434112 Title: Optimize periodic call to get_by_host Status in OpenStack Compute (Nova): New Bug description: A recent change (https://review.openstack.org/#/c/160513) added a periodic task to the compute manager that retrieves a list of instances. During review it was suggested that the call could be optimized, but that it could be done as a later bugfix. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1434112/+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 1408480] [NEW] PciDevTracker passes context module instead of instance
Public bug reported:
Currently, the code in the PciDevTracker.__init__() method of
nova/pci/manager.py reads:
```
def __init__(self, node_id=None):
Create a pci device tracker.
If a node_id is passed in, it will fetch pci devices information
from database, otherwise, it will create an empty devices list
and the resource tracker will update the node_id information later.
super(PciDevTracker, self).__init__()
self.stale = {}
self.node_id = node_id
self.stats = stats.PciDeviceStats()
if node_id:
self.pci_devs = list(
objects.PciDeviceList.get_by_compute_node(context, node_id))
else:
self.pci_devs = []
self._initial_instance_usage()
```
The problem is that in the call to
`objects.PciDeviceList.get_by_compute_node(context, node_id)`, there is
no local value for the 'context' parameter, so as a result, the context
module defined in the imports is what is passed.
Instead, the parameter should be changed to
`context.get_admin_context()`.
** Affects: nova
Importance: Undecided
Assignee: Ed Leafe (ed-leafe)
Status: New
** Changed in: nova
Assignee: (unassigned) = Ed Leafe (ed-leafe)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1408480
Title:
PciDevTracker passes context module instead of instance
Status in OpenStack Compute (Nova):
New
Bug description:
Currently, the code in the PciDevTracker.__init__() method of
nova/pci/manager.py reads:
```
def __init__(self, node_id=None):
Create a pci device tracker.
If a node_id is passed in, it will fetch pci devices information
[Yahoo-eng-team] [Bug 1381185] [NEW] Update imports to use jsonutils from oslo.serialization
Public bug reported: The code for jsonutils has moved from oslo-incubated to the oslo.serialization library. References to the old jsonutils in nova.openstack.common should be updated to use the version in oslo.serialization. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: New ** Changed in: nova Assignee: (unassigned) = Ed Leafe (ed-leafe) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1381185 Title: Update imports to use jsonutils from oslo.serialization Status in OpenStack Compute (Nova): New Bug description: The code for jsonutils has moved from oslo-incubated to the oslo.serialization library. References to the old jsonutils in nova.openstack.common should be updated to use the version in oslo.serialization. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1381185/+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 1381185] Re: Update imports to use jsonutils from oslo.serialization
Another patch hit Gerrit before mine that fixed this issue, so this is no longer a valid bug. ** 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/1381185 Title: Update imports to use jsonutils from oslo.serialization Status in OpenStack Compute (Nova): Invalid Bug description: The code for jsonutils has moved from oslo-incubated to the oslo.serialization library. References to the old jsonutils in nova.openstack.common should be updated to use the version in oslo.serialization. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1381185/+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
