Public bug reported:
Description
===
Following an upgrade from 2023.1 to 2023.2 we are seeing intermittent issues
with requests to perform live migrations (and potentially cold migrations). The
failed requests result in the impacted instances going into an error state
which appears
Public bug reported:
As far as I can tell this is likely to be a Nova issue rather than
Neutron, but as it relates to both I can't be certain.
Description
===
When an instance is first created, the 'dns_name' for its network port(s)
reflects the instance name. When the instance is then
Public bug reported:
Neutron 2023.1 29cc1a634e530972614c09fbb212b5f63fd4c374
Ubuntu 20.04
This issue has been identified in a Neutron system running Linux Bridge
networking, but whilst this may no longer be supported I'm posting it in
case the same issue might be relevant for other drivers.
Public bug reported:
As far as I can tell, when Horizon interacts with an OpenStack API via
the relevant client (for example Nova client), it currently instantiates
the client with a major version integer by default (for example '2')
unless a feature requires an explicit microversion (as
Public bug reported:
This is a follow-up to https://bugs.launchpad.net/nova/+bug/1967314
Having deployed the Nova scheduler configuration for routed provider
networks as follows (Xena deployment @
7df9379d6661233174d49fb7be8eda0828a5e5ca), this was found to resolve
issues around scheduling of
Public bug reported:
Description
===
Nova does not appear to take account of Neutron-defined host aggregates when
migrating instances which have interfaces attached to routed provider networks.
If the operator does not manually select an appropriate hypervisor to migrate
to (within the
Public bug reported:
We have a Xena deployment based on Linux bridge networking, with a mix
of Neutron managed VXLAN, and routed/L3 provider networks.
neutron-dhcp-agent services are deployed to a set of network nodes in
order to serve the VXLAN networks. These services are also deployed to a
** Changed in: nova
Status: Expired => 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/1915400
Title:
Snapshots fail with traceback from API
Status in
Public bug reported:
We have seen regular issues with the neutron-bgp-dragent service when
one or more network nodes fail or are undergoing maintenance.
In the most problematic case, we have a deployment with four network
nodes. Each of these runs a neutron-bgp-dragent process, and each is
Public bug reported:
Description
===
Having upgraded three OpenStack deployments to Victoria, we have noticed that
snapshots are now failing to be created. When a user attempts this via Horizon
they receive an error such as:
Error: Unable to create snapshot. Details
Unexpected API
Public bug reported:
Running 'nova-manage placement audit --verbose' results in various
reports of orphaned resources. However, if one resource provider is
selected and 'nova-manage placement --verbose --resource_provider
' is used this always indicates that the resource provider does
not exist.
Public bug reported:
Having upgraded to Ussuri, we've noted that live migrations now always
fail across our hosts with newer Intel CPUs (identified by libvirt as
Cascadelake-Server-noTSX).
When processing the CPU's features, the calls made by Nova to libvirt
appear to result in an XML segment
12 matches
Mail list logo
