** Also affects: cinder
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/2051108
Title:
Support for the "bring your own keys"
Public bug reported:
Our jobs that run the evacuate post hook are failing due to not being
able to run the ansible virt module because of a missing lxml library:
2023-10-16 14:38:57.818847 | TASK [run-evacuate-hook : Register running domains
on subnode]
2023-10-16 14:38:58.598524 | controller
Public bug reported:
If an operator configures cpu0 in the dedicated set and enables state
management, nova-compute will fail on startup with this obscure error:
Oct 06 20:08:43.195137 np0035436890 nova-compute[104711]: ERROR
oslo_service.service nova.exception.FileNotFound: File
The instance name in the XML is not the instance name according to nova.
It is generated based on a template by the compute driver and is not
otherwise mutable. So this is operating as designed.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you
Public bug reported:
This isn't really a bug in nova, but it's something that we're hitting
in CI quite a bit, so I'm filing here to record the details and so I can
recheck against it. The actual bug is either in the guest (cirros 0.5.2)
kernel, QEMU, or something similar. In tests where we
Public bug reported:
This is the same problem as https://bugs.launchpad.net/nova/+bug/1846820
but for scheduler. Because we initialize our placement client during
manager init, we will crash (and loop) on startup if keystone or
placement are down. Example trace:
Mar 22 15:54:39 jammy
Public bug reported:
As reported on the mailing list:
http://lists.openstack.org/pipermail/openstack-
discuss/2022-January/026603.html
The service version check at startup can prevent FFUs from being
possible without hacking the database. As implemented here:
Public bug reported:
The patch 9e002a77f2131d3594a2a4029a147beaf37f5b17 which is aimed at
fixing things in advance of SQLAlchemy 2.0 seems to have broken our
opportunistic testing of DB migrations on py36 only. This manifests as a
total lockup of one worker during functional tests, which fails to
Public bug reported:
The test
glance.tests.unit.v2.test_images_resource.TestImagesController.test_update_queued_image_with_hidden
seems to be looking to confirm that queued images cannot be marked as
hidden. However, if that was the case, it should be checking for
BadRequest (or similar) and not
Public bug reported:
During an upgrade to Xena, cinder-backed image locations are migrated to
include the store name in the URL field. This is lazily done on the
first GET of the image. The problem is that the first user to GET an
image after the migration may not be an admin or the owner of the
Public bug reported:
The glance /images/$uuid/tasks API is excluding in-progress tasks,
leading to test failures like this one:
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/api/image/v2/test_images.py", line 111, in
test_image_glance_direct_import
Public bug reported:
We broke check_instance_shared_storage() in this change:
https://review.opendev.org/c/openstack/nova/+/761452/13..15/nova/compute/rpcapi.py
Where we re-ordered the rpcapi client signature without adjusting the
caller. This leads to this failure:
Mar 25 13:46:28.041587
** Changed in: glance
Status: Invalid => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1913625
Title:
Glance will leak staging data
Status in Glance:
Confirmed
Bug
Public bug reported:
Glance is translating "Not Found" errors from the DB layer into "Not
Authorized" errors in policy, which it should not be doing. In general,
we should always return 404 when something either does not exist, or
when permissions do not allow you to know if that thing exists.
Public bug reported:
In my testing, if I provide a URL to web-download that yields an error
from urlopen(), I never see the store listed in the
os_glance_failed_import list, and the store remains in
os_glance_importing_to_stores. The image status does not change, which
means there's no way for
Public bug reported:
Noticed during a cinder multistore test run, we hit a quota not found
error. It looks like we don't handle this well, which causes nova to see
a 503: Proxy Error. I dunno if there's anything better can do than raise
a 5xx, but we should probably explain in the error what
Public bug reported:
Seeing this failure in the gate:
https://zuul.opendev.org/t/openstack/build/7c71502b04fe47039b87f76fbe04fe56/log/controller/logs/screen-n-cpu.txt#33096
Feb 04 20:54:32.857198 ubuntu-focal-limestone-regionone-0022873642
nova-compute[90163]: ERROR nova.virt.libvirt.driver
Public bug reported:
In various situations, glance will leak (potentially very large)
temporary files in the staging store.
One example is doing a web-download import, where glance initially
downloads the image to its staging store. If the worker doing that
activity crashes, loses power, etc,
Public bug reported:
Certain image properties are reserved for internal glance usage, such as
os_glance_import_task. Changing these properties is disallowed during
PATCH. However, glance does not enforce that they are not present in an
image POST. It should.
This command:
openstack --debug
Public bug reported:
During the MultiStoresImportTest module in tempest, when we go to clean
up images during tearDown, we occasionally get a 500 from the delete,
which yields this from the test:
ft1.1: tearDownClass
Public bug reported:
If import is called with all_stores_must_succeed=True and a store fails
during set_image_data(), the store will remain in
os_glance_importing_stores forever, never going into the
os_glance_failed_import list. This means a polling client will never
notice that the import
Public bug reported:
The glance.tests.functional.test_reload.TestReload.test_reload() test
has been causing spurious deadlocks in functional test jobs, resulting
in TIMED_OUT job statuses due to the global timeout expiring. This can
be reproduced locally with lots of exposure, but Zuul runs
Public bug reported:
The wsgi_app.py file in the tree allows operators to run Glance API as a
proper WSGI app. This has been the default devstack deployment for some
time and multiple real clouds in the wild deploy like this. However, an
attempt to start an import will be met with an image state
Public bug reported:
This is a hypothetical (but very possible) scenario that will result in
a corrupted image stored by glance. I don't have code to reproduce it,
but discussion seems to indicate that it is possible.
Scenario:
1. Upload image to glance to one store, everything is good
2. Start
Public bug reported:
I'm filing this bug a little prematurely because Abhi and I didn't get a
chance to fully discuss it. However, looking at the code and the
behavior I'm seeing due to another bug (1884587), I feel rather
confident.
Especially in a situation where glance is running on multiple
Public bug reported:
In testing the image import copy-to-store mechanism from Nova, I hit an
issue that seems clearly to be a bug. Scenario:
A user boots an instance from an image they have permission to see. Nova
uses their credentials to start an image import copy-to-store operation,
which
Public bug reported:
Nova does not currently support multiple rbd backends. However, Glance
does and an operator may point Nova at a Glance with access to multiple
RBD clusters. If this happens, Nova will silently download the image
from Glance, flatten it, and upload it to the local RBD cluster
Nova does not even call down to the compute node when attributes like
display_name are changed. The next time the xml is updated would be when
it is regenerated, like during a lifecycle event (hard reboot) or
migration. Ceilometer scraping that information out of the libvirt XML
underneath nova
ognised
2019-03-14 19:11:31.709 6 ERROR nova.compute.manager
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Co
ind(':')
ERROR nova.objects.cell_mapping AttributeError: 'NoneType' object has no
attribute 'find'
ERROR nova.objects.cell_mapping
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms)
Status: In Progress
--
You received this bug notification because you are a
than what we have today,
even discounting this race. We can do what we did before, which is do it
once for backports, and then add a mapped bit in master to make it more
efficient, allowing it to be included in the scheduler periodic task.
** Affects: nova
Importance: Medium
Assignee:
Importance: Medium
Assignee: Dan Smith (danms)
Status: In Progress
** Tags: queens-rc-potential 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/1746294
Public bug reported:
This error occurs during Newton's online_data_migration phase:
error: (pymysql.err.DataError) (1406, u"Data too long for column 'spec'
at row 1") [SQL: u'INSERT INTO request_specs
Which comes from RequestSpec.instance_group.members being extremely
large
** Affects: nova
Public bug reported:
Testing with 500 instances in ACTIVE, and 500 in ERROR state, using curl
to pull all 1000 instances ten times in a row, 2.47 clearly shows a knee
in the curve on average response time:
https://imgur.com/a/2lmiw
We should...fix that and stuff.
** Affects: nova
Public bug reported:
In nova/service.py we poll for conductor readiness before we allow
normal service startup behavior. The ironic driver does RPC to conductor
in its _refresh_hash_ring() code, which may expect conductor be up
before it's not. If so, we'll fail to start up because we called to
Public bug reported:
As far back as Ocata, compute nodes that manage allocations will end up
overwriting allocations from other compute nodes when doing a migration.
This stems from the fact that the Resource Tracker was designed to
manage a per-compute-node set of accounting, but placement is
Public bug reported:
Nova's resource tracker is expected to publish negative values to the
scheduler when resources are overcommitted. Nova's scheduler expects
this:
https://github.com/openstack/nova/blob/a43dbba2b8feea063ed2d0c79780b4c3507cf89b/nova/scheduler/host_manager.py#L215
In change
** Changed in: nova
Status: Fix Released => Confirmed
--
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/1696125
Title:
Detach interface failed - Unable to detach
Dupe of 1692397
** Changed in: nova
Status: New => Won't Fix
--
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/1693911
Title:
compute node statistics will lie if
Public bug reported:
If a compute node references a deleted service, we will include it in
the compute node statistics output. This happens even if the compute
node record _is_ deleted, because of our join of the services table,
which causes us to get back rows anyway. This results in the stats
** 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/1684861
Title:
Database online_data_migrations in newton fail due to
The missed steps are documented here:
https://docs.openstack.org/developer/nova/cells.html#first-time-setup
That should get you a cell record created, hosts discovered, and back on
track.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a
Public bug reported:
This could contain credentials for the DB and MQ
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms)
Status: In Progress
** Tags: newton-backport-potential
--
You received this bug notification because you are a member of Yahoo
Public bug reported:
If deleted service records are present in the database, the Service
minimum version calculation should ignore them, but it does not. One
manifestation of this is the PCI device migration from mitaka/newton
will never complete, emitting an error message like this:
2017-02-27
the main
database.
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms)
Status: In Progress
** Tags: newton-backport-potential ocata-backport-potential
** Tags added: newton-backport-potential
--
You received this bug notification because you are a member of Yahoo
Cells are not optional in Nova as of Ocata. Since cells are required,
you should not see instances that are not assigned to a cell, because
such a thing is not possible (post-scheduling).
Creating an instance before nova is fully setup is not valid either.
These two things combined are doubly
What you describe is fundamental to how nova works right now. We
speculate in the scheduler, and if we race between two, we handle it
with a reschedule. Nova specifically states that scheduling every last
resource is out of scope. When trying to do that (which is often the use
case for ironic)
Public bug reported:
The following sequence of events will result in a corrupted instance
allocation in placement:
1. Instance running on host A, placement has allocations for instance on host A
2. Host A goes down
3. Instance is evacuated to host B, host B creates duplicated allocations in
Something in your config has been preventing compute nodes from creating
their compute node records for much longer than the referenced patch has
been in place. I picked a random older run and found the same compute
node record create failure:
Public bug reported:
Newton scheduler clients will stop reporting any time they encounter a
setup-related error, which isn't very operator-friendly for the ocata
upgrade process.
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: Confirmed
** Tags
Yeah, mixed-version controllers isn't supported. We've made some
progress towards being able to support it in master, but it's definitely
not going to work in mitaka/newton.
You have to upgrade your controllers simultaneously (well, most
critically, your conductor services), and then you can have
on the system, VM
creates started failing with "Argument list too long" as libvirt was
choking on enumerating the interfaces it had left behind.
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: In Progress
** Affects: nova/newton
Importance:
4323 DEBUG nova.compute.resource_tracker [req-...]
Migration instance not
found: Instance 585ac641-... could not be found.
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms)
Status: In Progress
** Tags: mitaka-backport-potential
--
You received this bug notification b
Public bug reported:
Recently the ceph job (and any other configuration that doesn't use disk
image as the backend storage) started failing like this:
2016-03-09 14:47:29.102 17597 ERROR oslo_messaging.rpc.dispatcher Traceback
(most recent call last):
2016-03-09 14:47:29.102 17597 ERROR
Public bug reported:
During a normal tempest run, way (way) too many object lazy-loads are
being triggered, which causes extra RPC and database traffic. In a given
tempest run, we should be able to pretty much prevent any lazy-loads in
that predictable situation. The only case where we might want
Public bug reported:
The following message in nova gate test logs shows that libvirt live
migration can stall on some sort of deadlock:
2016-01-28 16:53:20.878 INFO nova.virt.libvirt.driver [req-692a1f4f-
16aa-4d93-a694-1f7eef4df9f6 tempest-
LiveBlockMigrationTestJSON-1471114638 tempest-
version 0
Which is clearly wrong (service_version minimum should be 2 not 0)
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed
Public bug reported:
When we convert a V2 instance to a V1 instance, we don't provide it a
context, which could, under some circumstances, cause a failure to lazy-
load things we need to construct the older instance.
** Affects: nova
Importance: High
Assignee: Dan Smith (danms
** Changed in: nova
Importance: High => Undecided
** Changed in: nova
Status: In Progress => Invalid
** Changed in: nova
Milestone: liberty-rc1 => None
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Assignee: Dan Smith (danms)
Status: Confirmed
--
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/1498023
Title:
_cleanup_incomplete_migrations() does not check
** Changed in: nova
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1387244
Title:
Increasing number of
Public bug reported:
The debug log statement in nova-conductor's object_backport_versions()
method doesn't format and looks like this:
2015-09-09 11:26:57.126 DEBUG nova.conductor.manager [req-9ff7962c-
c8b8-4579-8943-cbf2ef0be373 demo demo] Backporting %(obj)s to %(ver)s
with versions
Public bug reported:
Nova will accept an unbounded number of live migrations for a single
host, which will result in timeouts and failures (at least for libvirt).
Since live migrations are seriously IO intensive, allowing this to be
unlimited is just never going to be the right thing to do,
changes, then we will just delete data based on a hunch.
Nova-compute needs a better mechanism to detect if an evacuation has
actually been requested before deleting the data.
See Blueprint robustify-evacuate
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms
Public bug reported:
In nova/tests/objects/test_objects.py, we have an important test called
test_relationships(). This ensures that we have version mappings between
objects that depend on each other, and that those versions and
relationships are bumped when one object changes versions.
That
Public bug reported:
Nova's List-based objects have something called child_versions, which is
a naive mapping of the objects field and the version relationships
between the list object and the content object. This was created before
we generalized the work in obj_relationships, which normal
creation failed
** Affects: nova
Importance: High
Assignee: Dan Smith (danms)
Status: In Progress
** Tags: juno-backport-potential kilo-backport-potential libvirt neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
Public bug reported:
We badly need to bump the compute RPC version to 4.0 BEFORE we release
kilo.
** Affects: nova
Importance: Critical
Assignee: Dan Smith (danms)
Status: Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team
Assignee: Dan Smith (danms)
Status: In Progress
** Tags: unified-objects
--
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/1441243
Title:
EnumField can be None and thus
to
refresh_instance_security_rules()
** Affects: nova
Importance: Undecided
Assignee: Dan Smith (danms)
Status: Confirmed
--
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/1435586
, in encode
chunks = self.iterencode(o, _one_shot=True)
File /usr/lib64/python2.7/json/encoder.py, line 270, in iterencode
return _iterencode(o, 0)
ValueError: Circular reference detected
** Affects: nova
Importance: Critical
Assignee: Dan Smith (danms
27090 TRACE nova.notifications [instance:
74bb24d3-ba69-41e2-b99a-1c35a2331c1b]
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: Confirmed
** Changed in: nova
Importance: Undecided = Medium
** Changed in: nova
Status: New = Confirmed
** Changed
** Changed in: nova
Status: Opinion = Confirmed
--
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/1373106
Title:
jogo and sdague are making me sad
Status in
Public bug reported:
Currently DB migrations can be added to the tree without the
corresponding migration tests. This is bad and means that we have some
that are untested in the tree already.
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: In Progress
This is super old, lots has changed since then, and several folks have
not been able to reproduce. Please re-open if this is still valid.
** Changed in: nova
Importance: High = Undecided
** Changed in: nova
Status: Triaged = Invalid
** Changed in: nova
Assignee: Dan Smith (danms
Assignee: Dan Smith (danms)
Status: Confirmed
** Tags: unified-objects
--
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/1361683
Title:
Instance pci_devices
Public bug reported:
From http://logs.openstack.org/70/113270/3/check/gate-nova-
python26/038b3fa/console.html:
2014-08-21 20:08:33.507 | Traceback (most recent call last):
2014-08-21 20:08:33.507 | File nova/tests/conductor/test_conductor.py, line
1343, in
Public bug reported:
The object hash test will fail to detect method signature changes when
something like the serialize_args decorator is used. The test needs to
drill down until it finds the remotable level and do the calculation
there.
** Affects: nova
Importance: Low
Assignee: Dan
Importance: Undecided
Assignee: Dan Smith (danms)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1351020
Title:
FloatingIP fails
which means we don't fully tear down everything
at disconnect time.
This is present in at least Havana, and I expect it is present in
Icehosue and master as well.
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: Confirmed
** Tags: libvirt
--
You received
Marking this as invalid since there was no follow up to the question of
recurrence in the last three months.
** Changed in: nova
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
I think we determined this was related to a bad backport via mailing
list convo. Re-open if not.
** 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).
** Also affects: nova/icehouse
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/1308715
Title:
Deadlock on quota_usages
: ['ovs-vsctl', '--timeout=120', 'del-port',
'br-int', u'qvo81ce661d-1a']
** Affects: nova
Importance: High
Assignee: Dan Smith (danms)
Status: Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Public bug reported:
Change Ia0ebd674345734e7cfa31ccd400fdba93646c554 traded one race
condition for another. By ignoring all mkdir() calls that would
otherwise fail because an instance directory already exists, two nodes
racing to create a single image will corrupt or lose data, or fail in a
Public bug reported:
This change:
https://review.openstack.org/#/c/66469
Changed the format of the data in the values dictionary of
compute_node_update. This causes an icehouse conductor to generate a
broken SQL query when called from a havana compute node:
Public bug reported:
The simple_tenant_usage extension gets the flavor data from the instance
and then looks up the flavor from the database to return usage
information. Since we now store all of the flavor data in the instance
itself, we should use that information instead of what the flavor
Public bug reported:
Several virt drivers are using non-standard driver-specific image
metadata properties. This creates an API contract between the external
user and the driver implementation. These non-standard ones should be
marked as deprecated in some way, enforced in v3, etc. We need a
Public bug reported:
If an older node does an Instance.refresh() it will fail because
conductor will overwrite the info_cache field with a new
InstanceInfoCache object. This happens during the LifecycleEvent handler
in nova-compute.
** Affects: nova
Importance: Undecided
Assignee: Dan
Public bug reported:
Icehouse introduced a state called image_snapshot_pending which havana
nodes do not understand. If they call save with
expected_task_state=image_snapshot they will crash on the new state.
2014-01-02 11:58:46.766 TRACE nova.openstack.common.rpc.amqp File
this properly.
** Affects: nova
Importance: Medium
Assignee: Dan Smith (danms)
Status: Confirmed
** Tags: unified-objects
--
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
I don't think this bug is valid. Isn't the problem just that you're
failing to schedule both times and ending up with the same error
message?
** Changed in: nova
Status: In Progress = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which
** Changed in: nova
Importance: Undecided = Wishlist
** Changed in: nova
Status: New = Opinion
--
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/1165895
Title:
Yes, that's the fix I'm talking about. I'm going to mark this bug as
invalid since it has already been fixed.
** Changed in: nova
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
OP realized this is a dupe
** 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/1161496
Title:
Boot from volume will attach
This was fixed at some point, probably after several recent changes, and
is no longer an issue according to the reporter.
** Changed in: nova
Status: Triaged = Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
96 matches
Mail list logo
