Maximets.
On Tue, Jun 4, 2024 at 11:05 AM Simon Horman wrote:
+ Ihar
On Fri, May 31, 2024 at 03:40:08PM -0400, Brian Haley wrote:
An earlier patch [1] increased the size of the listen
backlog to 64. While that was a huge improvement over
10, further testing in large deployments showed 128
/ovs/commit/2b7efee031c3a2205ad2ee999275893edd083c1c
[2]
https://github.com/openvswitch/ovs/commit/2b7efee031c3a2205ad2ee999275893edd083c1c
Signed-off-by: Brian Haley
---
lib/socket-util.c| 2 +-
python/ovs/stream.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib
Sorry, just clicked the wrong buttons, trying to get this targeted to
the UCA back to Ussuri.
** Also affects: neutron/wallaby
Importance: Undecided
Status: New
** Also affects: neutron/xena
Importance: Undecided
Status: New
** Also affects: neutron/ussuri
Importance:
Sorry, just clicked the wrong buttons, trying to get this targeted to
the UCA back to Ussuri.
** Also affects: neutron/wallaby
Importance: Undecided
Status: New
** Also affects: neutron/xena
Importance: Undecided
Status: New
** Also affects: neutron/ussuri
Importance:
BTW, Terry Wilson found the original neutron bug where this behavior was
introduced in neutron, allowing all subnets indirectly connected to a
router to use the default SNAT address.
https://bugs.launchpad.net/neutron/+bug/1386041
Wanted to make sure that was documented.
--
You received this
Well, for the PUT operation it's the same thing for neutron (and the
same call here [0]), whether the port is null or another valid port id,
neutron is going to update it.
As I mentioned in the other bug, it will be up to the Nova team to
determine if it's API is working correctly.
[0] PUT
The Neutron API is only associating a floating IP with an internal port
[0], there is no check for a server as that is under the purview of
Nova.
Neutron will only raise a 409 on a 'create' call if the floating IP is
already in-use, but not on a call to update it - either clearing or
moving to
On 4/4/24 12:59 PM, Ilya Maximets wrote:
On 4/4/24 18:07, Brian Haley wrote:
Hi,
On 4/4/24 6:12 AM, Ilya Maximets wrote:
On 4/3/24 22:15, Brian Haley via discuss wrote:
Hi,
I recently have been seeing issues in a large environment where the
listen backlog of ovsdb-server, both NB and SB
Hi,
On 4/4/24 6:12 AM, Ilya Maximets wrote:
On 4/3/24 22:15, Brian Haley via discuss wrote:
Hi,
I recently have been seeing issues in a large environment where the
listen backlog of ovsdb-server, both NB and SB, is getting over-flowed,
for example:
17842 times the listen queue of a socket
Hi Ihar,
On 4/3/24 4:37 PM, Ihar Hrachyshka wrote:
On Wed, Apr 3, 2024 at 4:15 PM Brian Haley via discuss
mailto:ovs-discuss@openvswitch.org>> wrote:
Hi,
I recently have been seeing issues in a large environment where the
listen backlog of ovsdb-server, both NB and SB, is g
Hi,
I recently have been seeing issues in a large environment where the
listen backlog of ovsdb-server, both NB and SB, is getting over-flowed,
for example:
17842 times the listen queue of a socket overflowed
17842 SYNs to LISTEN sockets dropped
There is more on NB than SB, but I was
Hi,
On 3/21/24 6:09 AM, Simon Horman wrote:
Recently OVS adopted a policy of using the inclusive naming word list v1
[1, 2].
In keeping with this policy rename the primary development branch from
'master' to 'main'. This patch does not actually make that change,
but rather updates references
Hi,
On 3/16/24 6:07 AM, Geert Stappers wrote:
On Sat, Mar 02, 2024 at 05:03:01PM +0100, Geert Stappers wrote:
On Fri, Mar 01, 2024 at 04:43:20PM -0500, Brian Haley wrote:
When a new IPv6 address is being added to a dhcp_config
struct, if there is anything invalid regarding the prefix
it looks
Hi,
On 3/17/24 9:38 AM, Geert Stappers wrote:
From: Brian Haley
When a new IPv6 address is being added to a dhcp_config
struct, if there is anything invalid regarding the prefix
it looks like there is a potential memory leak.
ret_err_free() should be used to free it.
Signed-off-by: Brian
I am going to close this as it's been a number of years and the original
patch was abandoned. If someone wants to pick it up please re-open.
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
This seems to be complete, will close bug. Please re-open if I'm wrong.
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
>From all the changes that have merged this seems to be complete, will
close.
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
>From comment in the change that was linked above:
"BakedQuery is a legacy extension that no longer does too much beyond
what SQLAlchemy 1.4 does in most cases automatically. new development w/
BakedQuery is a non-starter, this is a legacy module we would eventually
remove."
For that reason I'm
As this has never been worked on am going to close. If anyone wants to
pick it up please re-open.
** Changed in: neutron
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
The documents have been updated many times over the past 6+ years, I'm
going to close this as they are much better now. If there is something
specific please open a new bug.
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member
Seems this fix is released, will close.
** Changed in: neutron
Status: In Progress => 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/1666779
Title:
Expose neutron
>From the review it seems as the decision was to not do this, so I will
close this bug.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Going to mark invalid for Neutron as it seems like an oslo.config bug.
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1898015
I am going to close this as it has been un-assigned for almost 3 years
and the change abandoned. If you wish to work on it please re-open.
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Looking at some recent logs these values seem Ok now, so will close
this. If we see the issue again can open a new bug.
** Changed in: neutron
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
I think I figured out the issue here, so will close this.
Here's my thinking.
The referenced log above was from a change on stable/train:
https://review.opendev.org/c/openstack/neutron/+/730888
Lajos fixed a bug in _find_available_ips that seems related:
I am inclined to leave this as-is since there are other resources that
follow the same pattern, and either the maintenance task will fix it,
otherwise when it's associated to a port.
Thanks for the bug Flavio :)
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug
I am going to close this since moving to the OVS firewall driver has
helped, and I'm not sure anyone will take the time to investigate
further as OVN is now the default driver. Someone can re-open if they
intend on working on it.
** Changed in: neutron
Status: Triaged => Won't Fix
--
You
I am going to close this as fwaas-v1 has been deprecated. Please open a
new bug if this also affects fwaas-v2. Thanks.
** Changed in: neutron
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
I have tested neutron version 2:16.4.2-0ubuntu6.4~cloud0 from the cloud-
archive:ussuri-proposed repository and can verify the code has this
change, and the failure does not occur. I followed the steps from the
bug description:
Created two security group rules, one for 10.0.0.1/8 and the other
I have tested neutron version 2:16.4.2-0ubuntu6.4~cloud0 from the cloud-
archive:ussuri-proposed repository and can verify the code has this
change, and the failure does not occur. I followed the steps from
Comment #3:
openstack network create test_ap1_net
openstack network create test_ap2_net
I have tested neutron version 2:16.4.2-0ubuntu6.4~cloud0 from the cloud-
archive:ussuri-proposed repository and can verify the code has this
change, and the failure does not occur. I followed the steps from the
bug description:
neutron-ovn-db-sync-util --config-file /etc/neutron/neutron.conf
I have tested neutron version 2:16.4.2-0ubuntu6.4~cloud0 from the cloud-
archive:ussuri-proposed repository and can verify the code has this
change, and the failure does not occur. I followed the steps from the
bug description:
openstack port create --network --binding-profile
trusted=true
I have tested neutron version 2:16.4.2-0ubuntu6.4~cloud0 from the cloud-
archive:ussuri-proposed repository and can verify the code has this
change, and the failure does not occur. I followed the steps from the
bug description:
Quick way to reproduce on ML2/OVN:
- openstack project create
Can you paste the change you're using that seems to help? Maybe getting
some eyes on it might help point in a direction? Not that I have lots of
extra cycles.
And I didn't expect the change I made to help, that failure probably
never happens, and if you're just dealing with IPv4 it won't come
Can you paste the change you're using that seems to help? Maybe getting
some eyes on it might help point in a direction? Not that I have lots of
extra cycles.
And I didn't expect the change I made to help, that failure probably
never happens, and if you're just dealing with IPv4 it won't come
Just adding issue Rodolfo raised with the OVN team at Red Hat:
https://issues.redhat.com/browse/FDP-448
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2051935
Title:
[OVN] SNAT only happens for
Patches merged, will close.
** Changed in: neutron
Status: In Progress => 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/2025056
Title:
Router ports without IP
Seems fixed, closing.
** Changed in: neutron
Status: Confirmed => 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/1999154
Title:
ovs/ovn source deployment broken
Change merged, will close this.
** Changed in: neutron
Status: In Progress => 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/2008912
Title:
Patches have merged, will close.
** Changed in: neutron
Status: In Progress => 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/2022914
Title:
[neutron-api] remove
Seems to have been fixed with
https://review.opendev.org/c/openstack/neutron/+/820911 will close this
bug.
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
I am going to close this as it is over 6 years old and no one has
stepped forward to fix it, so it's just not a priority. Please re-open
if necessary.
** Changed in: neutron
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
** Changed in: neutron
Assignee: Adil Ishaq (iradvisor) => (unassigned)
** Changed in: identity-management
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
** Also affects: neutron (Ubuntu)
Importance: Undecided
Status: New
** Also affects: neutron (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: neutron (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: neutron (Ubuntu Jammy)
** Also affects: neutron (Ubuntu)
Importance: Undecided
Status: New
** Also affects: neutron (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: neutron (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: neutron (Ubuntu Jammy)
>From that trace, it looks like it is in this code in dhcp_config_free()
when it makes the free() call:
#ifdef HAVE_DHCP6
if (config->flags & CONFIG_ADDR6)
{
struct addrlist *addr, *tmp;
for (addr = config->addr6; addr; addr = tmp)
{
From that trace, it looks like it is in this code in dhcp_config_free()
when it makes the free() call:
#ifdef HAVE_DHCP6
if (config->flags & CONFIG_ADDR6)
{
struct addrlist *addr, *tmp;
for (addr = config->addr6; addr; addr = tmp)
{
tmp
** Also affects: cloud-archive
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/1973347
Title:
OVN revision_number infinite update loop
Status
So just some additional information.
The reporter confirmed their cloud is running HA routers, but not DVR.
And talking with Rodolfo on irc reminded me of a proposed change that I
finally found:
https://review.opendev.org/c/openstack/neutron/+/890459
And the bug for that is:
Neutron started using network:distributed for both DHCP and metadata
ports in Victoria [0]
Looking at the change proposed, Nova only ever looks for ports with
network:dhcp in the device_owner field, it also needs to do a lookup of
ports with network:distributed in this field. Unfortunately they
Ok, as I was asked about the case of 3 nested routers (i.e. a network on
a private subnet behind 3 total routers, 2 nested on their own private
networks), I've tested that as well. Same results - shows a clear
regression from ML2/OVS to OVN.
Again, I used devstack, this was the latest commit in
These are the settings I used for my ml2/ovs devstack:
Q_AGENT=openvswitch
Q_ML2_PLUGIN_MECHANISM_DRIVERS=openvswitch
Q_ML2_TENANT_NETWORK_TYPE=vxlan
enable_service q-agt
enable_service q-l3
enable_service q-dhcp
enable_service q-meta
disable_service ovn-controller
disable_service ovn-northd
Could not reproduce, marking invalid.
** Changed in: neutron
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1867214
Title:
MTU too large error
Looks like this was fixed, will close.
** Changed in: neutron
Status: In Progress => 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/1865223
Title:
[scale issue]
I'm going to close this as the logs to know what the exact error was are
long gone. If it happens again we can open a new bug.
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
I'm goint to close this as Stein has been EOL for quite a while. If this
is happening on a newer, supported release please open a new bug.
** Changed in: neutron
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Looks like this was fixed in commit
748dd8df737d28aad7dfd0a1e32659e0256126e2 in the tempest tree, will
close.
** Changed in: neutron
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Looks like this code was changed for Sqlalchemy 2.0 in
d7ba5948ffe4ff4ec760a2774c699774b065cdfb as from_engine() is deprecated,
will close this bug.
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering
As this was not a neutron bug and the tobiko patch has merged will close
this bug.
** Changed in: neutron
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
** Changed in: neutron
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2042941
Title:
neutron-{ovn,ovs}-tempest-with-sqlalchemy-master jobs not
The comment on a failure in Zed looked to not have the fix - version
21.1.2, version 21.2.0 or greater is required. Will close this as the
fixes have been released.
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member
** Changed in: python-openstackclient
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/1742187
Title:
osc client missing extra-dhcp-opts option
Status
Since this has been fixed in later Ussuri and/or later neutron code I'm
going to close this. Please re-open if necessary.
** Changed in: neutron
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Public bug reported:
Running 'tox -e pep8' in neutron-lib or neutron repo generates this new
warning:
/home/bhaley/git/neutron-lib/neutron_lib/db/model_base.py:113:
MovedIn20Warning: Deprecated API features detected! These feature(s) are not
compatible with SQLAlchemy 2.0. To prevent
*** This bug is a duplicate of bug 2038541 ***
https://bugs.launchpad.net/bugs/2038541
This was fixed with
https://review.opendev.org/c/openstack/neutron/+/898832 and is a
duplicate of https://bugs.launchpad.net/neutron/+bug/2038541 - please
try the fix there.
** This bug has been marked a
subnet_dhcp_options
ERROR neutron_ovn_db_sync_util network =
db_networks[utils.ovn_name(subnet['network_id'])]
ERROR neutron_ovn_db_sync_util KeyError:
'neutron-93ad1c21-d2cf-448a-8fae-21c71f44dc5c'
** Affects: neutron
Importance: Medium
Assignee: Brian Haley (brian-haley)
https://docs.openstack.org/api-ref/network/v2/#port-binding shows these
api's are now present, closing bug.
** Changed in: neutron
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
** Changed in: neutron
Status: In Progress => 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/1779335
Title:
neutron-vpnaas doesn't support local tox targets
Status
** Changed in: neutron
Status: In Progress => 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/2024205
Title:
[OVN] Hash Ring nodes removed when "periodic worker" is
Since the skip-level job is now passing and voting in our gate I am
going to close this bug.
** Changed in: neutron
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
Since the patch on master was abandoned manually I am going to close
this.
** Changed in: neutron
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
I am going to mark this as won't fix as the linuxbridge agent is
unmaintained and experimental on the master branch.
** Changed in: neutron
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
** Changed in: neutron
Status: In Progress => 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/2028003
Title:
neutron fails with postgres on subnet_id
Status in
** Changed in: neutron
Status: Expired => Triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1975828
Title:
difference in execution time between admin/non-admin call
Status
;From looking at the functional tests and Nova code, should be a
straightforward fix.
We should also look at creating a test job that both tests sqlalchemy
2.0 and neutron-lib main/master branches so we don't regress.
** Affects: neutron
Importance: High
Assignee: Brian Haley
Moving this to the neutron project as networking-ovn has been retired
for a while.
My first question is are you able to test this with a later release?
Since it's been 10 months since it was filed just want to make sure it
hasn't been fixed.
** Project changed: networking-ovn => neutron
** Tags
Public bug reported:
Running the segment unit tests -
neutron/tests/unit/extensions/test_segment.py generates a lot of extra
noise, like:
{0}
neutron.tests.unit.extensions.test_segment.TestNovaSegmentNotifier.test_delete_network_and_owned_segments
[1.185650s] ... ok
Captured stderr:
** Changed in: neutron
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2037500
Title:
OVSDB transaction returned TRY_AGAIN, retrying do_commit
Public bug reported:
A number of different scenario tests seem to be failing randomly in the
same way:
Details: Router 01dda41e-67ed-4af0-ac56-72fd895cef9a is not active on
any of the L3 agents
One example is in
https://review.opendev.org/c/openstack/neutron/+/895832 where these
three jobs are
Hi Brain (?),
On 9/20/23 1:56 AM, Ales Musil via discuss wrote:
On Tue, Sep 19, 2023 at 9:02 PM Brain Empty via discuss
mailto:ovs-discuss@openvswitch.org>> wrote:
Hi, I got stuck into a problem. maybe there is something wrong with
ovs|ovn acl.
If I enable the port security
Hi Ales,
On 9/15/23 8:15 AM, Ales Musil wrote:
When client sends RS we reply with RA to the source address,
however the client is allowed to send RS with unspecified
source address ("::"). In that case we would send the RA to
that empty address which is not correct.
According to RFC 2461 [0]
So this also fails with version 2.89 that is in Lunar?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/2026757
Title:
dnsmasq on Ubuntu Jammy/Lunar crashes on
*** This bug is a duplicate of bug 1975743 ***
https://bugs.launchpad.net/bugs/1975743
** This bug has been marked a duplicate of bug 1975743
ML2 OVN - Creating an instance with hardware offloaded port is broken
--
You received this bug notification because you are a member of Yahoo!
is making the request, but it
could be logged for posterity.
I'll send a change for that soon.
** Affects: neutron
Importance: Medium
Assignee: Brian Haley (brian-haley)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering T
** Changed in: neutron
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2025264
Title:
[ovn][DVR]FIP traffic centralized in DVR environments
On 6/8/23 3:52 PM, Paolo Valerio wrote:
Brian Haley writes:
Hi Paolo,
On 4/19/23 2:40 PM, Paolo Valerio wrote:
During the creation of a new connection, there's a chance both key and
rev_key end up having the same hash. This is more common in the case
of all-zero snat with no collisions
Hi Paolo,
On 4/19/23 2:40 PM, Paolo Valerio wrote:
During the creation of a new connection, there's a chance both key and
rev_key end up having the same hash. This is more common in the case
of all-zero snat with no collisions. In that case, once the
connection is expired, but not cleaned up,
/issues/192
Reported-by: Nicolas Bock
Signed-off-by: Brian Haley
---
Changes since v3:
- Updated commit message to include reporter info
---
Changes since v2:
- Updated commit message to be more clear
---
Changes since v1:
- Added issue #192 to commit message
---
controller/pinctrl.c | 7 +++
1
:
On Thu, May 25, 2023 at 8:29 PM Brian Haley <mailto:haleyb@gmail.com>> wrote:
DNS queries with optional records (RRs), for example, with
cookies for EDNS, are not supported by the OVN resolver.
Trying to reply will result in mangled responses that
clients do not u
, which
will trigger a negative response and cause clients to
go to the upstream forwarder, hopefully resulting in a
successful query.
In our testing, the resolver only retries if the
response is correctly formatted, which now happens
with this change.
Closes issue #192
Signed-off-by: Brian Haley
.
Thanks,
-Brian
[0]
https://patchwork.ozlabs.org/project/ovn/patch/2023052223.363328-1-haleyb@gmail.com/
On 5/22/23 4:13 PM, Brian Haley wrote:
DNS queries with optional records (RRs), for example, with
cookies for EDNS, are not supported by the OVN resolver.
Trying to reply
/+/883991
I realize there are changes in-flight wrt to sRBAC which might fix the
issue, but until they all merge I think we should just make it non-
voting on the master branch. The other branches don't seem to have any
problems.
** Affects: neutron
Importance: High
Assignee: Brian Haley
and cause clients to
go to the upstream forwarder, hopefully resulting in a
successful query.
Closes issue #192
Signed-off-by: Brian Haley
---
Changes since v1:
- Added issue #192 to commit message
---
controller/pinctrl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/controller/pinctrl.c
and cause clients to
go to the upstream forwarder, hopefully resulting in a
successful query.
Signed-off-by: Brian Haley
---
controller/pinctrl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index b5df8b1eb..b45b4c747 100644
--- a/controller
Added neutron since I don't think this is specific to charms.
** Also affects: neutron
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/1993628
Hi Frode,
Thanks for fixing this, just had one nit below since you're pushing out
a new PS.
On 5/10/23 11:12 AM, Frode Nordahl wrote:
The tc module combines the use of the `tc_transact` helper
function for communication with the in-kernel tc infrastructure
with assertions on the reply data
The patch would not have fixed the issue, just added some logging so it
was obvious what the agent was doing.
And yes, syncing time is important, it could have just been the time
difference on the agents and server causing things to seem broken. Glad
you solved your issue.
** Changed in: neutron
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: neutron
Assignee: (unassigned) => Brian Haley (brian-haley)
** Changed in: neutron
Importance: Undecided => Medium
** Tags added: ovn
--
You received this bug notification because you are a
d an error since there was a subnet here,
will have to re-check the API ref to see.
During one attempt I actually triggered a SubnetNotFound error, but
that's probably a different issue as it wasn't necessary to recreate
this.
** Affects: neutron
Importance: Medium
Assignee: Brian Ha
1 - 100 of 909 matches
Mail list logo
