Hi, Thanks guys for digging into it. It is much appreciated.
It was as sean said, the libvirt-python package was cached into the
systems, and after cleaning the cache, everything worked as expected.
** Changed in: nova
Status: Incomplete => Invalid
--
You received this bug notification
https://review.opendev.org/c/openstack/charm-keystone/+/797516 landed.
Marking Fix Committed.
** Changed in: keystone
Status: New => Fix Committed
** Changed in: charm-keystone-ldap
Status: Triaged => Invalid
** Changed in: keystone
Status: Fix Committed => Invalid
** Also
Public bug reported:
When updating the mtu on a network, the new mtu is correctly set in
qrouter-namespace but not in snat-namespace.
Also, a stack trace is reported in l3-agent logs stating that the qr-
abcdef interface is not found.
Step by step:
- create a router in DVR mode (I also have HA,
Reviewed: https://review.opendev.org/c/openstack/neutron/+/780055
Committed:
https://opendev.org/openstack/neutron/commit/77ac42d2ee664263dd1dfd391dac4d8e062875e0
Submitter: "Zuul (22348)"
Branch:master
commit 77ac42d2ee664263dd1dfd391dac4d8e062875e0
Author: Rodolfo Alonso Hernandez
Date:
Reviewed: https://review.opendev.org/c/openstack/nova/+/769614
Committed:
https://opendev.org/openstack/nova/commit/387823b36d091abbaa37efb930fc98b94a5bbb93
Submitter: "Zuul (22348)"
Branch:master
commit 387823b36d091abbaa37efb930fc98b94a5bbb93
Author: Sean Mooney
Date: Wed Jan 6 19:49:56
It's a valid bug, but as ports are Neutron's responsibility, I'm not
sure what can be done in this case. Neutron is free to delete a port
without checking anything about the instance it's attached to. Perhaps
this can be changed to the Neutron component, to see if folks there have
an idea?
** Proj
Public bug reported:
Neutron's RBAC system supports security group sharing but it's
impossible to use with changed policies. When RBAC for security groups
was added [1] field "shared" was not added to the database. As result,
we cannot use this flag for policy checks and SG sharing will work only
Reviewed: https://review.opendev.org/c/openstack/neutron/+/796844
Committed:
https://opendev.org/openstack/neutron/commit/976cba61331702e1a8e4781af478fa4676afd13d
Submitter: "Zuul (22348)"
Branch:master
commit 976cba61331702e1a8e4781af478fa4676afd13d
Author: Slawek Kaplonski
Date: Thu Jun
Public bug reported:
Traceback (most recent call last):
File "/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/base.py",
line 183, in func
return f(self, *args, **kwargs)
File
"/home/zuul/src/opendev.org/openstack/neutron/neutron/tests/fullstack/test_l3_agent.py",
line 322, in
I browsed the current Keystone code, issues and opened reviews, and I
believe this issue is still in Keystone and there is no review that
attempted to address this, even abandoned.
There are other reviews around Keystone, LDAP and non-ASCII chars but
not regarding teaching the encoding to osci.con
Public bug reported:
When instances are booting, they will try to retrieve metadata from
Nova by the path of Neutron virtual switches(bridges), virtual devices,
namespaces and metadata-agents. After that, metadata agent has no other
functionalities. In large-scale scenarios, a large number of depl
Public bug reported:
Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1949460
VMs subscribed to a multicast group are receiving 2 multicast packets
when only one is sent by a sender VM.
I dug into the problem and found out that the problematic option is
"mcast_flood" set in the localnet
12 matches
Mail list logo
