Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 1985820

Summary:	[RFE] OVSDB Relay: Support database 'index' for clients
Product:	Red Hat Enterprise Linux Fast Datapath	Reporter:	Ilya Maximets <i.maximets>
Component:	ovsdb2.15	Assignee:	OVS RFE <ovs-rfe>
Status:	CLOSED EOL	QA Contact:	ovs-qe
Severity:	low	Docs Contact:
Priority:	low
Version:	RHEL 8.0	CC:	ctrautma, ekuris, jhsiao, mmichels, ralongi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-10-08 17:49:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ilya Maximets 2021-07-26 00:25:29 UTC

Clustered database server reports an 'index' value, which is the
index of the last database update on this server.  This value is
used by clients to detect and disconnect from servers with stale
data (i.e. if they were previously connected to a server with higher
index).  OVSDB Relay may proxy this information from the relay source
to the relay's _Server database, so the clients may detect relays with
stale data.

This mechanism has drawbacks though.  If the cluster is re-started
from scratch, clients might loop over all servers and think that
all of them has stale data.  This is a generic problem that should
be addressed separately (there is another BZ 1972270 for that).

Comment 1 Eelco Chaudron 2022-04-19 14:33:25 UTC

It's not really clear from the Description what is required to be done as part of this BZ. Can you please clarify it more?

Comment 2 Ilya Maximets 2024-01-24 14:46:52 UTC

The _Server database contains an 'index' column for each database the
server serves.  This column contains the ever-growing number that is
essentially a sequence number for all te database changes.

In case of clustered databases, when client re-connects from one cluster
member to another, they check the 'index'.  And if the value is lower
than the value this client seen before, it means that server we re-connected
too has older data, so updates from this server should not be applied,
so the client ultimately re-connects again to a different server looking
for one with the 'index' the same or more recent to what it seen before.

This is a protection from connecting to a server with a stale data
and breaking the local cache on a client side.

Now we have relays that connect to the cluster, and clients connect
to relays.  Relay servers do not provide the database 'index' to the
clients.  So, if this relay is connected to a cluster member with a
stale data, the client will not know that.  This may cause the breakage
of the local cache on the client if it re-connects to a different
relay that relays the data from a stale cluster member.

This task is to relay the 'index' from a _Server database of the relay
source to the _Server database of the relay itself, so it is visible to
the end client.

Comment 3 ovs-bot 2024-10-08 17:49:14 UTC

This bug did not meet the criteria for automatic migration and is being closed.
If the issue remains, please open a new ticket in https://issues.redhat.com/browse/FDP