Hello, thanks for the report.
This falls outside the scope of a Nova bug. It's either a support
request, or a deployment question. You can try asking on the openstack-
discuss mailing list [1].
[1] https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-
discuss
** Changed in: nova
Hello, thanks for the bug report!
IIRC the host oom killer runs per NUMA node, so in this case this sounds
like expected behaviour: node0 is out of memory (32 + 64 is bigger than
64).
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a membe
While Nova indeed exposes the MTU in our metadata, our source of truth
for that information is Neutron, via the `mtu` field on the Neutron
network.
[As an aside, we've had a long standing issue wherein Neutron allows the
MTU to be mutable, but there's no real support for changing the MTU
within No
** Also affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1987393
Title:
autopkgtest-buildvm-ubuntu-cloud hangs on ppc64el
** Changed in: cloud-archive/zed
Status: New => Fix Released
** Changed in: cloud-archive/yoga
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1973
** Also affects: cloud-archive
Importance: Undecided
Status: New
** Also affects: cloud-archive/xena
Importance: Undecided
Status: New
** Also affects: cloud-archive/yoga
Importance: Undecided
Status: New
** Also affects: cloud-archive/zed
Importance: Undecided
** Also affects: neutron (Ubuntu)
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/1973276
Title:
OVN port loses its virtual type after port upd
Public bug reported:
masquerading behavior changed beteen queens and train following [1]
implementation of random-fully to solve another issue. Now, the source
port is remapped randomly to some undeterminisitc value in order to
avoid a racy tuple generation in the kernel but this has for effect
Reviewed: https://review.opendev.org/c/openstack/neutron/+/852885
Committed:
https://opendev.org/openstack/neutron/commit/3202a5c19ec01dfd38c4471be21002467bc0a0e5
Submitter: "Zuul (22348)"
Branch:master
commit 3202a5c19ec01dfd38c4471be21002467bc0a0e5
Author: Rodolfo Alonso Hernandez
Date:
Public bug reported:
This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:
- [X] This doc is inaccurate in this way: The doc should specify
commenting out the `Listen` parameter in http
As commented in IRC, the problem is not in the metadata service. The
creation of the namespace, assignation of the IP address and spawn of
the proxy is done in 2 seconds.
The problem seems to be be in the addition of the OF rules in OVS. But
this is not related to the metadata agent.
** Changed i
Public bug reported:
This RFE proposes to add a new valid DSCP mark value: 44.
This value was recently added in the RFC5865 [1]: "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic".
[1]https://www.rfc-editor.org/rfc/rfc5865.html
[2]https://www.iana.org/assignments/dscp-r
Public bug reported:
env:
branch: stable/victoria
The memory footprint becomes smaller after restarting the metadata-
agent, but as it runs longer, the memory footprint becomes larger and
larger until it is killed by oom
kubectl top pod neutron-metadata-agent-default-6nz79 -nopenstack
NAME
13 matches
Mail list logo
