2017-04-27 13:54:53 -07:00
|
|
|
|
/* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 Nicira, Inc.
|
2017-08-03 14:20:15 -04:00
|
|
|
|
* Copyright (C) 2016 Hewlett Packard Enterprise Development LP
|
2009-12-02 11:26:15 -08:00
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at:
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
|
|
#include "ovsdb-idl.h"
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
#include <errno.h>
|
2009-12-16 16:26:17 -08:00
|
|
|
|
#include <inttypes.h>
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include <limits.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
#include "bitmap.h"
|
2014-05-29 23:44:37 -07:00
|
|
|
|
#include "coverage.h"
|
2016-12-19 20:55:35 -08:00
|
|
|
|
#include "hash.h"
|
2016-03-03 10:20:46 -08:00
|
|
|
|
#include "openvswitch/dynamic-string.h"
|
2010-04-13 09:28:13 -07:00
|
|
|
|
#include "fatal-signal.h"
|
2016-07-12 16:37:34 -05:00
|
|
|
|
#include "openvswitch/json.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include "jsonrpc.h"
|
2015-03-19 23:45:42 -07:00
|
|
|
|
#include "ovsdb/ovsdb.h"
|
|
|
|
|
#include "ovsdb/table.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include "ovsdb-data.h"
|
|
|
|
|
#include "ovsdb-error.h"
|
|
|
|
|
#include "ovsdb-idl-provider.h"
|
2015-03-19 23:45:42 -07:00
|
|
|
|
#include "ovsdb-parser.h"
|
2017-12-31 21:15:58 -08:00
|
|
|
|
#include "ovsdb-server-idl.h"
|
|
|
|
|
#include "ovsdb-session.h"
|
2017-11-03 13:53:53 +08:00
|
|
|
|
#include "openvswitch/poll-loop.h"
|
2016-07-12 16:37:34 -05:00
|
|
|
|
#include "openvswitch/shash.h"
|
2017-08-03 14:20:15 -04:00
|
|
|
|
#include "skiplist.h"
|
2015-03-19 23:45:42 -07:00
|
|
|
|
#include "sset.h"
|
2017-12-31 21:15:58 -08:00
|
|
|
|
#include "svec.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
#include "util.h"
|
2017-08-03 14:20:15 -04:00
|
|
|
|
#include "uuid.h"
|
2014-12-15 14:10:38 +01:00
|
|
|
|
#include "openvswitch/vlog.h"
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-10-19 14:47:01 -07:00
|
|
|
|
VLOG_DEFINE_THIS_MODULE(ovsdb_idl);
|
2010-07-16 11:02:49 -07:00
|
|
|
|
|
2014-05-29 23:44:37 -07:00
|
|
|
|
COVERAGE_DEFINE(txn_uncommitted);
|
|
|
|
|
COVERAGE_DEFINE(txn_unchanged);
|
|
|
|
|
COVERAGE_DEFINE(txn_incomplete);
|
|
|
|
|
COVERAGE_DEFINE(txn_aborted);
|
|
|
|
|
COVERAGE_DEFINE(txn_success);
|
|
|
|
|
COVERAGE_DEFINE(txn_try_again);
|
|
|
|
|
COVERAGE_DEFINE(txn_not_locked);
|
|
|
|
|
COVERAGE_DEFINE(txn_error);
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
/* An arc from one idl_row to another. When row A contains a UUID that
|
|
|
|
|
* references row B, this is represented by an arc from A (the source) to B
|
|
|
|
|
* (the destination).
|
|
|
|
|
*
|
|
|
|
|
* Arcs from a row to itself are omitted, that is, src and dst are always
|
|
|
|
|
* different.
|
|
|
|
|
*
|
|
|
|
|
* Arcs are never duplicated, that is, even if there are multiple references
|
|
|
|
|
* from A to B, there is only a single arc from A to B.
|
|
|
|
|
*
|
|
|
|
|
* Arcs are directed: an arc from A to B is the converse of an an arc from B to
|
|
|
|
|
* A. Both an arc and its converse may both be present, if each row refers
|
|
|
|
|
* to the other circularly.
|
|
|
|
|
*
|
|
|
|
|
* The source and destination row may be in the same table or in different
|
|
|
|
|
* tables.
|
|
|
|
|
*/
|
|
|
|
|
struct ovsdb_idl_arc {
|
2014-12-15 14:10:38 +01:00
|
|
|
|
struct ovs_list src_node; /* In src->src_arcs list. */
|
|
|
|
|
struct ovs_list dst_node; /* In dst->dst_arcs list. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *src; /* Source row. */
|
|
|
|
|
struct ovsdb_idl_row *dst; /* Destination row. */
|
|
|
|
|
};
|
|
|
|
|
|
2017-12-11 14:30:33 -08:00
|
|
|
|
/* Connection state machine.
|
|
|
|
|
*
|
2017-12-31 21:15:58 -08:00
|
|
|
|
* When a JSON-RPC session connects, the IDL sends a "monitor_cond" request for
|
|
|
|
|
* the Database table in the _Server database and transitions to the
|
|
|
|
|
* IDL_S_SERVER_MONITOR_COND_REQUESTED state. If the session drops and
|
|
|
|
|
* reconnects, or if the IDL receives a "monitor_canceled" notification for a
|
|
|
|
|
* table it is monitoring, the IDL starts over again in the same way. */
|
|
|
|
|
#define OVSDB_IDL_STATES \
|
|
|
|
|
/* Waits for "get_schema" reply, then sends "monitor_cond" \
|
|
|
|
|
* request for the Database table in the _Server database, whose \
|
|
|
|
|
* details are informed by the schema, and transitions to \
|
|
|
|
|
* IDL_S_SERVER_MONITOR_COND_REQUESTED. */ \
|
|
|
|
|
OVSDB_IDL_STATE(SERVER_SCHEMA_REQUESTED) \
|
|
|
|
|
\
|
|
|
|
|
/* Waits for "monitor_cond" reply for the Database table: \
|
|
|
|
|
* \
|
|
|
|
|
* - If the reply indicates success, and the Database table has a \
|
|
|
|
|
* row for the IDL database: \
|
|
|
|
|
* \
|
|
|
|
|
* * If the row indicates that this is a clustered database \
|
|
|
|
|
* that is not connected to the cluster, closes the \
|
|
|
|
|
* connection. The next connection attempt has a chance at \
|
|
|
|
|
* picking a connected server. \
|
|
|
|
|
* \
|
2019-02-28 09:15:19 -08:00
|
|
|
|
* * Otherwise, sends a "monitor_cond_since" request for the IDL \
|
2017-12-31 21:15:58 -08:00
|
|
|
|
* database whose details are informed by the schema \
|
|
|
|
|
* (obtained from the row), and transitions to \
|
2019-02-28 09:15:19 -08:00
|
|
|
|
* IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED. \
|
2017-12-31 21:15:58 -08:00
|
|
|
|
* \
|
|
|
|
|
* - If the reply indicates success, but the Database table does \
|
|
|
|
|
* not have a row for the IDL database, transitions to \
|
|
|
|
|
* IDL_S_ERROR. \
|
|
|
|
|
* \
|
|
|
|
|
* - If the reply indicates failure, sends a "get_schema" request \
|
|
|
|
|
* for the IDL database and transitions to \
|
|
|
|
|
* IDL_S_DATA_SCHEMA_REQUESTED. */ \
|
|
|
|
|
OVSDB_IDL_STATE(SERVER_MONITOR_COND_REQUESTED) \
|
|
|
|
|
\
|
|
|
|
|
/* Waits for "get_schema" reply, then sends "monitor_cond" \
|
|
|
|
|
* request whose details are informed by the schema, and \
|
|
|
|
|
* transitions to IDL_S_DATA_MONITOR_COND_REQUESTED. */ \
|
|
|
|
|
OVSDB_IDL_STATE(DATA_SCHEMA_REQUESTED) \
|
|
|
|
|
\
|
2019-02-28 09:15:19 -08:00
|
|
|
|
/* Waits for "monitor_cond_since" reply. If successful, replaces \
|
|
|
|
|
* the IDL contents by the data carried in the reply and \
|
|
|
|
|
* transitions to IDL_S_MONITORING. On failure, sends a \
|
|
|
|
|
* "monitor_cond" request and transitions to \
|
|
|
|
|
* IDL_S_DATA_MONITOR_COND_REQUESTED. */ \
|
|
|
|
|
OVSDB_IDL_STATE(DATA_MONITOR_COND_SINCE_REQUESTED) \
|
|
|
|
|
\
|
2017-12-31 21:15:58 -08:00
|
|
|
|
/* Waits for "monitor_cond" reply. If successful, replaces the \
|
|
|
|
|
* IDL contents by the data carried in the reply and transitions \
|
|
|
|
|
* to IDL_S_MONITORING. On failure, sends a "monitor" request \
|
|
|
|
|
* and transitions to IDL_S_DATA_MONITOR_REQUESTED. */ \
|
|
|
|
|
OVSDB_IDL_STATE(DATA_MONITOR_COND_REQUESTED) \
|
|
|
|
|
\
|
|
|
|
|
/* Waits for "monitor" reply. If successful, replaces the IDL \
|
|
|
|
|
* contents by the data carried in the reply and transitions to \
|
|
|
|
|
* IDL_S_MONITORING. On failure, transitions to IDL_S_ERROR. */ \
|
|
|
|
|
OVSDB_IDL_STATE(DATA_MONITOR_REQUESTED) \
|
|
|
|
|
\
|
2019-02-28 09:15:19 -08:00
|
|
|
|
/* State that processes "update", "update2" or "update3" \
|
|
|
|
|
* notifications for the main database (and the Database table \
|
|
|
|
|
* in _Server if available). \
|
2017-12-31 21:15:58 -08:00
|
|
|
|
* \
|
|
|
|
|
* If we're monitoring the Database table and we get notified \
|
|
|
|
|
* that the IDL database has been deleted, we close the \
|
|
|
|
|
* connection (which will restart the state machine). */ \
|
|
|
|
|
OVSDB_IDL_STATE(MONITORING) \
|
|
|
|
|
\
|
|
|
|
|
/* Terminal error state that indicates that nothing useful can be \
|
|
|
|
|
* done, for example because the database server doesn't actually \
|
|
|
|
|
* have the desired database. We maintain the session with the \
|
|
|
|
|
* database server anyway. If it starts serving the database \
|
|
|
|
|
* that we want, or if someone fixes and restarts the database, \
|
|
|
|
|
* then it will kill the session and we will automatically \
|
|
|
|
|
* reconnect and try again. */ \
|
|
|
|
|
OVSDB_IDL_STATE(ERROR) \
|
|
|
|
|
\
|
|
|
|
|
/* Terminal state that indicates we connected to a useless server \
|
|
|
|
|
* in a cluster, e.g. one that is partitioned from the rest of \
|
|
|
|
|
* the cluster. We're waiting to retry. */ \
|
|
|
|
|
OVSDB_IDL_STATE(RETRY)
|
|
|
|
|
|
2015-03-19 23:45:42 -07:00
|
|
|
|
enum ovsdb_idl_state {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
#define OVSDB_IDL_STATE(NAME) IDL_S_##NAME,
|
|
|
|
|
OVSDB_IDL_STATES
|
|
|
|
|
#undef OVSDB_IDL_STATE
|
|
|
|
|
};
|
2017-12-11 14:30:33 -08:00
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static const char *ovsdb_idl_state_to_string(enum ovsdb_idl_state);
|
|
|
|
|
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method {
|
|
|
|
|
OVSDB_IDL_MM_MONITOR,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND_SINCE
|
|
|
|
|
};
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
enum ovsdb_idl_monitoring {
|
|
|
|
|
OVSDB_IDL_NOT_MONITORING, /* Database is not being monitored. */
|
|
|
|
|
OVSDB_IDL_MONITORING, /* Database has "monitor" outstanding. */
|
|
|
|
|
OVSDB_IDL_MONITORING_COND, /* Database has "monitor_cond" outstanding. */
|
2019-02-28 09:15:19 -08:00
|
|
|
|
OVSDB_IDL_MONITORING_COND_SINCE, /* Database has "monitor_cond_since"
|
|
|
|
|
outstanding. */
|
2015-03-19 23:45:42 -07:00
|
|
|
|
};
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_db {
|
|
|
|
|
struct ovsdb_idl *idl;
|
|
|
|
|
|
2017-12-11 14:30:33 -08:00
|
|
|
|
/* Data. */
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_class *class_;
|
2016-08-28 23:21:40 -07:00
|
|
|
|
struct shash table_by_name; /* Contains "struct ovsdb_idl_table *"s.*/
|
2017-08-11 11:06:44 -07:00
|
|
|
|
struct ovsdb_idl_table *tables; /* Array of ->class_->n_tables elements. */
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct json *monitor_id;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
unsigned int change_seqno;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
struct hmap outstanding_txns;
|
|
|
|
|
bool verify_write_only;
|
|
|
|
|
struct json *schema;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
enum ovsdb_idl_monitoring monitoring;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
|
|
|
|
|
/* True if any of the tables' monitoring conditions has changed. */
|
|
|
|
|
bool cond_changed;
|
|
|
|
|
|
|
|
|
|
unsigned int cond_seqno; /* Keep track of condition clauses changes
|
|
|
|
|
over a single conditional monitoring session.
|
|
|
|
|
Reverts to zero when idl session
|
|
|
|
|
reconnects. */
|
|
|
|
|
|
|
|
|
|
/* Database locking. */
|
|
|
|
|
char *lock_name; /* Name of lock we need, NULL if none. */
|
|
|
|
|
bool has_lock; /* Has db server told us we have the lock? */
|
|
|
|
|
bool is_lock_contended; /* Has db server told us we can't get lock? */
|
|
|
|
|
struct json *lock_request_id; /* JSON-RPC ID of in-flight lock request. */
|
2019-02-28 09:15:20 -08:00
|
|
|
|
|
|
|
|
|
/* Last db txn id, used for fast resync through monitor_cond_since */
|
|
|
|
|
struct uuid last_id;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_db_track_clear(struct ovsdb_idl_db *);
|
|
|
|
|
static void ovsdb_idl_db_add_column(struct ovsdb_idl_db *,
|
|
|
|
|
const struct ovsdb_idl_column *);
|
|
|
|
|
static void ovsdb_idl_db_omit(struct ovsdb_idl_db *,
|
|
|
|
|
const struct ovsdb_idl_column *);
|
|
|
|
|
static void ovsdb_idl_db_omit_alert(struct ovsdb_idl_db *,
|
|
|
|
|
const struct ovsdb_idl_column *);
|
|
|
|
|
static unsigned int ovsdb_idl_db_set_condition(
|
|
|
|
|
struct ovsdb_idl_db *, const struct ovsdb_idl_table_class *,
|
|
|
|
|
const struct ovsdb_idl_condition *);
|
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_send_schema_request(struct ovsdb_idl *,
|
|
|
|
|
struct ovsdb_idl_db *);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static void ovsdb_idl_send_db_change_aware(struct ovsdb_idl *);
|
|
|
|
|
static bool ovsdb_idl_check_server_db(struct ovsdb_idl *);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void ovsdb_idl_send_monitor_request(struct ovsdb_idl *,
|
|
|
|
|
struct ovsdb_idl_db *,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method);
|
2019-07-01 12:24:38 +02:00
|
|
|
|
static void ovsdb_idl_db_clear(struct ovsdb_idl_db *db);
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
static void ovsdb_idl_db_ack_condition(struct ovsdb_idl_db *db);
|
|
|
|
|
static void ovsdb_idl_db_sync_condition(struct ovsdb_idl_db *db);
|
|
|
|
|
static void ovsdb_idl_condition_move(struct ovsdb_idl_condition **dst,
|
|
|
|
|
struct ovsdb_idl_condition **src);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
|
|
|
|
|
struct ovsdb_idl {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
struct ovsdb_idl_db server;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_db data;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-12-11 14:30:33 -08:00
|
|
|
|
/* Session state.
|
|
|
|
|
*
|
|
|
|
|
*'state_seqno' is a snapshot of the session's sequence number as returned
|
|
|
|
|
* jsonrpc_session_get_seqno(session), so if it differs from the value that
|
|
|
|
|
* function currently returns then the session has reconnected and the
|
|
|
|
|
* state machine must restart. */
|
|
|
|
|
struct jsonrpc_session *session; /* Connection to the server. */
|
2018-06-18 11:36:49 -07:00
|
|
|
|
char *remote; /* 'session' remote name. */
|
2017-12-11 14:30:33 -08:00
|
|
|
|
enum ovsdb_idl_state state; /* Current session state. */
|
|
|
|
|
unsigned int state_seqno; /* See above. */
|
|
|
|
|
struct json *request_id; /* JSON ID for request awaiting reply. */
|
2016-12-19 23:55:01 -08:00
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
struct uuid cid;
|
|
|
|
|
|
|
|
|
|
uint64_t min_index;
|
|
|
|
|
bool leader_only;
|
2019-04-12 16:26:24 -07:00
|
|
|
|
bool shuffle_remotes;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
};
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static void ovsdb_idl_transition_at(struct ovsdb_idl *, enum ovsdb_idl_state,
|
|
|
|
|
const char *where);
|
|
|
|
|
#define ovsdb_idl_transition(IDL, STATE) \
|
|
|
|
|
ovsdb_idl_transition_at(IDL, STATE, OVS_SOURCE_LOCATOR)
|
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_retry_at(struct ovsdb_idl *, const char *where);
|
|
|
|
|
#define ovsdb_idl_retry(IDL) ovsdb_idl_retry_at(IDL, OVS_SOURCE_LOCATOR)
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct ovsdb_idl_txn {
|
|
|
|
|
struct hmap_node hmap_node;
|
|
|
|
|
struct json *request_id;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_db *db;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct hmap txn_rows;
|
|
|
|
|
enum ovsdb_idl_txn_status status;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
char *error;
|
2009-12-11 11:28:36 -08:00
|
|
|
|
bool dry_run;
|
2009-12-16 13:30:53 -08:00
|
|
|
|
struct ds comment;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
|
|
|
|
|
/* Increments. */
|
2012-04-12 08:25:10 -07:00
|
|
|
|
const char *inc_table;
|
|
|
|
|
const char *inc_column;
|
|
|
|
|
struct uuid inc_row;
|
2016-08-07 20:44:51 -07:00
|
|
|
|
bool inc_force;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
unsigned int inc_index;
|
|
|
|
|
int64_t inc_new_value;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
|
|
|
|
|
/* Inserted rows. */
|
2011-09-15 12:53:12 -07:00
|
|
|
|
struct hmap inserted_rows; /* Contains "struct ovsdb_idl_txn_insert"s. */
|
2010-01-28 13:23:30 -08:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_txn_insert {
|
|
|
|
|
struct hmap_node hmap_node; /* In struct ovsdb_idl_txn's inserted_rows. */
|
|
|
|
|
struct uuid dummy; /* Dummy UUID used locally. */
|
|
|
|
|
int op_index; /* Index into transaction's operation array. */
|
|
|
|
|
struct uuid real; /* Real UUID used by database server. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct vlog_rate_limit syntax_rl = VLOG_RATE_LIMIT_INIT(1, 5);
|
|
|
|
|
static struct vlog_rate_limit semantic_rl = VLOG_RATE_LIMIT_INIT(1, 5);
|
2017-05-31 19:04:32 -04:00
|
|
|
|
static struct vlog_rate_limit other_rl = VLOG_RATE_LIMIT_INIT(1, 5);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_clear(struct ovsdb_idl *);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void ovsdb_idl_db_parse_monitor_reply(struct ovsdb_idl_db *,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
const struct json *result,
|
|
|
|
|
enum ovsdb_idl_monitor_method method);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static bool ovsdb_idl_db_parse_update_rpc(struct ovsdb_idl_db *,
|
|
|
|
|
const struct jsonrpc_msg *);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static bool ovsdb_idl_handle_monitor_canceled(struct ovsdb_idl *,
|
|
|
|
|
struct ovsdb_idl_db *,
|
|
|
|
|
const struct jsonrpc_msg *);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void ovsdb_idl_db_parse_update(struct ovsdb_idl_db *,
|
|
|
|
|
const struct json *table_updates,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method method);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
static bool ovsdb_idl_process_update(struct ovsdb_idl_table *,
|
2009-12-02 11:26:15 -08:00
|
|
|
|
const struct uuid *,
|
|
|
|
|
const struct json *old,
|
|
|
|
|
const struct json *new);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
static bool ovsdb_idl_process_update2(struct ovsdb_idl_table *,
|
|
|
|
|
const struct uuid *,
|
|
|
|
|
const char *operation,
|
|
|
|
|
const struct json *row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void ovsdb_idl_insert_row(struct ovsdb_idl_row *, const struct json *);
|
|
|
|
|
static void ovsdb_idl_delete_row(struct ovsdb_idl_row *);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
static bool ovsdb_idl_modify_row(struct ovsdb_idl_row *, const struct json *);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
static bool ovsdb_idl_modify_row_by_diff(struct ovsdb_idl_row *,
|
|
|
|
|
const struct json *);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
static bool ovsdb_idl_row_is_orphan(const struct ovsdb_idl_row *);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct ovsdb_idl_row *ovsdb_idl_row_create__(
|
|
|
|
|
const struct ovsdb_idl_table_class *);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_idl_row *ovsdb_idl_row_create(struct ovsdb_idl_table *,
|
|
|
|
|
const struct uuid *);
|
|
|
|
|
static void ovsdb_idl_row_destroy(struct ovsdb_idl_row *);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void ovsdb_idl_row_destroy_postprocess(struct ovsdb_idl_db *);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static void ovsdb_idl_destroy_all_map_op_lists(struct ovsdb_idl_row *);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
static void ovsdb_idl_destroy_all_set_op_lists(struct ovsdb_idl_row *);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
static void ovsdb_idl_row_parse(struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_row_unparse(struct ovsdb_idl_row *);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static void ovsdb_idl_row_clear_old(struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_row_clear_new(struct ovsdb_idl_row *);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
static void ovsdb_idl_row_clear_arcs(struct ovsdb_idl_row *, bool destroy_dsts);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void ovsdb_idl_db_txn_abort_all(struct ovsdb_idl_db *);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static void ovsdb_idl_txn_abort_all(struct ovsdb_idl *);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static bool ovsdb_idl_db_txn_process_reply(struct ovsdb_idl_db *,
|
|
|
|
|
const struct jsonrpc_msg *msg);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static bool ovsdb_idl_txn_extract_mutations(struct ovsdb_idl_row *,
|
|
|
|
|
struct json *);
|
|
|
|
|
static void ovsdb_idl_txn_add_map_op(struct ovsdb_idl_row *,
|
|
|
|
|
const struct ovsdb_idl_column *,
|
|
|
|
|
struct ovsdb_datum *,
|
|
|
|
|
enum map_op_type);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
static void ovsdb_idl_txn_add_set_op(struct ovsdb_idl_row *,
|
|
|
|
|
const struct ovsdb_idl_column *,
|
|
|
|
|
struct ovsdb_datum *,
|
|
|
|
|
enum set_op_type);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static bool ovsdb_idl_db_process_lock_replies(struct ovsdb_idl_db *,
|
|
|
|
|
const struct jsonrpc_msg *);
|
|
|
|
|
static struct jsonrpc_msg *ovsdb_idl_db_compose_lock_request(
|
|
|
|
|
struct ovsdb_idl_db *);
|
|
|
|
|
static struct jsonrpc_msg *ovsdb_idl_db_compose_unlock_request(
|
|
|
|
|
struct ovsdb_idl_db *);
|
|
|
|
|
static void ovsdb_idl_db_parse_lock_reply(struct ovsdb_idl_db *,
|
|
|
|
|
const struct json *);
|
|
|
|
|
static bool ovsdb_idl_db_parse_lock_notify(struct ovsdb_idl_db *,
|
|
|
|
|
const struct json *params,
|
|
|
|
|
bool new_has_lock);
|
|
|
|
|
static struct ovsdb_idl_table *
|
|
|
|
|
ovsdb_idl_db_table_from_class(const struct ovsdb_idl_db *,
|
|
|
|
|
const struct ovsdb_idl_table_class *);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
static struct ovsdb_idl_table *
|
|
|
|
|
ovsdb_idl_table_from_class(const struct ovsdb_idl *,
|
|
|
|
|
const struct ovsdb_idl_table_class *);
|
|
|
|
|
static bool ovsdb_idl_track_is_set(struct ovsdb_idl_table *table);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
static void ovsdb_idl_send_cond_change(struct ovsdb_idl *idl);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
static void ovsdb_idl_destroy_indexes(struct ovsdb_idl_table *);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
static void ovsdb_idl_add_to_indexes(const struct ovsdb_idl_row *);
|
|
|
|
|
static void ovsdb_idl_remove_from_indexes(const struct ovsdb_idl_row *);
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_init(struct ovsdb_idl_db *db, const struct ovsdb_idl_class *class,
|
|
|
|
|
struct ovsdb_idl *parent, bool monitor_everything_by_default)
|
|
|
|
|
{
|
|
|
|
|
memset(db, 0, sizeof *db);
|
|
|
|
|
|
|
|
|
|
uint8_t default_mode = (monitor_everything_by_default
|
|
|
|
|
? OVSDB_IDL_MONITOR | OVSDB_IDL_ALERT
|
|
|
|
|
: 0);
|
|
|
|
|
|
|
|
|
|
db->idl = parent;
|
|
|
|
|
db->class_ = class;
|
|
|
|
|
shash_init(&db->table_by_name);
|
|
|
|
|
db->tables = xmalloc(class->n_tables * sizeof *db->tables);
|
|
|
|
|
for (size_t i = 0; i < class->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = &class->tables[i];
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
|
|
|
|
|
|
|
|
|
shash_add_assert(&db->table_by_name, tc->name, table);
|
|
|
|
|
table->class_ = tc;
|
|
|
|
|
table->modes = xmalloc(tc->n_columns);
|
|
|
|
|
memset(table->modes, default_mode, tc->n_columns);
|
|
|
|
|
table->need_table = false;
|
|
|
|
|
shash_init(&table->columns);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovs_list_init(&table->indexes);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (size_t j = 0; j < tc->n_columns; j++) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &tc->columns[j];
|
|
|
|
|
|
|
|
|
|
shash_add_assert(&table->columns, column->name, column);
|
|
|
|
|
}
|
|
|
|
|
hmap_init(&table->rows);
|
|
|
|
|
ovs_list_init(&table->track_list);
|
|
|
|
|
table->change_seqno[OVSDB_IDL_CHANGE_INSERT]
|
|
|
|
|
= table->change_seqno[OVSDB_IDL_CHANGE_MODIFY]
|
|
|
|
|
= table->change_seqno[OVSDB_IDL_CHANGE_DELETE] = 0;
|
|
|
|
|
table->db = db;
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
table->ack_cond = NULL;
|
|
|
|
|
table->req_cond = NULL;
|
|
|
|
|
table->new_cond = xmalloc(sizeof *table->new_cond);
|
|
|
|
|
ovsdb_idl_condition_init(table->new_cond);
|
|
|
|
|
ovsdb_idl_condition_add_clause_true(table->new_cond);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
}
|
|
|
|
|
db->monitor_id = json_array_create_2(json_string_create("monid"),
|
|
|
|
|
json_string_create(class->database));
|
|
|
|
|
hmap_init(&db->outstanding_txns);
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Creates and returns a connection to database 'remote', which should be in a
|
|
|
|
|
* form acceptable to jsonrpc_session_open(). The connection will maintain an
|
|
|
|
|
* in-memory replica of the remote database whose schema is described by
|
|
|
|
|
* 'class'. (Ordinarily 'class' is compiled from an OVSDB schema automatically
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* by ovsdb-idlc.)
|
|
|
|
|
*
|
2013-03-15 16:14:28 -07:00
|
|
|
|
* Passes 'retry' to jsonrpc_session_open(). See that function for
|
|
|
|
|
* documentation.
|
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* If 'monitor_everything_by_default' is true, then everything in the remote
|
|
|
|
|
* database will be replicated by default. ovsdb_idl_omit() and
|
|
|
|
|
* ovsdb_idl_omit_alert() may be used to selectively drop some columns from
|
|
|
|
|
* monitoring.
|
|
|
|
|
*
|
|
|
|
|
* If 'monitor_everything_by_default' is false, then no columns or tables will
|
|
|
|
|
* be replicated by default. ovsdb_idl_add_column() and ovsdb_idl_add_table()
|
|
|
|
|
* must be used to choose some columns or tables to replicate.
|
|
|
|
|
*/
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl *
|
2010-11-16 09:14:52 -08:00
|
|
|
|
ovsdb_idl_create(const char *remote, const struct ovsdb_idl_class *class,
|
2013-03-15 16:14:28 -07:00
|
|
|
|
bool monitor_everything_by_default, bool retry)
|
2018-06-18 11:36:49 -07:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl *idl = ovsdb_idl_create_unconnected(
|
|
|
|
|
class, monitor_everything_by_default);
|
|
|
|
|
ovsdb_idl_set_remote(idl, remote, retry);
|
|
|
|
|
return idl;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Creates and returns a connection to an in-memory replica of the remote
|
|
|
|
|
* database whose schema is described by 'class'. (Ordinarily 'class' is
|
|
|
|
|
* compiled from an OVSDB schema automatically by ovsdb-idlc.)
|
|
|
|
|
*
|
|
|
|
|
* Use ovsdb_idl_set_remote() to configure the database to which to connect.
|
|
|
|
|
* Until a remote is configured, no data can be retrieved.
|
|
|
|
|
*
|
|
|
|
|
* If 'monitor_everything_by_default' is true, then everything in the remote
|
|
|
|
|
* database will be replicated by default. ovsdb_idl_omit() and
|
|
|
|
|
* ovsdb_idl_omit_alert() may be used to selectively drop some columns from
|
|
|
|
|
* monitoring.
|
|
|
|
|
*
|
|
|
|
|
* If 'monitor_everything_by_default' is false, then no columns or tables will
|
|
|
|
|
* be replicated by default. ovsdb_idl_add_column() and ovsdb_idl_add_table()
|
|
|
|
|
* must be used to choose some columns or tables to replicate.
|
|
|
|
|
*/
|
|
|
|
|
struct ovsdb_idl *
|
|
|
|
|
ovsdb_idl_create_unconnected(const struct ovsdb_idl_class *class,
|
|
|
|
|
bool monitor_everything_by_default)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl *idl;
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
idl = xzalloc(sizeof *idl);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_db_init(&idl->server, &serverrec_idl_class, idl, true);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_init(&idl->data, class, idl, monitor_everything_by_default);
|
2015-03-19 23:45:42 -07:00
|
|
|
|
idl->state_seqno = UINT_MAX;
|
|
|
|
|
idl->request_id = NULL;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
idl->leader_only = true;
|
2019-04-12 16:26:24 -07:00
|
|
|
|
idl->shuffle_remotes = true;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
|
|
|
|
|
/* Monitor the Database table in the _Server database.
|
|
|
|
|
*
|
|
|
|
|
* We monitor only the row for 'class', or the row that has the
|
|
|
|
|
* desired 'cid'. */
|
|
|
|
|
struct ovsdb_idl_condition cond;
|
|
|
|
|
ovsdb_idl_condition_init(&cond);
|
|
|
|
|
if (!uuid_is_zero(&idl->cid)) {
|
|
|
|
|
serverrec_database_add_clause_cid(&cond, OVSDB_F_EQ, &idl->cid, 1);
|
|
|
|
|
} else {
|
|
|
|
|
serverrec_database_add_clause_name(&cond, OVSDB_F_EQ, class->database);
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_db_set_condition(&idl->server, &serverrec_table_database, &cond);
|
|
|
|
|
ovsdb_idl_condition_destroy(&cond);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
return idl;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-18 11:36:49 -07:00
|
|
|
|
/* Changes the remote and creates a new session.
|
|
|
|
|
*
|
|
|
|
|
* If 'retry' is true, the connection to the remote will automatically retry
|
|
|
|
|
* when it fails. If 'retry' is false, the connection is one-time. */
|
2016-04-12 08:43:59 -05:00
|
|
|
|
void
|
2018-06-18 11:36:49 -07:00
|
|
|
|
ovsdb_idl_set_remote(struct ovsdb_idl *idl, const char *remote, bool retry)
|
2016-04-12 08:43:59 -05:00
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (idl
|
|
|
|
|
&& ((remote != NULL) != (idl->remote != NULL)
|
|
|
|
|
|| (remote && idl->remote && strcmp(remote, idl->remote)))) {
|
|
|
|
|
ovs_assert(!idl->data.txn);
|
|
|
|
|
|
|
|
|
|
/* Close the old session, if any. */
|
|
|
|
|
if (idl->session) {
|
|
|
|
|
jsonrpc_session_close(idl->session);
|
|
|
|
|
idl->session = NULL;
|
|
|
|
|
|
|
|
|
|
free(idl->remote);
|
|
|
|
|
idl->remote = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Open new session, if any. */
|
|
|
|
|
if (remote) {
|
|
|
|
|
struct svec remotes = SVEC_EMPTY_INITIALIZER;
|
|
|
|
|
ovsdb_session_parse_remote(remote, &remotes, &idl->cid);
|
2019-04-12 16:26:24 -07:00
|
|
|
|
if (idl->shuffle_remotes) {
|
|
|
|
|
svec_shuffle(&remotes);
|
|
|
|
|
}
|
2018-06-18 11:36:49 -07:00
|
|
|
|
idl->session = jsonrpc_session_open_multiple(&remotes, retry);
|
|
|
|
|
svec_destroy(&remotes);
|
|
|
|
|
|
|
|
|
|
idl->state_seqno = UINT_MAX;
|
|
|
|
|
|
|
|
|
|
idl->remote = xstrdup(remote);
|
|
|
|
|
}
|
2016-04-12 08:43:59 -05:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-12 16:26:24 -07:00
|
|
|
|
/* Set whether the order of remotes should be shuffled, when there
|
|
|
|
|
* are more than one remotes. The setting doesn't take effect
|
|
|
|
|
* until the next time when ovsdb_idl_set_remote() is called. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_shuffle_remotes(struct ovsdb_idl *idl, bool shuffle)
|
|
|
|
|
{
|
|
|
|
|
idl->shuffle_remotes = shuffle;
|
|
|
|
|
}
|
|
|
|
|
|
2020-05-01 15:13:08 -04:00
|
|
|
|
/* Reset min_index to 0. This prevents a situation where the client
|
|
|
|
|
* thinks all databases have stale data, when they actually have all
|
|
|
|
|
* been destroyed and rebuilt from scratch.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_reset_min_index(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
idl->min_index = 0;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_destroy(struct ovsdb_idl_db *db)
|
|
|
|
|
{
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
struct ovsdb_idl_condition *null_cond = NULL;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovs_assert(!db->txn);
|
|
|
|
|
ovsdb_idl_db_txn_abort_all(db);
|
2019-07-01 12:24:38 +02:00
|
|
|
|
ovsdb_idl_db_clear(db);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (size_t i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
ovsdb_idl_condition_move(&table->ack_cond, &null_cond);
|
|
|
|
|
ovsdb_idl_condition_move(&table->req_cond, &null_cond);
|
|
|
|
|
ovsdb_idl_condition_move(&table->new_cond, &null_cond);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_destroy_indexes(table);
|
|
|
|
|
shash_destroy(&table->columns);
|
|
|
|
|
hmap_destroy(&table->rows);
|
|
|
|
|
free(table->modes);
|
|
|
|
|
}
|
|
|
|
|
shash_destroy(&db->table_by_name);
|
|
|
|
|
free(db->tables);
|
|
|
|
|
json_destroy(db->schema);
|
|
|
|
|
hmap_destroy(&db->outstanding_txns);
|
|
|
|
|
free(db->lock_name);
|
|
|
|
|
json_destroy(db->lock_request_id);
|
|
|
|
|
json_destroy(db->monitor_id);
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Destroys 'idl' and all of the data structures that it manages. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_destroy(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
if (idl) {
|
|
|
|
|
ovsdb_idl_clear(idl);
|
|
|
|
|
jsonrpc_session_close(idl->session);
|
2018-04-03 10:12:58 -07:00
|
|
|
|
ovsdb_idl_db_destroy(&idl->server);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_destroy(&idl->data);
|
2015-03-19 23:45:42 -07:00
|
|
|
|
json_destroy(idl->request_id);
|
2019-03-06 09:01:21 -08:00
|
|
|
|
free(idl->remote);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
free(idl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_leader_only(struct ovsdb_idl *idl, bool leader_only)
|
|
|
|
|
{
|
|
|
|
|
idl->leader_only = leader_only;
|
|
|
|
|
if (leader_only && idl->server.monitoring) {
|
|
|
|
|
ovsdb_idl_check_server_db(idl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_clear(struct ovsdb_idl_db *db)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
|
|
|
|
bool changed = false;
|
2009-12-04 14:55:24 -08:00
|
|
|
|
size_t i;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *row, *next_row;
|
|
|
|
|
|
|
|
|
|
if (hmap_is_empty(&table->rows)) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
changed = true;
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_SAFE (row, next_row, hmap_node, &table->rows) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_arc *arc, *next_arc;
|
|
|
|
|
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2010-09-17 10:33:10 -07:00
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next_arc, src_node, &row->src_arcs) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
free(arc);
|
|
|
|
|
}
|
|
|
|
|
/* No need to do anything with dst_arcs: some node has those arcs
|
|
|
|
|
* as forward arcs and will destroy them itself. */
|
|
|
|
|
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_destroy(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
2019-03-05 18:16:50 -08:00
|
|
|
|
ovsdb_idl_row_destroy_postprocess(db);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->cond_seqno = 0;
|
|
|
|
|
ovsdb_idl_db_track_clear(db);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (changed) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->change_seqno++;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static const char *
|
|
|
|
|
ovsdb_idl_state_to_string(enum ovsdb_idl_state state)
|
|
|
|
|
{
|
|
|
|
|
switch (state) {
|
|
|
|
|
#define OVSDB_IDL_STATE(NAME) case IDL_S_##NAME: return #NAME;
|
|
|
|
|
OVSDB_IDL_STATES
|
|
|
|
|
#undef OVSDB_IDL_STATE
|
|
|
|
|
default: return "<unknown>";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_retry_at(struct ovsdb_idl *idl, const char *where)
|
|
|
|
|
{
|
2019-08-19 09:29:57 -07:00
|
|
|
|
ovsdb_idl_force_reconnect(idl);
|
|
|
|
|
ovsdb_idl_transition_at(idl, IDL_S_RETRY, where);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_transition_at(struct ovsdb_idl *idl, enum ovsdb_idl_state new_state,
|
|
|
|
|
const char *where)
|
|
|
|
|
{
|
|
|
|
|
VLOG_DBG("%s: %s -> %s at %s",
|
2018-06-18 11:36:49 -07:00
|
|
|
|
idl->session ? jsonrpc_session_get_name(idl->session) : "void",
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_state_to_string(idl->state),
|
|
|
|
|
ovsdb_idl_state_to_string(new_state),
|
|
|
|
|
where);
|
|
|
|
|
idl->state = new_state;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_clear(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_db_clear(&idl->data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_send_request(struct ovsdb_idl *idl, struct jsonrpc_msg *request)
|
|
|
|
|
{
|
|
|
|
|
json_destroy(idl->request_id);
|
|
|
|
|
idl->request_id = json_clone(request->id);
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (idl->session) {
|
|
|
|
|
jsonrpc_session_send(idl->session, request);
|
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
}
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_restart_fsm(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
/* Resync data DB table conditions to avoid missing updates due to
|
|
|
|
|
* conditions that were in flight or changed locally while the connection
|
|
|
|
|
* was down.
|
|
|
|
|
*/
|
|
|
|
|
ovsdb_idl_db_sync_condition(&idl->data);
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_send_schema_request(idl, &idl->server);
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_SERVER_SCHEMA_REQUESTED);
|
|
|
|
|
idl->data.monitoring = OVSDB_IDL_NOT_MONITORING;
|
|
|
|
|
idl->server.monitoring = OVSDB_IDL_NOT_MONITORING;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_process_response(struct ovsdb_idl *idl, struct jsonrpc_msg *msg)
|
|
|
|
|
{
|
|
|
|
|
bool ok = msg->type == JSONRPC_REPLY;
|
|
|
|
|
if (!ok
|
|
|
|
|
&& idl->state != IDL_S_SERVER_SCHEMA_REQUESTED
|
|
|
|
|
&& idl->state != IDL_S_SERVER_MONITOR_COND_REQUESTED
|
2019-02-28 09:15:19 -08:00
|
|
|
|
&& idl->state != IDL_S_DATA_MONITOR_COND_REQUESTED
|
|
|
|
|
&& idl->state != IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED) {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
|
|
|
|
|
char *s = jsonrpc_msg_to_string(msg);
|
|
|
|
|
VLOG_INFO_RL(&rl, "%s: received unexpected %s response in "
|
|
|
|
|
"%s state: %s", jsonrpc_session_get_name(idl->session),
|
|
|
|
|
jsonrpc_msg_type_to_string(msg->type),
|
|
|
|
|
ovsdb_idl_state_to_string(idl->state),
|
|
|
|
|
s);
|
|
|
|
|
free(s);
|
|
|
|
|
ovsdb_idl_retry(idl);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (idl->state) {
|
|
|
|
|
case IDL_S_SERVER_SCHEMA_REQUESTED:
|
|
|
|
|
if (ok) {
|
|
|
|
|
json_destroy(idl->server.schema);
|
|
|
|
|
idl->server.schema = json_clone(msg->result);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_send_monitor_request(idl, &idl->server,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_SERVER_MONITOR_COND_REQUESTED);
|
|
|
|
|
} else {
|
|
|
|
|
ovsdb_idl_send_schema_request(idl, &idl->data);
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_DATA_SCHEMA_REQUESTED);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case IDL_S_SERVER_MONITOR_COND_REQUESTED:
|
|
|
|
|
if (ok) {
|
|
|
|
|
idl->server.monitoring = OVSDB_IDL_MONITORING_COND;
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_db_parse_monitor_reply(&idl->server, msg->result,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
if (ovsdb_idl_check_server_db(idl)) {
|
|
|
|
|
ovsdb_idl_send_db_change_aware(idl);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
ovsdb_idl_send_schema_request(idl, &idl->data);
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_DATA_SCHEMA_REQUESTED);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case IDL_S_DATA_SCHEMA_REQUESTED:
|
|
|
|
|
json_destroy(idl->data.schema);
|
|
|
|
|
idl->data.schema = json_clone(msg->result);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_send_monitor_request(idl, &idl->data,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_DATA_MONITOR_COND_REQUESTED);
|
|
|
|
|
break;
|
|
|
|
|
|
2019-02-28 09:15:19 -08:00
|
|
|
|
case IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED:
|
|
|
|
|
if (!ok) {
|
|
|
|
|
/* "monitor_cond_since" not supported. Try "monitor_cond". */
|
|
|
|
|
ovsdb_idl_send_monitor_request(idl, &idl->data,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND);
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_DATA_MONITOR_COND_REQUESTED);
|
|
|
|
|
} else {
|
|
|
|
|
idl->data.monitoring = OVSDB_IDL_MONITORING_COND_SINCE;
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_MONITORING);
|
|
|
|
|
ovsdb_idl_db_parse_monitor_reply(&idl->data, msg->result,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND_SINCE);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
case IDL_S_DATA_MONITOR_COND_REQUESTED:
|
|
|
|
|
if (!ok) {
|
|
|
|
|
/* "monitor_cond" not supported. Try "monitor". */
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_send_monitor_request(idl, &idl->data,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_DATA_MONITOR_REQUESTED);
|
|
|
|
|
} else {
|
|
|
|
|
idl->data.monitoring = OVSDB_IDL_MONITORING_COND;
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_MONITORING);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_db_parse_monitor_reply(&idl->data, msg->result,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case IDL_S_DATA_MONITOR_REQUESTED:
|
|
|
|
|
idl->data.monitoring = OVSDB_IDL_MONITORING;
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_MONITORING);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_db_parse_monitor_reply(&idl->data, msg->result,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
idl->data.change_seqno++;
|
|
|
|
|
ovsdb_idl_clear(idl);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_db_parse_update(&idl->data, msg->result,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case IDL_S_MONITORING:
|
|
|
|
|
/* We don't normally have a request outstanding in this state. If we
|
|
|
|
|
* do, it's a "monitor_cond_change", which means that the conditional
|
|
|
|
|
* monitor clauses were updated.
|
|
|
|
|
*
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
* Mark the last requested conditions as acked and if further
|
|
|
|
|
* condition changes were pending, send them now. */
|
|
|
|
|
ovsdb_idl_db_ack_condition(&idl->data);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_send_cond_change(idl);
|
|
|
|
|
idl->data.cond_seqno++;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case IDL_S_ERROR:
|
|
|
|
|
case IDL_S_RETRY:
|
|
|
|
|
/* Nothing to do in this state. */
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
OVS_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_process_msg(struct ovsdb_idl *idl, struct jsonrpc_msg *msg)
|
|
|
|
|
{
|
|
|
|
|
bool is_response = (msg->type == JSONRPC_REPLY ||
|
|
|
|
|
msg->type == JSONRPC_ERROR);
|
|
|
|
|
|
|
|
|
|
/* Process a reply to an outstanding request. */
|
|
|
|
|
if (is_response
|
|
|
|
|
&& idl->request_id && json_equal(idl->request_id, msg->id)) {
|
|
|
|
|
json_destroy(idl->request_id);
|
|
|
|
|
idl->request_id = NULL;
|
|
|
|
|
ovsdb_idl_process_response(idl, msg);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Process database contents updates. */
|
|
|
|
|
if (ovsdb_idl_db_parse_update_rpc(&idl->data, msg)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (idl->server.monitoring
|
|
|
|
|
&& ovsdb_idl_db_parse_update_rpc(&idl->server, msg)) {
|
|
|
|
|
ovsdb_idl_check_server_db(idl);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ovsdb_idl_handle_monitor_canceled(idl, &idl->data, msg)
|
|
|
|
|
|| (idl->server.monitoring
|
|
|
|
|
&& ovsdb_idl_handle_monitor_canceled(idl, &idl->server, msg))) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Process "lock" replies and related notifications. */
|
|
|
|
|
if (ovsdb_idl_db_process_lock_replies(&idl->data, msg)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Process response to a database transaction we submitted. */
|
|
|
|
|
if (is_response && ovsdb_idl_db_txn_process_reply(&idl->data, msg)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Unknown message. Log at a low level because this can happen if
|
|
|
|
|
* ovsdb_idl_txn_destroy() is called to destroy a transaction
|
|
|
|
|
* before we receive the reply.
|
|
|
|
|
*
|
|
|
|
|
* (We could sort those out from other kinds of unknown messages by
|
|
|
|
|
* using distinctive IDs for transactions, if it seems valuable to
|
|
|
|
|
* do so, and then it would be possible to use different log
|
|
|
|
|
* levels. XXX?) */
|
|
|
|
|
char *s = jsonrpc_msg_to_string(msg);
|
|
|
|
|
VLOG_DBG("%s: received unexpected %s message: %s",
|
|
|
|
|
jsonrpc_session_get_name(idl->session),
|
|
|
|
|
jsonrpc_msg_type_to_string(msg->type), s);
|
|
|
|
|
free(s);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-27 10:16:52 -07:00
|
|
|
|
/* Processes a batch of messages from the database server on 'idl'. This may
|
|
|
|
|
* cause the IDL's contents to change. The client may check for that with
|
|
|
|
|
* ovsdb_idl_get_seqno(). */
|
|
|
|
|
void
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_run(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (!idl->session) {
|
|
|
|
|
ovsdb_idl_txn_abort_all(idl);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
int i;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovs_assert(!idl->data.txn);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
|
|
|
|
ovsdb_idl_send_cond_change(idl);
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
jsonrpc_session_run(idl->session);
|
|
|
|
|
for (i = 0; jsonrpc_session_is_connected(idl->session) && i < 50; i++) {
|
2011-02-23 10:38:59 -08:00
|
|
|
|
struct jsonrpc_msg *msg;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
unsigned int seqno;
|
|
|
|
|
|
|
|
|
|
seqno = jsonrpc_session_get_seqno(idl->session);
|
2015-03-19 23:45:42 -07:00
|
|
|
|
if (idl->state_seqno != seqno) {
|
|
|
|
|
idl->state_seqno = seqno;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_abort_all(idl);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_restart_fsm(idl);
|
2015-03-19 23:45:42 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (idl->data.lock_name) {
|
|
|
|
|
jsonrpc_session_send(
|
|
|
|
|
idl->session,
|
|
|
|
|
ovsdb_idl_db_compose_lock_request(&idl->data));
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
msg = jsonrpc_session_recv(idl->session);
|
|
|
|
|
if (!msg) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_process_msg(idl, msg);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
jsonrpc_msg_destroy(msg);
|
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_row_destroy_postprocess(&idl->data);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Arranges for poll_block() to wake up when ovsdb_idl_run() has something to
|
|
|
|
|
* do or when activity occurs on a transaction on 'idl'. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_wait(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (!idl->session) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
jsonrpc_session_wait(idl->session);
|
|
|
|
|
jsonrpc_session_recv_wait(idl->session);
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a "sequence number" that represents the state of 'idl'. When
|
|
|
|
|
* ovsdb_idl_run() changes the database, the sequence number changes. The
|
|
|
|
|
* initial fetch of the entire contents of the remote database is considered to
|
|
|
|
|
* be one kind of change. Successfully acquiring a lock, if one has been
|
|
|
|
|
* configured with ovsdb_idl_set_lock(), is also considered to be a change.
|
|
|
|
|
*
|
|
|
|
|
* As long as the sequence number does not change, the client may continue to
|
|
|
|
|
* use any data structures it obtains from 'idl'. But when it changes, the
|
|
|
|
|
* client must not access any of these data structures again, because they
|
|
|
|
|
* could have freed or reused for other purposes.
|
|
|
|
|
*
|
|
|
|
|
* The sequence number can occasionally change even if the database does not.
|
|
|
|
|
* This happens if the connection to the database drops and reconnects, which
|
|
|
|
|
* causes the database contents to be reloaded even if they didn't change. (It
|
|
|
|
|
* could also happen if the database server sends out a "change" that reflects
|
|
|
|
|
* what the IDL already thought was in the database. The database server is
|
|
|
|
|
* not supposed to do that, but bugs could in theory cause it to do so.) */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_get_seqno(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return idl->data.change_seqno;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 23:55:01 -08:00
|
|
|
|
/* Returns a "sequence number" that represents the number of conditional
|
|
|
|
|
* monitoring updates successfully received by the OVSDB server of an IDL
|
|
|
|
|
* connection.
|
|
|
|
|
*
|
|
|
|
|
* ovsdb_idl_set_condition() sets a new condition that is different from
|
|
|
|
|
* the current condtion, the next expected "sequence number" is returned.
|
|
|
|
|
*
|
|
|
|
|
* Whenever ovsdb_idl_get_cond_seqno() returns a value that matches
|
|
|
|
|
* the return value of ovsdb_idl_set_condition(), The client is
|
|
|
|
|
* assured that:
|
|
|
|
|
* - The ovsdb_idl_set_condition() changes has been acknowledged by
|
|
|
|
|
* the OVSDB sever.
|
|
|
|
|
*
|
|
|
|
|
* - 'idl' now contains the content matches the new conditions. */
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_get_condition_seqno(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return idl->data.cond_seqno;
|
2016-12-19 23:55:01 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Returns true if 'idl' successfully connected to the remote database and
|
|
|
|
|
* retrieved its contents (even if the connection subsequently dropped and is
|
|
|
|
|
* in the process of reconnecting). If so, then 'idl' contains an atomic
|
|
|
|
|
* snapshot of the database's contents (but it might be arbitrarily old if the
|
|
|
|
|
* connection dropped).
|
|
|
|
|
*
|
|
|
|
|
* Returns false if 'idl' has never connected or retrieved the database's
|
|
|
|
|
* contents. If so, 'idl' is empty. */
|
2010-01-14 13:10:35 -08:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_has_ever_connected(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_get_seqno(idl) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-02-18 13:19:36 -08:00
|
|
|
|
/* Reconfigures 'idl' so that it would reconnect to the database, if
|
|
|
|
|
* connection was dropped. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_enable_reconnect(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (idl->session) {
|
|
|
|
|
jsonrpc_session_enable_reconnect(idl->session);
|
|
|
|
|
}
|
2014-02-18 13:19:36 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-06-23 10:13:39 -07:00
|
|
|
|
/* Forces 'idl' to drop its connection to the database and reconnect. In the
|
|
|
|
|
* meantime, the contents of 'idl' will not change. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_force_reconnect(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (idl->session) {
|
|
|
|
|
jsonrpc_session_force_reconnect(idl->session);
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2012-09-20 11:13:15 -07:00
|
|
|
|
|
|
|
|
|
/* Some IDL users should only write to write-only columns. Furthermore,
|
|
|
|
|
* writing to a column which is not write-only can cause serious performance
|
|
|
|
|
* degradations for these users. This function causes 'idl' to reject writes
|
|
|
|
|
* to columns which are not marked write only using ovsdb_idl_omit_alert(). */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_verify_write_only(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
idl->data.verify_write_only = true;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
}
|
2013-03-15 16:14:28 -07:00
|
|
|
|
|
2016-02-24 10:48:34 -05:00
|
|
|
|
/* Returns true if 'idl' is currently connected or trying to connect
|
|
|
|
|
* and a negative response to a schema request has not been received */
|
2013-03-15 16:14:28 -07:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_alive(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
return idl->session && jsonrpc_session_is_alive(idl->session) &&
|
2017-12-31 21:15:58 -08:00
|
|
|
|
idl->state != IDL_S_ERROR;
|
2013-03-15 16:14:28 -07:00
|
|
|
|
}
|
|
|
|
|
|
2018-07-31 17:35:00 +02:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_connected(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
return idl->session && jsonrpc_session_is_connected(idl->session);
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-31 11:28:39 -07:00
|
|
|
|
/* Returns the last error reported on a connection by 'idl'. The return value
|
2016-02-24 10:48:34 -05:00
|
|
|
|
* is 0 only if no connection made by 'idl' has ever encountered an error and
|
|
|
|
|
* a negative response to a schema request has never been received. See
|
|
|
|
|
* jsonrpc_get_status() for jsonrpc_session_get_last_error() return value
|
|
|
|
|
* interpretation. */
|
2013-03-15 16:14:28 -07:00
|
|
|
|
int
|
|
|
|
|
ovsdb_idl_get_last_error(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
int err = idl->session ? jsonrpc_session_get_last_error(idl->session) : 0;
|
2016-02-24 10:48:34 -05:00
|
|
|
|
if (err) {
|
|
|
|
|
return err;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
} else if (idl->state == IDL_S_ERROR) {
|
2016-02-24 10:48:34 -05:00
|
|
|
|
return ENOENT;
|
|
|
|
|
} else {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2013-03-15 16:14:28 -07:00
|
|
|
|
}
|
2016-03-25 02:18:34 +08:00
|
|
|
|
|
|
|
|
|
/* Sets the "probe interval" for 'idl->session' to 'probe_interval', in
|
|
|
|
|
* milliseconds.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_probe_interval(const struct ovsdb_idl *idl, int probe_interval)
|
|
|
|
|
{
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (idl->session) {
|
|
|
|
|
jsonrpc_session_set_probe_interval(idl->session, probe_interval);
|
|
|
|
|
}
|
2016-03-25 02:18:34 +08:00
|
|
|
|
}
|
2016-09-07 09:04:46 -07:00
|
|
|
|
|
|
|
|
|
static size_t
|
|
|
|
|
find_uuid_in_array(const struct uuid *target,
|
|
|
|
|
const struct uuid *array, size_t n)
|
|
|
|
|
{
|
|
|
|
|
for (size_t i = 0; i < n; i++) {
|
|
|
|
|
if (uuid_equals(&array[i], target)) {
|
|
|
|
|
return i;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return SIZE_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static size_t
|
|
|
|
|
array_contains_uuid(const struct uuid *target,
|
|
|
|
|
const struct uuid *array, size_t n)
|
|
|
|
|
{
|
|
|
|
|
return find_uuid_in_array(target, array, n) != SIZE_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
remove_uuid_from_array(const struct uuid *target,
|
|
|
|
|
struct uuid *array, size_t *n)
|
|
|
|
|
{
|
|
|
|
|
size_t i = find_uuid_in_array(target, array, *n);
|
|
|
|
|
if (i != SIZE_MAX) {
|
|
|
|
|
array[i] = array[--*n];
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
add_row_references(const struct ovsdb_base_type *type,
|
|
|
|
|
const union ovsdb_atom *atoms, size_t n_atoms,
|
|
|
|
|
const struct uuid *exclude_uuid,
|
|
|
|
|
struct uuid **dstsp, size_t *n_dstsp,
|
|
|
|
|
size_t *allocated_dstsp)
|
|
|
|
|
{
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (type->type != OVSDB_TYPE_UUID || !type->uuid.refTableName) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0; i < n_atoms; i++) {
|
|
|
|
|
const struct uuid *uuid = &atoms[i].uuid;
|
|
|
|
|
if (!uuid_equals(uuid, exclude_uuid)
|
|
|
|
|
&& !array_contains_uuid(uuid, *dstsp, *n_dstsp)) {
|
|
|
|
|
if (*n_dstsp >= *allocated_dstsp) {
|
|
|
|
|
*dstsp = x2nrealloc(*dstsp, allocated_dstsp,
|
|
|
|
|
sizeof **dstsp);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
(*dstsp)[*n_dstsp] = *uuid;
|
|
|
|
|
++*n_dstsp;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Checks for consistency in 'idl''s graph of arcs between database rows. Each
|
|
|
|
|
* reference from one row to a different row should be reflected as a "struct
|
|
|
|
|
* ovsdb_idl_arc" between those rows.
|
|
|
|
|
*
|
|
|
|
|
* This function is slow, big-O wise, and aborts if it finds an inconsistency,
|
|
|
|
|
* thus it is only for use in test programs. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_check_consistency(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
/* Consistency is broken while a transaction is in progress. */
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (!idl->data.txn) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ok = true;
|
|
|
|
|
|
|
|
|
|
struct uuid *dsts = NULL;
|
|
|
|
|
size_t allocated_dsts = 0;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (size_t i = 0; i < idl->data.class_->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table *table = &idl->data.tables[i];
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = table->class_;
|
2016-09-07 09:04:46 -07:00
|
|
|
|
|
|
|
|
|
const struct ovsdb_idl_row *row;
|
|
|
|
|
HMAP_FOR_EACH (row, hmap_node, &table->rows) {
|
|
|
|
|
size_t n_dsts = 0;
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
size_t n_columns = shash_count(&row->table->columns);
|
|
|
|
|
for (size_t j = 0; j < n_columns; j++) {
|
|
|
|
|
const struct ovsdb_type *type = &class->columns[j].type;
|
2017-08-11 11:06:46 -07:00
|
|
|
|
const struct ovsdb_datum *datum = &row->new_datum[j];
|
2016-09-07 09:04:46 -07:00
|
|
|
|
add_row_references(&type->key,
|
|
|
|
|
datum->keys, datum->n, &row->uuid,
|
|
|
|
|
&dsts, &n_dsts, &allocated_dsts);
|
|
|
|
|
add_row_references(&type->value,
|
|
|
|
|
datum->values, datum->n, &row->uuid,
|
|
|
|
|
&dsts, &n_dsts, &allocated_dsts);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
const struct ovsdb_idl_arc *arc;
|
|
|
|
|
LIST_FOR_EACH (arc, src_node, &row->src_arcs) {
|
|
|
|
|
if (!remove_uuid_from_array(&arc->dst->uuid,
|
|
|
|
|
dsts, &n_dsts)) {
|
|
|
|
|
VLOG_ERR("unexpected arc from %s row "UUID_FMT" to %s "
|
|
|
|
|
"row "UUID_FMT,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
table->class_->name,
|
2016-09-07 09:04:46 -07:00
|
|
|
|
UUID_ARGS(&row->uuid),
|
2017-08-11 11:06:44 -07:00
|
|
|
|
arc->dst->table->class_->name,
|
2016-09-07 09:04:46 -07:00
|
|
|
|
UUID_ARGS(&arc->dst->uuid));
|
|
|
|
|
ok = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
2017-08-02 15:03:06 -07:00
|
|
|
|
for (size_t j = 0; j < n_dsts; j++) {
|
2016-09-07 09:04:46 -07:00
|
|
|
|
VLOG_ERR("%s row "UUID_FMT" missing arc to row "UUID_FMT,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
table->class_->name, UUID_ARGS(&row->uuid),
|
2017-08-02 15:03:06 -07:00
|
|
|
|
UUID_ARGS(&dsts[j]));
|
2016-09-07 09:04:46 -07:00
|
|
|
|
ok = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
free(dsts);
|
|
|
|
|
ovs_assert(ok);
|
|
|
|
|
}
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
2017-04-27 13:54:53 -07:00
|
|
|
|
const struct ovsdb_idl_class *
|
|
|
|
|
ovsdb_idl_get_class(const struct ovsdb_idl *idl)
|
2010-08-11 15:41:41 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return idl->data.class_;
|
2017-04-27 13:54:53 -07:00
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
|
2017-04-27 13:54:53 -07:00
|
|
|
|
/* Given 'column' in some table in 'class', returns the table's class. */
|
|
|
|
|
const struct ovsdb_idl_table_class *
|
|
|
|
|
ovsdb_idl_table_class_from_column(const struct ovsdb_idl_class *class,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
for (size_t i = 0; i < class->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = &class->tables[i];
|
2010-08-11 15:41:41 -07:00
|
|
|
|
if (column >= tc->columns && column < &tc->columns[tc->n_columns]) {
|
2017-04-27 13:54:53 -07:00
|
|
|
|
return tc;
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-17 10:32:12 -08:00
|
|
|
|
OVS_NOT_REACHED();
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
/* Given 'column' in some table in 'db', returns the table. */
|
2017-04-27 13:54:53 -07:00
|
|
|
|
static struct ovsdb_idl_table *
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_table_from_column(struct ovsdb_idl_db *db,
|
2017-04-27 13:54:53 -07:00
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *tc =
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_table_class_from_column(db->class_, column);
|
|
|
|
|
return &db->tables[tc - db->class_->tables];
|
2017-04-27 13:54:53 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static unsigned char *
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_get_mode(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
2017-04-27 13:54:53 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovs_assert(!db->change_seqno);
|
2017-04-27 13:54:53 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
const struct ovsdb_idl_table *table = ovsdb_idl_table_from_column(db,
|
2017-04-27 13:54:53 -07:00
|
|
|
|
column);
|
2017-08-11 11:06:44 -07:00
|
|
|
|
return &table->modes[column - table->class_->columns];
|
2017-04-27 13:54:53 -07:00
|
|
|
|
}
|
|
|
|
|
|
2018-07-19 15:51:07 +02:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_set_mode(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
unsigned char mode)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table *table = ovsdb_idl_table_from_column(db,
|
|
|
|
|
column);
|
|
|
|
|
size_t column_idx = column - table->class_->columns;
|
|
|
|
|
|
|
|
|
|
if (table->modes[column_idx] != mode) {
|
|
|
|
|
*ovsdb_idl_db_get_mode(db, column) = mode;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-16 09:14:52 -08:00
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
add_ref_table(struct ovsdb_idl_db *db, const struct ovsdb_base_type *base)
|
2010-11-16 09:14:52 -08:00
|
|
|
|
{
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (base->type == OVSDB_TYPE_UUID && base->uuid.refTableName) {
|
2010-11-16 09:14:52 -08:00
|
|
|
|
struct ovsdb_idl_table *table;
|
|
|
|
|
|
2018-05-24 10:32:59 -07:00
|
|
|
|
table = shash_find_data(&db->table_by_name, base->uuid.refTableName);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
if (table) {
|
|
|
|
|
table->need_table = true;
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN("%s IDL class missing referenced table %s",
|
2018-05-24 10:32:59 -07:00
|
|
|
|
db->class_->database, base->uuid.refTableName);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_add_column(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2018-07-19 15:51:07 +02:00
|
|
|
|
ovsdb_idl_db_set_mode(db, column, OVSDB_IDL_MONITOR | OVSDB_IDL_ALERT);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
add_ref_table(db, &column->type.key);
|
|
|
|
|
add_ref_table(db, &column->type.value);
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-16 09:14:52 -08:00
|
|
|
|
/* Turns on OVSDB_IDL_MONITOR and OVSDB_IDL_ALERT for 'column' in 'idl'. Also
|
|
|
|
|
* ensures that any tables referenced by 'column' will be replicated, even if
|
|
|
|
|
* no columns in that table are selected for replication (see
|
|
|
|
|
* ovsdb_idl_add_table() for more information).
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function is only useful if 'monitor_everything_by_default' was false in
|
|
|
|
|
* the call to ovsdb_idl_create(). This function should be called between
|
|
|
|
|
* ovsdb_idl_create() and the first call to ovsdb_idl_run().
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_add_column(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_add_column(&idl->data, column);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_add_table(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc)
|
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
|
|
|
|
|
|
|
|
|
if (table->class_ == tc) {
|
|
|
|
|
table->need_table = true;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OVS_NOT_REACHED();
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Ensures that the table with class 'tc' will be replicated on 'idl' even if
|
2015-11-27 16:57:07 +00:00
|
|
|
|
* no columns are selected for replication. Just the necessary data for table
|
|
|
|
|
* references will be replicated (the UUID of the rows, for instance), any
|
|
|
|
|
* columns not selected for replication will remain unreplicated.
|
|
|
|
|
* This can be useful because it allows 'idl' to keep track of what rows in the
|
|
|
|
|
* table actually exist, which in turn allows columns that reference the table
|
|
|
|
|
* to have accurate contents. (The IDL presents the database with references to
|
|
|
|
|
* rows that do not exist removed.)
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function is only useful if 'monitor_everything_by_default' was false in
|
|
|
|
|
* the call to ovsdb_idl_create(). This function should be called between
|
|
|
|
|
* ovsdb_idl_create() and the first call to ovsdb_idl_run().
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_add_table(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_add_table(&idl->data, tc);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
2016-08-13 21:52:27 -07:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
/* A single clause within an ovsdb_idl_condition. */
|
2016-08-13 21:52:27 -07:00
|
|
|
|
struct ovsdb_idl_clause {
|
2016-12-19 20:55:35 -08:00
|
|
|
|
struct hmap_node hmap_node; /* In struct ovsdb_idl_condition. */
|
|
|
|
|
enum ovsdb_function function; /* Never OVSDB_F_TRUE or OVSDB_F_FALSE. */
|
|
|
|
|
const struct ovsdb_idl_column *column; /* Must be nonnull. */
|
|
|
|
|
struct ovsdb_datum arg; /* Has ovsdb_type ->column->type. */
|
2016-08-13 21:52:27 -07:00
|
|
|
|
};
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
static uint32_t
|
|
|
|
|
ovsdb_idl_clause_hash(const struct ovsdb_idl_clause *clause)
|
|
|
|
|
{
|
|
|
|
|
uint32_t hash = hash_pointer(clause->column, clause->function);
|
|
|
|
|
return ovsdb_datum_hash(&clause->arg, &clause->column->type, hash);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int
|
|
|
|
|
ovsdb_idl_clause_equals(const struct ovsdb_idl_clause *a,
|
|
|
|
|
const struct ovsdb_idl_clause *b)
|
|
|
|
|
{
|
|
|
|
|
return (a->function == b->function
|
|
|
|
|
&& a->column == b->column
|
|
|
|
|
&& ovsdb_datum_equals(&a->arg, &b->arg, &a->column->type));
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-18 11:45:58 +03:00
|
|
|
|
static struct json *
|
|
|
|
|
ovsdb_idl_clause_to_json(const struct ovsdb_idl_clause *clause)
|
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
const char *function = ovsdb_function_to_string(clause->function);
|
|
|
|
|
return json_array_create_3(json_string_create(clause->column->name),
|
|
|
|
|
json_string_create(function),
|
|
|
|
|
ovsdb_datum_to_json(&clause->arg,
|
|
|
|
|
&clause->column->type));
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_clause_destroy(struct ovsdb_idl_clause *clause)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (clause) {
|
2016-07-18 11:45:58 +03:00
|
|
|
|
ovsdb_datum_destroy(&clause->arg, &clause->column->type);
|
2016-12-19 20:55:35 -08:00
|
|
|
|
free(clause);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2016-12-19 20:55:35 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* ovsdb_idl_condition. */
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_condition_init(struct ovsdb_idl_condition *cnd)
|
|
|
|
|
{
|
|
|
|
|
hmap_init(&cnd->clauses);
|
|
|
|
|
cnd->is_true = false;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_condition_destroy(struct ovsdb_idl_condition *cond)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (cond) {
|
|
|
|
|
ovsdb_idl_condition_clear(cond);
|
|
|
|
|
hmap_destroy(&cond->clauses);
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_condition_clear(struct ovsdb_idl_condition *cond)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_clause *clause, *next;
|
|
|
|
|
HMAP_FOR_EACH_SAFE (clause, next, hmap_node, &cond->clauses) {
|
|
|
|
|
hmap_remove(&cond->clauses, &clause->hmap_node);
|
|
|
|
|
ovsdb_idl_clause_destroy(clause);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2016-12-19 20:55:35 -08:00
|
|
|
|
cond->is_true = false;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_condition_is_true(const struct ovsdb_idl_condition *condition)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
return condition->is_true;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-08-13 21:52:27 -07:00
|
|
|
|
static struct ovsdb_idl_clause *
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_condition_find_clause(const struct ovsdb_idl_condition *condition,
|
|
|
|
|
const struct ovsdb_idl_clause *target,
|
|
|
|
|
uint32_t hash)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
struct ovsdb_idl_clause *clause;
|
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (clause, hmap_node, hash, &condition->clauses) {
|
|
|
|
|
if (ovsdb_idl_clause_equals(clause, target)) {
|
|
|
|
|
return clause;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-13 21:52:27 -07:00
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_condition_add_clause__(struct ovsdb_idl_condition *condition,
|
|
|
|
|
const struct ovsdb_idl_clause *src,
|
|
|
|
|
uint32_t hash)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_clause *clause = xmalloc(sizeof *clause);
|
|
|
|
|
clause->function = src->function;
|
|
|
|
|
clause->column = src->column;
|
|
|
|
|
ovsdb_datum_clone(&clause->arg, &src->arg, &src->column->type);
|
|
|
|
|
hmap_insert(&condition->clauses, &clause->hmap_node, hash);
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-13 21:52:27 -07:00
|
|
|
|
/* Adds a clause to the condition for replicating the table with class 'tc' in
|
|
|
|
|
* 'idl'.
|
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* The IDL replicates only rows in a table that satisfy at least one clause in
|
|
|
|
|
* the table's condition. The default condition for a table has a single
|
|
|
|
|
* clause with function OVSDB_F_TRUE, so that the IDL replicates all rows in
|
|
|
|
|
* the table. When the IDL client replaces the default condition by one of its
|
|
|
|
|
* own, the condition can have any number of clauses. If it has no conditions,
|
|
|
|
|
* then no rows are replicated.
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* Two distinct of clauses can usefully be added:
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* - A 'function' of OVSDB_F_TRUE. A "true" clause causes every row to be
|
|
|
|
|
* replicated, regardless of whether other clauses exist. 'column' and
|
|
|
|
|
* 'arg' are ignored.
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*
|
2016-12-19 20:55:35 -08:00
|
|
|
|
* - Binary 'functions' add a clause of the form "<column> <function>
|
|
|
|
|
* <arg>", e.g. "column == 5" or "column <= 10". In this case, 'arg' must
|
|
|
|
|
* have a type that is compatible with 'column'.
|
2016-08-13 21:52:27 -07:00
|
|
|
|
*/
|
|
|
|
|
void
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_condition_add_clause(struct ovsdb_idl_condition *condition,
|
2016-08-13 21:52:27 -07:00
|
|
|
|
enum ovsdb_function function,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
const struct ovsdb_datum *arg)
|
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (condition->is_true) {
|
|
|
|
|
/* Adding a clause to an always-true condition has no effect. */
|
|
|
|
|
} else if (function == OVSDB_F_TRUE) {
|
|
|
|
|
ovsdb_idl_condition_add_clause_true(condition);
|
|
|
|
|
} else if (function == OVSDB_F_FALSE) {
|
|
|
|
|
/* Adding a "false" clause never has any effect. */
|
|
|
|
|
} else {
|
|
|
|
|
struct ovsdb_idl_clause clause = {
|
|
|
|
|
.function = function,
|
|
|
|
|
.column = column,
|
|
|
|
|
.arg = *arg,
|
|
|
|
|
};
|
|
|
|
|
uint32_t hash = ovsdb_idl_clause_hash(&clause);
|
|
|
|
|
if (!ovsdb_idl_condition_find_clause(condition, &clause, hash)) {
|
|
|
|
|
ovsdb_idl_condition_add_clause__(condition, &clause, hash);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-13 21:52:27 -07:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_condition_add_clause_true(struct ovsdb_idl_condition *condition)
|
|
|
|
|
{
|
|
|
|
|
if (!condition->is_true) {
|
|
|
|
|
ovsdb_idl_condition_clear(condition);
|
|
|
|
|
condition->is_true = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_condition_equals(const struct ovsdb_idl_condition *a,
|
|
|
|
|
const struct ovsdb_idl_condition *b)
|
|
|
|
|
{
|
|
|
|
|
if (hmap_count(&a->clauses) != hmap_count(&b->clauses)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
if (a->is_true != b->is_true) {
|
|
|
|
|
return false;
|
2016-08-13 21:52:27 -07:00
|
|
|
|
}
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
const struct ovsdb_idl_clause *clause;
|
|
|
|
|
HMAP_FOR_EACH (clause, hmap_node, &a->clauses) {
|
|
|
|
|
if (!ovsdb_idl_condition_find_clause(b, clause,
|
|
|
|
|
clause->hmap_node.hash)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
static void
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
ovsdb_idl_condition_clone(struct ovsdb_idl_condition **dst,
|
2016-12-19 20:55:35 -08:00
|
|
|
|
const struct ovsdb_idl_condition *src)
|
|
|
|
|
{
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
if (*dst) {
|
|
|
|
|
ovsdb_idl_condition_destroy(*dst);
|
|
|
|
|
} else {
|
|
|
|
|
*dst = xmalloc(sizeof **dst);
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_condition_init(*dst);
|
2016-12-19 20:55:35 -08:00
|
|
|
|
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
(*dst)->is_true = src->is_true;
|
2016-12-19 20:55:35 -08:00
|
|
|
|
|
|
|
|
|
const struct ovsdb_idl_clause *clause;
|
|
|
|
|
HMAP_FOR_EACH (clause, hmap_node, &src->clauses) {
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
ovsdb_idl_condition_add_clause__(*dst, clause, clause->hmap_node.hash);
|
2016-12-19 20:55:35 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_condition_move(struct ovsdb_idl_condition **dst,
|
|
|
|
|
struct ovsdb_idl_condition **src)
|
|
|
|
|
{
|
|
|
|
|
if (*dst) {
|
|
|
|
|
ovsdb_idl_condition_destroy(*dst);
|
|
|
|
|
free(*dst);
|
|
|
|
|
}
|
|
|
|
|
*dst = *src;
|
|
|
|
|
*src = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static unsigned int
|
|
|
|
|
ovsdb_idl_db_set_condition(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc,
|
|
|
|
|
const struct ovsdb_idl_condition *condition)
|
|
|
|
|
{
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
struct ovsdb_idl_condition *table_cond;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_table *table = ovsdb_idl_db_table_from_class(db, tc);
|
|
|
|
|
unsigned int seqno = db->cond_seqno;
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
|
|
|
|
|
/* Compare the new condition to the last known condition which can be
|
|
|
|
|
* either "new" (not sent yet), "requested" or "acked", in this order.
|
|
|
|
|
*/
|
|
|
|
|
if (table->new_cond) {
|
|
|
|
|
table_cond = table->new_cond;
|
|
|
|
|
} else if (table->req_cond) {
|
|
|
|
|
table_cond = table->req_cond;
|
|
|
|
|
} else {
|
|
|
|
|
table_cond = table->ack_cond;
|
|
|
|
|
}
|
|
|
|
|
ovs_assert(table_cond);
|
|
|
|
|
|
|
|
|
|
if (!ovsdb_idl_condition_equals(condition, table_cond)) {
|
|
|
|
|
ovsdb_idl_condition_clone(&table->new_cond, condition);
|
|
|
|
|
db->cond_changed = true;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
poll_immediate_wake();
|
|
|
|
|
return seqno + 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return seqno;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 23:55:01 -08:00
|
|
|
|
/* Sets the replication condition for 'tc' in 'idl' to 'condition' and
|
|
|
|
|
* arranges to send the new condition to the database server.
|
|
|
|
|
*
|
2017-12-11 14:30:33 -08:00
|
|
|
|
* Return the next conditional update sequence number. When this
|
|
|
|
|
* value and ovsdb_idl_get_condition_seqno() matches, the 'idl'
|
|
|
|
|
* contains rows that match the 'condition'. */
|
2016-12-19 23:55:01 -08:00
|
|
|
|
unsigned int
|
2016-12-19 20:55:35 -08:00
|
|
|
|
ovsdb_idl_set_condition(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc,
|
|
|
|
|
const struct ovsdb_idl_condition *condition)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return ovsdb_idl_db_set_condition(&idl->data, tc, condition);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct json *
|
|
|
|
|
ovsdb_idl_condition_to_json(const struct ovsdb_idl_condition *cnd)
|
|
|
|
|
{
|
2016-12-19 20:55:35 -08:00
|
|
|
|
if (cnd->is_true) {
|
|
|
|
|
return json_array_create_empty();
|
|
|
|
|
}
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
size_t n = hmap_count(&cnd->clauses);
|
|
|
|
|
if (!n) {
|
|
|
|
|
return json_array_create_1(json_boolean_create(false));
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2016-12-19 20:55:35 -08:00
|
|
|
|
struct json **clauses = xmalloc(n * sizeof *clauses);
|
|
|
|
|
const struct ovsdb_idl_clause *clause;
|
|
|
|
|
size_t i = 0;
|
|
|
|
|
HMAP_FOR_EACH (clause, hmap_node, &cnd->clauses) {
|
|
|
|
|
clauses[i++] = ovsdb_idl_clause_to_json(clause);
|
|
|
|
|
}
|
|
|
|
|
ovs_assert(i == n);
|
|
|
|
|
return json_array_create(clauses, n);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2016-12-19 20:55:35 -08:00
|
|
|
|
|
2016-08-13 21:52:27 -07:00
|
|
|
|
static struct json *
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
ovsdb_idl_create_cond_change_req(const struct ovsdb_idl_condition *cond)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
|
|
|
|
struct json *monitor_cond_change_request = json_object_create();
|
|
|
|
|
struct json *cond_json = ovsdb_idl_condition_to_json(cond);
|
|
|
|
|
|
|
|
|
|
json_object_put(monitor_cond_change_request, "where", cond_json);
|
|
|
|
|
|
|
|
|
|
return monitor_cond_change_request;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct jsonrpc_msg *
|
|
|
|
|
ovsdb_idl_db_compose_cond_change(struct ovsdb_idl_db *db)
|
2016-07-18 11:45:58 +03:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (!db->cond_changed) {
|
|
|
|
|
return NULL;
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct json *monitor_cond_change_requests = NULL;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (size_t i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
/* Always use the most recent conditions set by the IDL client when
|
|
|
|
|
* requesting monitor_cond_change, i.e., table->new_cond.
|
|
|
|
|
*/
|
|
|
|
|
if (table->new_cond) {
|
|
|
|
|
struct json *req =
|
|
|
|
|
ovsdb_idl_create_cond_change_req(table->new_cond);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
if (req) {
|
|
|
|
|
if (!monitor_cond_change_requests) {
|
|
|
|
|
monitor_cond_change_requests = json_object_create();
|
|
|
|
|
}
|
|
|
|
|
json_object_put(monitor_cond_change_requests,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
table->class_->name,
|
2016-07-18 11:45:58 +03:00
|
|
|
|
json_array_create_1(req));
|
|
|
|
|
}
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
/* Mark the new condition as requested by moving it to req_cond.
|
|
|
|
|
* If there's already requested condition that's a bug.
|
|
|
|
|
*/
|
|
|
|
|
ovs_assert(table->req_cond == NULL);
|
|
|
|
|
ovsdb_idl_condition_move(&table->req_cond, &table->new_cond);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (!monitor_cond_change_requests) {
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
db->cond_changed = false;
|
|
|
|
|
struct json *params = json_array_create_3(json_clone(db->monitor_id),
|
|
|
|
|
json_clone(db->monitor_id),
|
|
|
|
|
monitor_cond_change_requests);
|
|
|
|
|
return jsonrpc_create_request("monitor_cond_change", params, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
/* Marks all requested table conditions in 'db' as acked by the server.
|
|
|
|
|
* It should be called when the server replies to monitor_cond_change
|
|
|
|
|
* requests.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_ack_condition(struct ovsdb_idl_db *db)
|
|
|
|
|
{
|
|
|
|
|
for (size_t i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
|
|
|
|
|
|
|
|
|
if (table->req_cond) {
|
|
|
|
|
ovsdb_idl_condition_move(&table->ack_cond, &table->req_cond);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Should be called when the IDL fsm is restarted and resyncs table conditions
|
|
|
|
|
* based on the state the DB is in:
|
|
|
|
|
* - if a non-zero last_id is available for the DB then upon reconnect
|
|
|
|
|
* the IDL should first request acked conditions to avoid missing updates
|
|
|
|
|
* about records that were added before the transaction with
|
|
|
|
|
* txn-id == last_id. If there were requested condition changes in flight
|
|
|
|
|
* (i.e., req_cond not NULL) and the IDL client didn't set new conditions
|
|
|
|
|
* (i.e., new_cond is NULL) then move req_cond to new_cond to trigger a
|
|
|
|
|
* follow up monitor_cond_change request.
|
|
|
|
|
* - if there's no last_id available for the DB then it's safe to use the
|
|
|
|
|
* latest conditions set by the IDL client even if they weren't acked yet.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_sync_condition(struct ovsdb_idl_db *db)
|
|
|
|
|
{
|
|
|
|
|
bool ack_all = uuid_is_zero(&db->last_id);
|
|
|
|
|
|
|
|
|
|
db->cond_changed = false;
|
|
|
|
|
for (size_t i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
|
|
|
|
|
|
|
|
|
/* When monitor_cond_since requests will be issued, the
|
|
|
|
|
* table->ack_cond condition will be added to the "where" clause".
|
|
|
|
|
* Follow up monitor_cond_change requests will use table->new_cond.
|
|
|
|
|
*/
|
|
|
|
|
if (ack_all) {
|
|
|
|
|
if (table->new_cond) {
|
|
|
|
|
ovsdb_idl_condition_move(&table->req_cond, &table->new_cond);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (table->req_cond) {
|
|
|
|
|
ovsdb_idl_condition_move(&table->ack_cond, &table->req_cond);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/* If there was no "unsent" condition but instead a
|
|
|
|
|
* monitor_cond_change request was in flight, move table->req_cond
|
|
|
|
|
* to table->new_cond and set db->cond_changed to trigger a new
|
|
|
|
|
* monitor_cond_change request.
|
|
|
|
|
*
|
|
|
|
|
* However, if a new condition has been set by the IDL client,
|
|
|
|
|
* monitor_cond_change will be sent anyway and will use the most
|
|
|
|
|
* recent table->new_cond so there's no need to update it here.
|
|
|
|
|
*/
|
|
|
|
|
if (table->req_cond && !table->new_cond) {
|
|
|
|
|
ovsdb_idl_condition_move(&table->new_cond, &table->req_cond);
|
|
|
|
|
db->cond_changed = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_send_cond_change(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
/* When 'idl->request_id' is not NULL, there is an outstanding
|
|
|
|
|
* conditional monitoring update request that we have not heard
|
|
|
|
|
* from the server yet. Don't generate another request in this case. */
|
|
|
|
|
if (!jsonrpc_session_is_connected(idl->session)
|
2019-02-28 09:15:19 -08:00
|
|
|
|
|| idl->data.monitoring == OVSDB_IDL_MONITORING
|
2017-12-15 10:59:36 -08:00
|
|
|
|
|| idl->request_id) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-07-18 11:45:58 +03:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct jsonrpc_msg *msg = ovsdb_idl_db_compose_cond_change(&idl->data);
|
|
|
|
|
if (msg) {
|
|
|
|
|
idl->request_id = json_clone(msg->id);
|
|
|
|
|
jsonrpc_session_send(idl->session, msg);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
}
|
|
|
|
|
|
2018-04-04 10:24:24 -07:00
|
|
|
|
/* Turns off OVSDB_IDL_ALERT and OVSDB_IDL_TRACK for 'column' in 'db'.
|
2017-12-15 10:59:36 -08:00
|
|
|
|
*
|
|
|
|
|
* This function should be called between ovsdb_idl_create() and the first call
|
|
|
|
|
* to ovsdb_idl_run().
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_omit_alert(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2018-04-04 10:24:24 -07:00
|
|
|
|
*ovsdb_idl_db_get_mode(db, column) &= ~(OVSDB_IDL_ALERT | OVSDB_IDL_TRACK);
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
|
|
|
|
|
2018-04-04 10:24:24 -07:00
|
|
|
|
/* Turns off OVSDB_IDL_ALERT and OVSDB_IDL_TRACK for 'column' in 'idl'.
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function should be called between ovsdb_idl_create() and the first call
|
|
|
|
|
* to ovsdb_idl_run().
|
|
|
|
|
*/
|
2010-08-11 15:41:41 -07:00
|
|
|
|
void
|
2010-11-16 09:14:52 -08:00
|
|
|
|
ovsdb_idl_omit_alert(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
2010-08-11 15:41:41 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_omit_alert(&idl->data, column);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_omit(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
*ovsdb_idl_db_get_mode(db, column) = 0;
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-11-16 09:14:52 -08:00
|
|
|
|
/* Sets the mode for 'column' in 'idl' to 0. See the big comment above
|
|
|
|
|
* OVSDB_IDL_MONITOR for details.
|
2010-08-11 15:41:41 -07:00
|
|
|
|
*
|
2010-11-16 09:14:52 -08:00
|
|
|
|
* This function should be called between ovsdb_idl_create() and the first call
|
|
|
|
|
* to ovsdb_idl_run().
|
|
|
|
|
*/
|
2010-08-11 15:41:41 -07:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_omit(struct ovsdb_idl *idl, const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_omit(&idl->data, column);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
|
|
|
|
/* Returns the most recent IDL change sequence number that caused a
|
|
|
|
|
* insert, modify or delete update to the table with class 'table_class'.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_table_get_seqno(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table
|
2017-12-15 10:59:36 -08:00
|
|
|
|
= ovsdb_idl_db_table_from_class(&idl->data, table_class);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
unsigned int max_seqno = table->change_seqno[OVSDB_IDL_CHANGE_INSERT];
|
|
|
|
|
|
|
|
|
|
if (max_seqno < table->change_seqno[OVSDB_IDL_CHANGE_MODIFY]) {
|
|
|
|
|
max_seqno = table->change_seqno[OVSDB_IDL_CHANGE_MODIFY];
|
|
|
|
|
}
|
|
|
|
|
if (max_seqno < table->change_seqno[OVSDB_IDL_CHANGE_DELETE]) {
|
|
|
|
|
max_seqno = table->change_seqno[OVSDB_IDL_CHANGE_DELETE];
|
|
|
|
|
}
|
|
|
|
|
return max_seqno;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* For each row that contains tracked columns, IDL stores the most
|
|
|
|
|
* recent IDL change sequence numbers associateed with insert, modify
|
|
|
|
|
* and delete updates to the table.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int
|
|
|
|
|
ovsdb_idl_row_get_seqno(const struct ovsdb_idl_row *row,
|
|
|
|
|
enum ovsdb_idl_change change)
|
|
|
|
|
{
|
|
|
|
|
return row->change_seqno[change];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Turns on OVSDB_IDL_TRACK for 'column' in 'idl', ensuring that
|
|
|
|
|
* all rows whose 'column' is modified are traced. Similarly, insert
|
|
|
|
|
* or delete of rows having 'column' are tracked. Clients are able
|
|
|
|
|
* to retrive the tracked rows with the ovsdb_idl_track_get_*()
|
|
|
|
|
* functions.
|
|
|
|
|
*
|
|
|
|
|
* This function should be called between ovsdb_idl_create() and
|
|
|
|
|
* the first call to ovsdb_idl_run(). The column to be tracked
|
|
|
|
|
* should have OVSDB_IDL_ALERT turned on.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_track_add_column(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (!(*ovsdb_idl_db_get_mode(&idl->data, column) & OVSDB_IDL_ALERT)) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
ovsdb_idl_add_column(idl, column);
|
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
*ovsdb_idl_db_get_mode(&idl->data, column) |= OVSDB_IDL_TRACK;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_track_add_all(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
size_t i, j;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (i = 0; i < idl->data.class_->n_tables; i++) {
|
|
|
|
|
const struct ovsdb_idl_table_class *tc = &idl->data.class_->tables[i];
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
|
|
|
|
for (j = 0; j < tc->n_columns; j++) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &tc->columns[j];
|
|
|
|
|
ovsdb_idl_track_add_column(idl, column);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'table' has any tracked column. */
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_track_is_set(struct ovsdb_idl_table *table)
|
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
for (i = 0; i < table->class_->n_columns; i++) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
if (table->modes[i] & OVSDB_IDL_TRACK) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the first tracked row in table with class 'table_class'
|
|
|
|
|
* for the specified 'idl'. Returns NULL if there are no tracked rows */
|
|
|
|
|
const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_track_get_first(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table
|
2017-12-15 10:59:36 -08:00
|
|
|
|
= ovsdb_idl_db_table_from_class(&idl->data, table_class);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (!ovs_list_is_empty(&table->track_list)) {
|
|
|
|
|
return CONTAINER_OF(ovs_list_front(&table->track_list), struct ovsdb_idl_row, track_node);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the next tracked row in table after the specified 'row'
|
|
|
|
|
* (in no particular order). Returns NULL if there are no tracked rows */
|
|
|
|
|
const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_track_get_next(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (row->track_node.next != &row->table->track_list) {
|
|
|
|
|
return CONTAINER_OF(row->track_node.next, struct ovsdb_idl_row, track_node);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-10 01:12:31 -08:00
|
|
|
|
/* Returns true if a tracked 'column' in 'row' was updated by IDL, false
|
|
|
|
|
* otherwise. The tracking data is cleared by ovsdb_idl_track_clear()
|
|
|
|
|
*
|
|
|
|
|
* Function returns false if 'column' is not tracked (see
|
|
|
|
|
* ovsdb_idl_track_add_column()).
|
|
|
|
|
*/
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_track_is_updated(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2015-12-10 01:12:31 -08:00
|
|
|
|
column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
if (row->updated && bitmap_is_set(row->updated, column_idx)) {
|
|
|
|
|
return true;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
/* Flushes the tracked rows. Client calls this function after calling
|
|
|
|
|
* ovsdb_idl_run() and read all tracked rows with the ovsdb_idl_track_get_*()
|
|
|
|
|
* functions. This is usually done at the end of the client's processing
|
|
|
|
|
* loop when it is ready to do ovsdb_idl_run() again.
|
|
|
|
|
*/
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_track_clear(struct ovsdb_idl_db *db)
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (!ovs_list_is_empty(&table->track_list)) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
|
|
|
|
LIST_FOR_EACH_SAFE(row, next, track_node, &table->track_list) {
|
2015-12-10 01:12:31 -08:00
|
|
|
|
if (row->updated) {
|
|
|
|
|
free(row->updated);
|
|
|
|
|
row->updated = NULL;
|
|
|
|
|
}
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_remove(&row->track_node);
|
|
|
|
|
ovs_list_init(&row->track_node);
|
2019-05-17 12:56:33 -07:00
|
|
|
|
if (ovsdb_idl_row_is_orphan(row) && row->tracked_old_datum) {
|
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
const struct ovsdb_idl_table_class *class =
|
|
|
|
|
row->table->class_;
|
|
|
|
|
for (size_t c = 0; c < class->n_columns; c++) {
|
|
|
|
|
ovsdb_datum_destroy(&row->tracked_old_datum[c],
|
|
|
|
|
&class->columns[c].type);
|
|
|
|
|
}
|
|
|
|
|
free(row->tracked_old_datum);
|
|
|
|
|
row->tracked_old_datum = NULL;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
free(row);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
/* Flushes the tracked rows. Client calls this function after calling
|
|
|
|
|
* ovsdb_idl_run() and read all tracked rows with the ovsdb_idl_track_get_*()
|
|
|
|
|
* functions. This is usually done at the end of the client's processing
|
|
|
|
|
* loop when it is ready to do ovsdb_idl_run() again.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_track_clear(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_db_track_clear(&idl->data);
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_send_schema_request(struct ovsdb_idl *idl,
|
|
|
|
|
struct ovsdb_idl_db *db)
|
2015-03-19 23:45:42 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_send_request(idl, jsonrpc_create_request(
|
|
|
|
|
"get_schema",
|
|
|
|
|
json_array_create_1(json_string_create(
|
|
|
|
|
db->class_->database)),
|
|
|
|
|
NULL));
|
2015-03-19 23:45:42 -07:00
|
|
|
|
}
|
2017-12-31 21:15:58 -08:00
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_send_db_change_aware(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
struct jsonrpc_msg *msg = jsonrpc_create_request(
|
|
|
|
|
"set_db_change_aware", json_array_create_1(json_boolean_create(true)),
|
|
|
|
|
NULL);
|
|
|
|
|
jsonrpc_session_send(idl->session, msg);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_check_server_db(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
const struct serverrec_database *database;
|
|
|
|
|
SERVERREC_DATABASE_FOR_EACH (database, idl) {
|
|
|
|
|
if (uuid_is_zero(&idl->cid)
|
|
|
|
|
? !strcmp(database->name, idl->data.class_->database)
|
|
|
|
|
: database->n_cid && uuid_equals(database->cid, &idl->cid)) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 5);
|
|
|
|
|
const char *server_name = jsonrpc_session_get_name(idl->session);
|
|
|
|
|
bool ok = false;
|
|
|
|
|
if (!database) {
|
|
|
|
|
VLOG_INFO_RL(&rl, "%s: server does not have %s database",
|
|
|
|
|
server_name, idl->data.class_->database);
|
2019-08-19 09:29:57 -07:00
|
|
|
|
} else if (!strcmp(database->model, "clustered")) {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
uint64_t index = database->n_index ? *database->index : 0;
|
|
|
|
|
|
|
|
|
|
if (!database->schema) {
|
|
|
|
|
VLOG_INFO("%s: clustered database server has not yet joined "
|
|
|
|
|
"cluster; trying another server", server_name);
|
|
|
|
|
} else if (!database->connected) {
|
|
|
|
|
VLOG_INFO("%s: clustered database server is disconnected "
|
|
|
|
|
"from cluster; trying another server", server_name);
|
|
|
|
|
} else if (idl->leader_only && !database->leader) {
|
|
|
|
|
VLOG_INFO("%s: clustered database server is not cluster "
|
|
|
|
|
"leader; trying another server", server_name);
|
|
|
|
|
} else if (index < idl->min_index) {
|
|
|
|
|
VLOG_WARN("%s: clustered database server has stale data; "
|
|
|
|
|
"trying another server", server_name);
|
|
|
|
|
} else {
|
2019-03-20 22:48:22 -07:00
|
|
|
|
idl->min_index = index;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ok = true;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
ok = true;
|
|
|
|
|
}
|
|
|
|
|
if (!ok) {
|
|
|
|
|
ovsdb_idl_retry(idl);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (idl->state == IDL_S_SERVER_MONITOR_COND_REQUESTED) {
|
|
|
|
|
json_destroy(idl->data.schema);
|
|
|
|
|
idl->data.schema = json_from_string(database->schema);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_send_monitor_request(idl, &idl->data,
|
|
|
|
|
OVSDB_IDL_MM_MONITOR_COND_SINCE);
|
|
|
|
|
ovsdb_idl_transition(idl, IDL_S_DATA_MONITOR_COND_SINCE_REQUESTED);
|
2017-12-31 21:15:58 -08:00
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-03-19 23:45:42 -07:00
|
|
|
|
static void
|
|
|
|
|
log_error(struct ovsdb_error *error)
|
|
|
|
|
{
|
2017-12-13 11:32:28 -08:00
|
|
|
|
char *s = ovsdb_error_to_string_free(error);
|
2015-03-19 23:45:42 -07:00
|
|
|
|
VLOG_WARN("error parsing database schema: %s", s);
|
|
|
|
|
free(s);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Frees 'schema', which is in the format returned by parse_schema(). */
|
|
|
|
|
static void
|
|
|
|
|
free_schema(struct shash *schema)
|
|
|
|
|
{
|
|
|
|
|
if (schema) {
|
|
|
|
|
struct shash_node *node, *next;
|
|
|
|
|
|
|
|
|
|
SHASH_FOR_EACH_SAFE (node, next, schema) {
|
|
|
|
|
struct sset *sset = node->data;
|
|
|
|
|
sset_destroy(sset);
|
|
|
|
|
free(sset);
|
|
|
|
|
shash_delete(schema, node);
|
|
|
|
|
}
|
|
|
|
|
shash_destroy(schema);
|
|
|
|
|
free(schema);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Parses 'schema_json', an OVSDB schema in JSON format as described in RFC
|
|
|
|
|
* 7047, to obtain the names of its rows and columns. If successful, returns
|
|
|
|
|
* an shash whose keys are table names and whose values are ssets, where each
|
|
|
|
|
* sset contains the names of its table's columns. On failure (due to a parse
|
|
|
|
|
* error), returns NULL.
|
|
|
|
|
*
|
|
|
|
|
* It would also be possible to use the general-purpose OVSDB schema parser in
|
|
|
|
|
* ovsdb-server, but that's overkill, possibly too strict for the current use
|
|
|
|
|
* case, and would require restructuring ovsdb-server to separate the schema
|
|
|
|
|
* code from the rest. */
|
|
|
|
|
static struct shash *
|
|
|
|
|
parse_schema(const struct json *schema_json)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_parser parser;
|
|
|
|
|
const struct json *tables_json;
|
|
|
|
|
struct ovsdb_error *error;
|
|
|
|
|
struct shash_node *node;
|
|
|
|
|
struct shash *schema;
|
|
|
|
|
|
|
|
|
|
ovsdb_parser_init(&parser, schema_json, "database schema");
|
|
|
|
|
tables_json = ovsdb_parser_member(&parser, "tables", OP_OBJECT);
|
|
|
|
|
error = ovsdb_parser_destroy(&parser);
|
|
|
|
|
if (error) {
|
|
|
|
|
log_error(error);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
schema = xmalloc(sizeof *schema);
|
|
|
|
|
shash_init(schema);
|
|
|
|
|
SHASH_FOR_EACH (node, json_object(tables_json)) {
|
|
|
|
|
const char *table_name = node->name;
|
|
|
|
|
const struct json *json = node->data;
|
|
|
|
|
const struct json *columns_json;
|
|
|
|
|
|
|
|
|
|
ovsdb_parser_init(&parser, json, "table schema for table %s",
|
|
|
|
|
table_name);
|
|
|
|
|
columns_json = ovsdb_parser_member(&parser, "columns", OP_OBJECT);
|
|
|
|
|
error = ovsdb_parser_destroy(&parser);
|
|
|
|
|
if (error) {
|
|
|
|
|
log_error(error);
|
|
|
|
|
free_schema(schema);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct sset *columns = xmalloc(sizeof *columns);
|
|
|
|
|
sset_init(columns);
|
|
|
|
|
|
|
|
|
|
struct shash_node *node2;
|
|
|
|
|
SHASH_FOR_EACH (node2, json_object(columns_json)) {
|
|
|
|
|
const char *column_name = node2->name;
|
|
|
|
|
sset_add(columns, column_name);
|
|
|
|
|
}
|
|
|
|
|
shash_add(schema, table_name, columns);
|
|
|
|
|
}
|
|
|
|
|
return schema;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_send_monitor_request(struct ovsdb_idl *idl, struct ovsdb_idl_db *db,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method monitor_method)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct shash *schema = parse_schema(db->schema);
|
|
|
|
|
struct json *monitor_requests = json_object_create();
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (size_t i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *tc = table->class_;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct json *monitor_request;
|
|
|
|
|
const struct sset *table_schema
|
|
|
|
|
= schema ? shash_find_data(schema, table->class_->name) : NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct json *columns
|
|
|
|
|
= table->need_table ? json_array_create_empty() : NULL;
|
|
|
|
|
for (size_t j = 0; j < tc->n_columns; j++) {
|
2010-09-02 10:09:09 -07:00
|
|
|
|
const struct ovsdb_idl_column *column = &tc->columns[j];
|
2016-10-07 09:47:43 -07:00
|
|
|
|
bool db_has_column = (table_schema &&
|
|
|
|
|
sset_contains(table_schema, column->name));
|
|
|
|
|
if (column->is_synthetic) {
|
|
|
|
|
if (db_has_column) {
|
|
|
|
|
VLOG_WARN("%s table in %s database has synthetic "
|
|
|
|
|
"column %s", table->class_->name,
|
2017-12-31 21:15:58 -08:00
|
|
|
|
db->class_->database, column->name);
|
2016-10-07 09:47:43 -07:00
|
|
|
|
}
|
|
|
|
|
} else if (table->modes[j] & OVSDB_IDL_MONITOR) {
|
|
|
|
|
if (table_schema && !db_has_column) {
|
2015-03-19 23:45:42 -07:00
|
|
|
|
VLOG_WARN("%s table in %s database lacks %s column "
|
|
|
|
|
"(database needs upgrade?)",
|
2017-12-15 10:59:36 -08:00
|
|
|
|
table->class_->name, db->class_->database,
|
2015-03-19 23:45:42 -07:00
|
|
|
|
column->name);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2010-11-16 09:14:52 -08:00
|
|
|
|
if (!columns) {
|
|
|
|
|
columns = json_array_create_empty();
|
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
json_array_add(columns, json_string_create(column->name));
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2010-11-16 09:14:52 -08:00
|
|
|
|
|
|
|
|
|
if (columns) {
|
2015-03-19 23:45:42 -07:00
|
|
|
|
if (schema && !table_schema) {
|
|
|
|
|
VLOG_WARN("%s database lacks %s table "
|
|
|
|
|
"(database needs upgrade?)",
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->class_->database, table->class_->name);
|
2015-03-19 23:45:42 -07:00
|
|
|
|
json_destroy(columns);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-16 09:14:52 -08:00
|
|
|
|
monitor_request = json_object_create();
|
|
|
|
|
json_object_put(monitor_request, "columns", columns);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
/* Always use acked conditions when requesting
|
|
|
|
|
* monitor_cond/monitor_cond_since.
|
|
|
|
|
*/
|
|
|
|
|
const struct ovsdb_idl_condition *cond = table->ack_cond;
|
2019-02-28 09:15:19 -08:00
|
|
|
|
if ((monitor_method == OVSDB_IDL_MM_MONITOR_COND ||
|
|
|
|
|
monitor_method == OVSDB_IDL_MM_MONITOR_COND_SINCE) &&
|
ovsdb-idl: Avoid inconsistent IDL state with OVSDB_MONITOR_V3.
Assuming an ovsdb client connected to a database using OVSDB_MONITOR_V3
(i.e., "monitor_cond_since" method) with the initial monitor condition
MC1.
Assuming the following two transactions are executed on the
ovsdb-server:
TXN1: "insert record R1 in table T1"
TXN2: "insert record R2 in table T2"
If the client's monitor condition MC1 for table T2 matches R2 then the
client will receive the following update3 message:
method="update3", "insert record R2 in table T2", last-txn-id=TXN2
At this point, if the presence of the new record R2 in the IDL triggers
the client to update its monitor condition to MC2 and add a clause for
table T1 which matches R1, a monitor_cond_change message is sent to the
server:
method="monitor_cond_change", "clauses from MC2"
In normal operation the ovsdb-server will reply with a new update3
message of the form:
method="update3", "insert record R1 in table T1", last-txn-id=TXN2
However, if the connection drops in the meantime, this last update might
get lost.
It might happen that during the reconnect a new transaction happens
that modifies the original record R1:
TXN3: "modify record R1 in table T1"
When the client reconnects, it will try to perform a fast resync by
sending:
method="monitor_cond_since", "clauses from MC2", last-txn-id=TXN2
Because TXN2 is still in the ovsdb-server transaction history, the
server replies with the changes from the most recent transactions only,
i.e., TXN3:
result="true", last-txbb-id=TXN3, "modify record R1 in table T1"
This causes the IDL on the client in to end up in an inconsistent
state because it has never seen the update that created R1.
Such a scenario is described in:
https://bugzilla.redhat.com/show_bug.cgi?id=1808580#c22
To avoid this issue, the IDL will now maintain (up to) 3 different
types of conditions for each DB table:
- new_cond: condition that has been set by the IDL client but has
not yet been sent to the server through monitor_cond_change.
- req_cond: condition that has been sent to the server but the reply
acknowledging the change hasn't been received yet.
- ack_cond: condition that has been acknowledged by the server.
Whenever the IDL FSM is restarted (e.g., voluntary or involuntary
disconnect):
- if there is a known last_id txn-id the code ensures that new_cond
will contain the most recent condition set by the IDL client
(either req_cond if there was a request in flight, or new_cond
if the IDL client set a condition while the IDL was disconnected)
- if there is no known last_id txn-id the code ensures that ack_cond will
contain the most recent conditions set by the IDL client regardless
whether they were acked by the server or not.
When monitor_cond_since/monitor_cond requests are sent they will
always include ack_cond and if new_cond is not NULL a follow up
monitor_cond_change will be generated afterwards.
On the other hand ovsdb_idl_db_set_condition() will always modify new_cond.
This ensures that updates of type "insert" that happened before the last
transaction known by the IDL but didn't match old monitor conditions are
sent upon reconnect if the monitor condition has changed to include them
in the meantime.
Fixes: 403a6a0cb003 ("ovsdb-idl: Fast resync from server when connection reset.")
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Acked-by: Han Zhou <hzhou@ovn.org>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
2020-05-28 14:32:31 +02:00
|
|
|
|
cond && !ovsdb_idl_condition_is_true(cond)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
json_object_put(monitor_request, "where",
|
|
|
|
|
ovsdb_idl_condition_to_json(cond));
|
2016-07-18 11:45:58 +03:00
|
|
|
|
}
|
2018-03-07 10:26:35 -08:00
|
|
|
|
json_object_put(monitor_requests, tc->name,
|
|
|
|
|
json_array_create_1(monitor_request));
|
2010-11-16 09:14:52 -08:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2015-03-19 23:45:42 -07:00
|
|
|
|
free_schema(schema);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2019-02-28 09:15:19 -08:00
|
|
|
|
struct json *params = json_array_create_3(
|
|
|
|
|
json_string_create(db->class_->database),
|
|
|
|
|
json_clone(db->monitor_id),
|
|
|
|
|
monitor_requests);
|
|
|
|
|
const char *method;
|
|
|
|
|
switch (monitor_method) {
|
|
|
|
|
case OVSDB_IDL_MM_MONITOR:
|
|
|
|
|
method = "monitor";
|
|
|
|
|
break;
|
|
|
|
|
case OVSDB_IDL_MM_MONITOR_COND:
|
|
|
|
|
method = "monitor_cond";
|
|
|
|
|
break;
|
|
|
|
|
case OVSDB_IDL_MM_MONITOR_COND_SINCE:
|
|
|
|
|
method = "monitor_cond_since";
|
|
|
|
|
struct json *json_last_id = json_string_create_nocopy(
|
2019-02-28 09:15:20 -08:00
|
|
|
|
xasprintf(UUID_FMT, UUID_ARGS(&db->last_id)));
|
2019-02-28 09:15:19 -08:00
|
|
|
|
json_array_add(params, json_last_id);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
OVS_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_send_request(idl, jsonrpc_create_request(method, params, NULL));
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
log_parse_update_error(struct ovsdb_error *error)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2017-12-08 13:24:27 -08:00
|
|
|
|
if (!VLOG_DROP_WARN(&syntax_rl)) {
|
|
|
|
|
char *s = ovsdb_error_to_string(error);
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "%s", s);
|
|
|
|
|
free(s);
|
|
|
|
|
}
|
|
|
|
|
ovsdb_error_destroy(error);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_parse_monitor_reply(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct json *result,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method method)
|
2015-10-15 14:09:37 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->change_seqno++;
|
2019-02-28 09:15:19 -08:00
|
|
|
|
const struct json *table_updates = result;
|
2019-02-28 09:15:20 -08:00
|
|
|
|
bool clear_db = true;
|
2019-02-28 09:15:19 -08:00
|
|
|
|
if (method == OVSDB_IDL_MM_MONITOR_COND_SINCE) {
|
|
|
|
|
if (result->type != JSON_ARRAY || result->array.n != 3) {
|
|
|
|
|
struct ovsdb_error *error = ovsdb_syntax_error(result, NULL,
|
|
|
|
|
"Response of monitor_cond_since must "
|
|
|
|
|
"be an array with 3 elements.");
|
|
|
|
|
log_parse_update_error(error);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-28 09:15:20 -08:00
|
|
|
|
bool found = json_boolean(result->array.elems[0]);
|
|
|
|
|
if (found) {
|
|
|
|
|
clear_db = false;
|
|
|
|
|
}
|
2019-02-28 09:15:19 -08:00
|
|
|
|
|
2019-02-28 09:15:20 -08:00
|
|
|
|
const char *last_id = json_string(result->array.elems[1]);
|
|
|
|
|
if (!uuid_from_string(&db->last_id, last_id)) {
|
|
|
|
|
struct ovsdb_error *error = ovsdb_syntax_error(result, NULL,
|
|
|
|
|
"Last-id %s is not in UUID format.",
|
|
|
|
|
last_id);
|
|
|
|
|
log_parse_update_error(error);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
table_updates = result->array.elems[2];
|
|
|
|
|
}
|
|
|
|
|
if (clear_db) {
|
|
|
|
|
ovsdb_idl_db_clear(db);
|
2019-02-28 09:15:19 -08:00
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_db_parse_update(db, table_updates, method);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_db_parse_update_rpc(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct jsonrpc_msg *msg)
|
2015-10-15 14:09:37 -07:00
|
|
|
|
{
|
2019-02-28 09:15:19 -08:00
|
|
|
|
if (msg->type != JSONRPC_NOTIFY) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
enum ovsdb_idl_monitor_method mm;
|
|
|
|
|
uint8_t n;
|
|
|
|
|
if (!strcmp(msg->method, "update")) {
|
|
|
|
|
mm = OVSDB_IDL_MM_MONITOR;
|
|
|
|
|
n = 2;
|
|
|
|
|
} else if (!strcmp(msg->method, "update2")) {
|
|
|
|
|
mm = OVSDB_IDL_MM_MONITOR_COND;
|
|
|
|
|
n = 2;
|
|
|
|
|
} else if (!strcmp(msg->method, "update3")) {
|
|
|
|
|
mm = OVSDB_IDL_MM_MONITOR_COND_SINCE;
|
|
|
|
|
n = 3;
|
|
|
|
|
} else {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct json *params = msg->params;
|
|
|
|
|
if (params->type != JSON_ARRAY || params->array.n != n) {
|
|
|
|
|
struct ovsdb_error *error = ovsdb_syntax_error(params, NULL,
|
|
|
|
|
"%s must be an array with %u elements.",
|
|
|
|
|
msg->method, n);
|
|
|
|
|
log_parse_update_error(error);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!json_equal(params->array.elems[0], db->monitor_id)) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct json *table_updates = params->array.elems[1];
|
|
|
|
|
if (!strcmp(msg->method, "update3")) {
|
|
|
|
|
table_updates = params->array.elems[2];
|
2019-02-28 09:15:20 -08:00
|
|
|
|
const char *last_id = json_string(params->array.elems[1]);
|
|
|
|
|
if (!uuid_from_string(&db->last_id, last_id)) {
|
|
|
|
|
struct ovsdb_error *error = ovsdb_syntax_error(params, NULL,
|
|
|
|
|
"Last-id %s is not in UUID format.",
|
|
|
|
|
last_id);
|
|
|
|
|
log_parse_update_error(error);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2019-02-28 09:15:19 -08:00
|
|
|
|
ovsdb_idl_db_parse_update(db, table_updates, mm);
|
|
|
|
|
return true;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2017-12-31 21:15:58 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_handle_monitor_canceled(struct ovsdb_idl *idl,
|
|
|
|
|
struct ovsdb_idl_db *db,
|
|
|
|
|
const struct jsonrpc_msg *msg)
|
|
|
|
|
{
|
|
|
|
|
if (msg->type != JSONRPC_NOTIFY
|
|
|
|
|
|| strcmp(msg->method, "monitor_canceled")
|
|
|
|
|
|| msg->params->type != JSON_ARRAY
|
2018-05-24 10:32:59 -07:00
|
|
|
|
|| msg->params->array.n != 1
|
|
|
|
|
|| !json_equal(msg->params->array.elems[0], db->monitor_id)) {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
db->monitoring = OVSDB_IDL_NOT_MONITORING;
|
|
|
|
|
|
|
|
|
|
/* Cancel the other monitor and restart the FSM from the top.
|
|
|
|
|
*
|
|
|
|
|
* Maybe a more sophisticated response would be better in some cases, but
|
|
|
|
|
* it doesn't seem worth optimizing yet. (Although this is already more
|
|
|
|
|
* sophisticated than just dropping the connection and reconnecting.) */
|
|
|
|
|
struct ovsdb_idl_db *other_db
|
|
|
|
|
= db == &idl->data ? &idl->server : &idl->data;
|
|
|
|
|
if (other_db->monitoring) {
|
|
|
|
|
jsonrpc_session_send(
|
|
|
|
|
idl->session,
|
|
|
|
|
jsonrpc_create_request(
|
|
|
|
|
"monitor_cancel",
|
|
|
|
|
json_array_create_1(json_clone(other_db->monitor_id)), NULL));
|
|
|
|
|
other_db->monitoring = OVSDB_IDL_NOT_MONITORING;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_restart_fsm(idl);
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_error *
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_parse_update__(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct json *table_updates,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method method)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
|
|
|
|
const struct shash_node *tables_node;
|
2019-02-28 09:15:19 -08:00
|
|
|
|
const char *version_suffix;
|
|
|
|
|
switch (method) {
|
|
|
|
|
case OVSDB_IDL_MM_MONITOR:
|
|
|
|
|
version_suffix = "";
|
|
|
|
|
break;
|
|
|
|
|
case OVSDB_IDL_MM_MONITOR_COND:
|
|
|
|
|
case OVSDB_IDL_MM_MONITOR_COND_SINCE:
|
|
|
|
|
version_suffix = "2";
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
OVS_NOT_REACHED();
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
|
|
|
|
if (table_updates->type != JSON_OBJECT) {
|
|
|
|
|
return ovsdb_syntax_error(table_updates, NULL,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
"<table_updates%s> is not an object",
|
|
|
|
|
version_suffix);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
SHASH_FOR_EACH (tables_node, json_object(table_updates)) {
|
|
|
|
|
const struct json *table_update = tables_node->data;
|
|
|
|
|
const struct shash_node *table_node;
|
|
|
|
|
struct ovsdb_idl_table *table;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
table = shash_find_data(&db->table_by_name, tables_node->name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (!table) {
|
|
|
|
|
return ovsdb_syntax_error(
|
|
|
|
|
table_updates, NULL,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
"<table_updates%s> includes unknown table \"%s\"",
|
|
|
|
|
version_suffix, tables_node->name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (table_update->type != JSON_OBJECT) {
|
|
|
|
|
return ovsdb_syntax_error(table_update, NULL,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
"<table_update%s> for table \"%s\" is "
|
2015-10-15 14:09:37 -07:00
|
|
|
|
"not an object",
|
2017-12-15 10:59:36 -08:00
|
|
|
|
version_suffix, table->class_->name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
SHASH_FOR_EACH (table_node, json_object(table_update)) {
|
|
|
|
|
const struct json *row_update = table_node->data;
|
|
|
|
|
struct uuid uuid;
|
|
|
|
|
|
|
|
|
|
if (!uuid_from_string(&uuid, table_node->name)) {
|
|
|
|
|
return ovsdb_syntax_error(table_update, NULL,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
"<table_update%s> for table \"%s\" "
|
2009-12-02 11:26:15 -08:00
|
|
|
|
"contains bad UUID "
|
|
|
|
|
"\"%s\" as member name",
|
2017-12-15 10:59:36 -08:00
|
|
|
|
version_suffix,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
table->class_->name,
|
2009-12-02 11:26:15 -08:00
|
|
|
|
table_node->name);
|
|
|
|
|
}
|
|
|
|
|
if (row_update->type != JSON_OBJECT) {
|
|
|
|
|
return ovsdb_syntax_error(row_update, NULL,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
"<table_update%s> for table \"%s\" "
|
|
|
|
|
"contains <row_update%s> for %s "
|
|
|
|
|
"that is not an object",
|
|
|
|
|
version_suffix, table->class_->name,
|
|
|
|
|
version_suffix, table_node->name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2019-02-28 09:15:19 -08:00
|
|
|
|
if (method == OVSDB_IDL_MM_MONITOR_COND ||
|
|
|
|
|
method == OVSDB_IDL_MM_MONITOR_COND_SINCE) {
|
2015-10-15 14:09:37 -07:00
|
|
|
|
const char *ops[] = {"modify", "insert", "delete", "initial"};
|
|
|
|
|
const char *operation;
|
|
|
|
|
const struct json *row;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(ops); i++) {
|
|
|
|
|
operation = ops[i];
|
|
|
|
|
row = shash_find_data(json_object(row_update), operation);
|
|
|
|
|
|
|
|
|
|
if (row) {
|
|
|
|
|
if (ovsdb_idl_process_update2(table, &uuid, operation,
|
|
|
|
|
row)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->change_seqno++;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* row_update2 should contain one of the objects */
|
|
|
|
|
if (i == ARRAY_SIZE(ops)) {
|
|
|
|
|
return ovsdb_syntax_error(row_update, NULL,
|
|
|
|
|
"<row_update2> includes unknown "
|
|
|
|
|
"object");
|
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
} else {
|
|
|
|
|
const struct json *old_json, *new_json;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
old_json = shash_find_data(json_object(row_update), "old");
|
|
|
|
|
new_json = shash_find_data(json_object(row_update), "new");
|
|
|
|
|
if (old_json && old_json->type != JSON_OBJECT) {
|
|
|
|
|
return ovsdb_syntax_error(old_json, NULL,
|
|
|
|
|
"\"old\" <row> is not object");
|
|
|
|
|
} else if (new_json && new_json->type != JSON_OBJECT) {
|
|
|
|
|
return ovsdb_syntax_error(new_json, NULL,
|
|
|
|
|
"\"new\" <row> is not object");
|
|
|
|
|
} else if ((old_json != NULL) + (new_json != NULL)
|
|
|
|
|
!= shash_count(json_object(row_update))) {
|
|
|
|
|
return ovsdb_syntax_error(row_update, NULL,
|
|
|
|
|
"<row-update> contains "
|
|
|
|
|
"unexpected member");
|
|
|
|
|
} else if (!old_json && !new_json) {
|
|
|
|
|
return ovsdb_syntax_error(row_update, NULL,
|
|
|
|
|
"<row-update> missing \"old\" "
|
|
|
|
|
"and \"new\" members");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ovsdb_idl_process_update(table, &uuid, old_json,
|
|
|
|
|
new_json)) {
|
|
|
|
|
db->change_seqno++;
|
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_db_parse_update(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct json *table_updates,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
enum ovsdb_idl_monitor_method method)
|
2017-12-15 10:59:36 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_error *error = ovsdb_idl_db_parse_update__(db, table_updates,
|
2019-02-28 09:15:19 -08:00
|
|
|
|
method);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (error) {
|
|
|
|
|
log_parse_update_error(error);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_get_row(struct ovsdb_idl_table *table, const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (row, hmap_node, uuid_hash(uuid), &table->rows) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (uuid_equals(&row->uuid, uuid)) {
|
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-11 15:41:41 -07:00
|
|
|
|
/* Returns true if a column with mode OVSDB_IDL_MODE_RW changed, false
|
|
|
|
|
* otherwise. */
|
|
|
|
|
static bool
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_process_update(struct ovsdb_idl_table *table,
|
|
|
|
|
const struct uuid *uuid, const struct json *old,
|
|
|
|
|
const struct json *new)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
|
|
|
|
|
row = ovsdb_idl_get_row(table, uuid);
|
|
|
|
|
if (!new) {
|
|
|
|
|
/* Delete row. */
|
|
|
|
|
if (row && !ovsdb_idl_row_is_orphan(row)) {
|
|
|
|
|
/* XXX perhaps we should check the 'old' values? */
|
|
|
|
|
ovsdb_idl_delete_row(row);
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot delete missing row "UUID_FMT" "
|
|
|
|
|
"from table %s",
|
2017-08-11 11:06:44 -07:00
|
|
|
|
UUID_ARGS(uuid), table->class_->name);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
return false;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
} else if (!old) {
|
|
|
|
|
/* Insert row. */
|
|
|
|
|
if (!row) {
|
|
|
|
|
ovsdb_idl_insert_row(ovsdb_idl_row_create(table, uuid), new);
|
|
|
|
|
} else if (ovsdb_idl_row_is_orphan(row)) {
|
|
|
|
|
ovsdb_idl_insert_row(row, new);
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot add existing row "UUID_FMT" to "
|
2017-08-11 11:06:44 -07:00
|
|
|
|
"table %s", UUID_ARGS(uuid), table->class_->name);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
return ovsdb_idl_modify_row(row, new);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/* Modify row. */
|
|
|
|
|
if (row) {
|
|
|
|
|
/* XXX perhaps we should check the 'old' values? */
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
2010-08-11 15:41:41 -07:00
|
|
|
|
return ovsdb_idl_modify_row(row, new);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot modify missing but "
|
|
|
|
|
"referenced row "UUID_FMT" in table %s",
|
2017-08-11 11:06:44 -07:00
|
|
|
|
UUID_ARGS(uuid), table->class_->name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_insert_row(row, new);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot modify missing row "UUID_FMT" "
|
2017-08-11 11:06:44 -07:00
|
|
|
|
"in table %s", UUID_ARGS(uuid), table->class_->name);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_insert_row(ovsdb_idl_row_create(table, uuid), new);
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
|
|
|
|
|
return true;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-08-11 15:41:41 -07:00
|
|
|
|
/* Returns true if a column with mode OVSDB_IDL_MODE_RW changed, false
|
|
|
|
|
* otherwise. */
|
|
|
|
|
static bool
|
2015-10-15 14:09:37 -07:00
|
|
|
|
ovsdb_idl_process_update2(struct ovsdb_idl_table *table,
|
|
|
|
|
const struct uuid *uuid,
|
|
|
|
|
const char *operation,
|
|
|
|
|
const struct json *json_row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
|
|
|
|
|
row = ovsdb_idl_get_row(table, uuid);
|
|
|
|
|
if (!strcmp(operation, "delete")) {
|
|
|
|
|
/* Delete row. */
|
|
|
|
|
if (row && !ovsdb_idl_row_is_orphan(row)) {
|
|
|
|
|
ovsdb_idl_delete_row(row);
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot delete missing row "UUID_FMT" "
|
|
|
|
|
"from table %s",
|
2017-08-11 11:06:44 -07:00
|
|
|
|
UUID_ARGS(uuid), table->class_->name);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
} else if (!strcmp(operation, "insert") || !strcmp(operation, "initial")) {
|
|
|
|
|
/* Insert row. */
|
|
|
|
|
if (!row) {
|
|
|
|
|
ovsdb_idl_insert_row(ovsdb_idl_row_create(table, uuid), json_row);
|
|
|
|
|
} else if (ovsdb_idl_row_is_orphan(row)) {
|
|
|
|
|
ovsdb_idl_insert_row(row, json_row);
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot add existing row "UUID_FMT" to "
|
2017-08-11 11:06:44 -07:00
|
|
|
|
"table %s", UUID_ARGS(uuid), table->class_->name);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
ovsdb_idl_delete_row(row);
|
|
|
|
|
ovsdb_idl_insert_row(row, json_row);
|
|
|
|
|
}
|
|
|
|
|
} else if (!strcmp(operation, "modify")) {
|
|
|
|
|
/* Modify row. */
|
|
|
|
|
if (row) {
|
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
|
|
|
|
return ovsdb_idl_modify_row_by_diff(row, json_row);
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot modify missing but "
|
|
|
|
|
"referenced row "UUID_FMT" in table %s",
|
2017-08-11 11:06:44 -07:00
|
|
|
|
UUID_ARGS(uuid), table->class_->name);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "cannot modify missing row "UUID_FMT" "
|
2017-08-11 11:06:44 -07:00
|
|
|
|
"in table %s", UUID_ARGS(uuid), table->class_->name);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2017-12-08 13:24:27 -08:00
|
|
|
|
VLOG_WARN_RL(&semantic_rl, "unknown operation %s to "
|
|
|
|
|
"table %s", operation, table->class_->name);
|
|
|
|
|
return false;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-13 10:48:03 -07:00
|
|
|
|
/* Recursively add rows to tracked change lists for current row
|
|
|
|
|
* and the rows that reference this row. */
|
|
|
|
|
static void
|
|
|
|
|
add_tracked_change_for_references(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (ovs_list_is_empty(&row->track_node) &&
|
|
|
|
|
ovsdb_idl_track_is_set(row->table)) {
|
|
|
|
|
ovs_list_push_back(&row->table->track_list,
|
|
|
|
|
&row->track_node);
|
2018-10-05 12:14:23 -07:00
|
|
|
|
row->change_seqno[OVSDB_IDL_CHANGE_MODIFY]
|
|
|
|
|
= row->table->change_seqno[OVSDB_IDL_CHANGE_MODIFY]
|
|
|
|
|
= row->table->db->change_seqno + 1;
|
2018-08-13 10:48:03 -07:00
|
|
|
|
|
|
|
|
|
const struct ovsdb_idl_arc *arc;
|
|
|
|
|
LIST_FOR_EACH (arc, dst_node, &row->dst_arcs) {
|
|
|
|
|
add_tracked_change_for_references(arc->src);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2015-10-15 14:09:37 -07:00
|
|
|
|
/* Returns true if a column with mode OVSDB_IDL_MODE_RW changed, false
|
|
|
|
|
* otherwise.
|
|
|
|
|
*
|
|
|
|
|
* Change 'row' either with the content of 'row_json' or by apply 'diff'.
|
|
|
|
|
* Caller needs to provide either valid 'row_json' or 'diff', but not
|
|
|
|
|
* both. */
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_change__(struct ovsdb_idl_row *row, const struct json *row_json,
|
|
|
|
|
const struct json *diff_json,
|
|
|
|
|
enum ovsdb_idl_change change)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = table->class_;
|
2015-10-15 14:09:37 -07:00
|
|
|
|
struct shash_node *node;
|
|
|
|
|
bool changed = false;
|
|
|
|
|
bool apply_diff = diff_json != NULL;
|
|
|
|
|
const struct json *json = apply_diff ? diff_json : row_json;
|
2010-08-11 15:29:36 -07:00
|
|
|
|
|
2015-10-15 14:09:37 -07:00
|
|
|
|
SHASH_FOR_EACH (node, json_object(json)) {
|
|
|
|
|
const char *column_name = node->name;
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
struct ovsdb_datum datum;
|
|
|
|
|
struct ovsdb_error *error;
|
|
|
|
|
unsigned int column_idx;
|
|
|
|
|
struct ovsdb_datum *old;
|
|
|
|
|
|
|
|
|
|
column = shash_find_data(&table->columns, column_name);
|
|
|
|
|
if (!column) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "unknown column %s updating row "UUID_FMT,
|
|
|
|
|
column_name, UUID_ARGS(&row->uuid));
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
column_idx = column - table->class_->columns;
|
2017-08-11 11:06:47 -07:00
|
|
|
|
old = &row->old_datum[column_idx];
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
|
|
|
|
error = NULL;
|
|
|
|
|
if (apply_diff) {
|
|
|
|
|
struct ovsdb_datum diff;
|
|
|
|
|
|
|
|
|
|
ovs_assert(!row_json);
|
|
|
|
|
error = ovsdb_transient_datum_from_json(&diff, &column->type,
|
|
|
|
|
node->data);
|
|
|
|
|
if (!error) {
|
|
|
|
|
error = ovsdb_datum_apply_diff(&datum, old, &diff,
|
|
|
|
|
&column->type);
|
|
|
|
|
ovsdb_datum_destroy(&diff, &column->type);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
ovs_assert(!diff_json);
|
|
|
|
|
error = ovsdb_datum_from_json(&datum, &column->type, node->data,
|
|
|
|
|
NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!error) {
|
2010-08-11 15:29:36 -07:00
|
|
|
|
if (!ovsdb_datum_equals(old, &datum, &column->type)) {
|
|
|
|
|
ovsdb_datum_swap(old, &datum);
|
2010-11-16 09:14:52 -08:00
|
|
|
|
if (table->modes[column_idx] & OVSDB_IDL_ALERT) {
|
2010-08-11 15:29:36 -07:00
|
|
|
|
changed = true;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
row->change_seqno[change]
|
|
|
|
|
= row->table->change_seqno[change]
|
2017-12-15 10:59:36 -08:00
|
|
|
|
= row->table->db->change_seqno + 1;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
if (table->modes[column_idx] & OVSDB_IDL_TRACK) {
|
2018-08-13 10:48:03 -07:00
|
|
|
|
add_tracked_change_for_references(row);
|
2015-12-10 01:12:31 -08:00
|
|
|
|
if (!row->updated) {
|
|
|
|
|
row->updated = bitmap_allocate(class->n_columns);
|
|
|
|
|
}
|
|
|
|
|
bitmap_set1(row->updated, column_idx);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
2010-08-11 15:29:36 -07:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
/* Didn't really change but the OVSDB monitor protocol always
|
|
|
|
|
* includes every value in a row. */
|
2010-08-11 15:41:41 -07:00
|
|
|
|
}
|
2010-08-11 15:29:36 -07:00
|
|
|
|
|
|
|
|
|
ovsdb_datum_destroy(&datum, &column->type);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
} else {
|
2017-12-13 11:32:28 -08:00
|
|
|
|
char *s = ovsdb_error_to_string_free(error);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "error parsing column %s in row "UUID_FMT
|
|
|
|
|
" in table %s: %s", column_name,
|
2017-08-11 11:06:44 -07:00
|
|
|
|
UUID_ARGS(&row->uuid), table->class_->name, s);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
free(s);
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-08-11 15:41:41 -07:00
|
|
|
|
return changed;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2015-10-15 14:09:37 -07:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_update(struct ovsdb_idl_row *row, const struct json *row_json,
|
|
|
|
|
enum ovsdb_idl_change change)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_row_change__(row, row_json, NULL, change);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_apply_diff(struct ovsdb_idl_row *row,
|
|
|
|
|
const struct json *diff_json,
|
|
|
|
|
enum ovsdb_idl_change change)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_row_change__(row, NULL, diff_json, change);
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-03 09:54:43 -08:00
|
|
|
|
/* When a row A refers to row B through a column with a "refTable" constraint,
|
|
|
|
|
* but row B does not exist, row B is called an "orphan row". Orphan rows
|
|
|
|
|
* should not persist, because the database enforces referential integrity, but
|
|
|
|
|
* they can appear transiently as changes from the database are received (the
|
|
|
|
|
* database doesn't try to topologically sort them and circular references mean
|
|
|
|
|
* it isn't always possible anyhow).
|
|
|
|
|
*
|
|
|
|
|
* This function returns true if 'row' is an orphan row, otherwise false.
|
|
|
|
|
*/
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_is_orphan(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
return !row->old_datum && !row->new_datum;
|
2010-03-03 09:54:43 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-03-03 09:59:47 -08:00
|
|
|
|
/* Returns true if 'row' is conceptually part of the database as modified by
|
|
|
|
|
* the current transaction (if any), false otherwise.
|
|
|
|
|
*
|
|
|
|
|
* This function will return true if 'row' is not an orphan (see the comment on
|
|
|
|
|
* ovsdb_idl_row_is_orphan()) and:
|
|
|
|
|
*
|
|
|
|
|
* - 'row' exists in the database and has not been deleted within the
|
|
|
|
|
* current transaction (if any).
|
|
|
|
|
*
|
|
|
|
|
* - 'row' was inserted within the current transaction and has not been
|
|
|
|
|
* deleted. (In the latter case you should not have passed 'row' in at
|
|
|
|
|
* all, because ovsdb_idl_txn_delete() freed it.)
|
|
|
|
|
*
|
|
|
|
|
* This function will return false if 'row' is an orphan or if 'row' was
|
|
|
|
|
* deleted within the current transaction.
|
|
|
|
|
*/
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_row_exists(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:46 -07:00
|
|
|
|
return row->new_datum != NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_parse(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2019-05-17 12:56:33 -07:00
|
|
|
|
if (row->parsed) {
|
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
|
|
|
|
const struct ovsdb_idl_column *c = &class->columns[i];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
(c->parse)(row, &row->old_datum[i]);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
2019-05-17 12:56:33 -07:00
|
|
|
|
row->parsed = true;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_unparse(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2019-05-17 12:56:33 -07:00
|
|
|
|
if (!row->parsed) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
|
|
|
|
const struct ovsdb_idl_column *c = &class->columns[i];
|
|
|
|
|
(c->unparse)(row);
|
|
|
|
|
}
|
2019-05-17 12:56:33 -07:00
|
|
|
|
row->parsed = false;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
|
|
|
|
/* The OVSDB-IDL Compound Indexes feature allows for the creation of custom
|
|
|
|
|
* table indexes over one or more columns in the IDL. These indexes provide
|
|
|
|
|
* the ability to retrieve rows matching a particular search criteria and to
|
|
|
|
|
* iterate over a subset of rows in a defined order.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Generic comparator that can compare each index, using the custom
|
|
|
|
|
* configuration (an struct ovsdb_idl_index) passed to it.
|
|
|
|
|
* Not intended for direct usage.
|
|
|
|
|
*/
|
|
|
|
|
static int
|
|
|
|
|
ovsdb_idl_index_generic_comparer(const void *a,
|
|
|
|
|
const void *b, const void *conf)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
const struct ovsdb_idl_index *index;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
|
|
index = CONST_CAST(struct ovsdb_idl_index *, conf);
|
|
|
|
|
|
|
|
|
|
if (a == b) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < index->n_columns; i++) {
|
|
|
|
|
int val;
|
|
|
|
|
if (index->columns[i].comparer) {
|
|
|
|
|
val = index->columns[i].comparer(a, b);
|
|
|
|
|
} else {
|
|
|
|
|
column = index->columns[i].column;
|
|
|
|
|
const struct ovsdb_idl_row *row_a, *row_b;
|
|
|
|
|
row_a = CONST_CAST(struct ovsdb_idl_row *, a);
|
|
|
|
|
row_b = CONST_CAST(struct ovsdb_idl_row *, b);
|
|
|
|
|
const struct ovsdb_datum *datum_a, *datum_b;
|
|
|
|
|
datum_a = ovsdb_idl_read(row_a, column);
|
|
|
|
|
datum_b = ovsdb_idl_read(row_b, column);
|
|
|
|
|
val = ovsdb_datum_compare_3way(datum_a, datum_b, &column->type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (val) {
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return index->columns[i].order == OVSDB_INDEX_ASC ? val : -val;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If ins_del is true then a row is being inserted into or deleted from
|
|
|
|
|
* the index list. In this case, we augment the search key with
|
|
|
|
|
* additional values (row UUID and memory address) to create a unique
|
|
|
|
|
* search key in order to locate the correct entry efficiently and to
|
|
|
|
|
* ensure that the correct entry is deleted in the case of a "delete"
|
|
|
|
|
* operation.
|
|
|
|
|
*/
|
|
|
|
|
if (index->ins_del) {
|
|
|
|
|
const struct ovsdb_idl_row *row_a, *row_b;
|
|
|
|
|
|
|
|
|
|
row_a = (const struct ovsdb_idl_row *) a;
|
|
|
|
|
row_b = (const struct ovsdb_idl_row *) b;
|
|
|
|
|
int value = uuid_compare_3way(&row_a->uuid, &row_b->uuid);
|
|
|
|
|
|
|
|
|
|
return value ? value : (a < b) - (a > b);
|
|
|
|
|
} else {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct ovsdb_idl_index *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_db_index_create(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_index_column *columns,
|
|
|
|
|
size_t n)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovs_assert(n > 0);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_index *index = xzalloc(sizeof *index);
|
|
|
|
|
|
|
|
|
|
index->table = ovsdb_idl_table_from_column(db, columns[0].column);
|
|
|
|
|
for (size_t i = 0; i < n; i++) {
|
|
|
|
|
const struct ovsdb_idl_index_column *c = &columns[i];
|
|
|
|
|
ovs_assert(ovsdb_idl_table_from_column(db, c->column) == index->table);
|
|
|
|
|
ovs_assert(*ovsdb_idl_db_get_mode(db, c->column) & OVSDB_IDL_MONITOR);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
index->columns = xmemdup(columns, n * sizeof *columns);
|
|
|
|
|
index->n_columns = n;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
index->skiplist = skiplist_create(ovsdb_idl_index_generic_comparer, index);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
|
|
|
|
|
ovs_list_push_back(&index->table->indexes, &index->node);
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
return index;
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
/* Creates a new index for the given 'idl' and with the 'n' specified
|
|
|
|
|
* 'columns'.
|
|
|
|
|
*
|
|
|
|
|
* All indexes must be created before the first call to ovsdb_idl_run(). */
|
|
|
|
|
struct ovsdb_idl_index *
|
|
|
|
|
ovsdb_idl_index_create(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_index_column *columns,
|
|
|
|
|
size_t n)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_db_index_create(&idl->data, columns, n);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_index *
|
|
|
|
|
ovsdb_idl_index_create1(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column1)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_index_column columns[] = {
|
|
|
|
|
{ .column = column1 },
|
|
|
|
|
};
|
|
|
|
|
return ovsdb_idl_index_create(idl, columns, ARRAY_SIZE(columns));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_index *
|
|
|
|
|
ovsdb_idl_index_create2(struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_column *column1,
|
|
|
|
|
const struct ovsdb_idl_column *column2)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_index_column columns[] = {
|
|
|
|
|
{ .column = column1 },
|
|
|
|
|
{ .column = column2 },
|
|
|
|
|
};
|
|
|
|
|
return ovsdb_idl_index_create(idl, columns, ARRAY_SIZE(columns));
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_destroy_indexes(struct ovsdb_idl_table *table)
|
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_index *index, *next;
|
|
|
|
|
LIST_FOR_EACH_SAFE (index, next, node, &table->indexes) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
skiplist_destroy(index->skiplist, NULL);
|
|
|
|
|
free(index->columns);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
free(index);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_add_to_indexes(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
|
|
|
|
struct ovsdb_idl_index *index;
|
2018-06-07 21:07:34 -07:00
|
|
|
|
LIST_FOR_EACH (index, node, &table->indexes) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
index->ins_del = true;
|
|
|
|
|
skiplist_insert(index->skiplist, row);
|
|
|
|
|
index->ins_del = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_remove_from_indexes(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
|
|
|
|
struct ovsdb_idl_index *index;
|
2018-06-07 21:07:34 -07:00
|
|
|
|
LIST_FOR_EACH (index, node, &table->indexes) {
|
2017-08-03 14:20:15 -04:00
|
|
|
|
index->ins_del = true;
|
|
|
|
|
skiplist_delete(index->skiplist, row);
|
|
|
|
|
index->ins_del = false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
/* Writes a datum in an ovsdb_idl_row, and updates the corresponding field in
|
|
|
|
|
* the table record. Not intended for direct usage. */
|
2017-08-03 14:20:15 -04:00
|
|
|
|
void
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_write(struct ovsdb_idl_row *const_row,
|
2017-08-03 14:20:15 -04:00
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum,
|
|
|
|
|
const struct ovsdb_idl_table_class *class)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, const_row);
|
|
|
|
|
size_t column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
if (bitmap_is_set(row->written, column_idx)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum[column_idx].values);
|
|
|
|
|
free(row->new_datum[column_idx].keys);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
} else {
|
|
|
|
|
bitmap_set1(row->written, column_idx);
|
|
|
|
|
}
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum[column_idx] = *datum;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
(column->unparse)(row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
(column->parse)(row, &row->new_datum[column_idx]);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
2017-10-30 12:21:49 -07:00
|
|
|
|
/* Magic UUID for index rows */
|
|
|
|
|
static const struct uuid index_row_uuid = {
|
|
|
|
|
.parts = {0xdeadbeef,
|
|
|
|
|
0xdeadbeef,
|
|
|
|
|
0xdeadbeef,
|
|
|
|
|
0xdeadbeef}};
|
|
|
|
|
|
|
|
|
|
/* Check if a row is an index row */
|
|
|
|
|
static bool
|
2018-06-07 21:07:34 -07:00
|
|
|
|
is_index_row(const struct ovsdb_idl_row *row)
|
2017-10-30 12:21:49 -07:00
|
|
|
|
{
|
|
|
|
|
return uuid_equals(&row->uuid, &index_row_uuid);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
/* Initializes a row for use in an indexed query.
|
|
|
|
|
* Not intended for direct usage.
|
|
|
|
|
*/
|
|
|
|
|
struct ovsdb_idl_row *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_init_row(struct ovsdb_idl_index *index)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = index->table->class_;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
struct ovsdb_idl_row *row = xzalloc(class->allocation_size);
|
|
|
|
|
class->row_init(row);
|
2017-10-30 12:21:49 -07:00
|
|
|
|
row->uuid = index_row_uuid;
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = xmalloc(class->n_columns * sizeof *row->new_datum);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
row->written = bitmap_allocate(class->n_columns);
|
2018-06-07 21:07:34 -07:00
|
|
|
|
row->table = index->table;
|
2017-10-30 12:21:49 -07:00
|
|
|
|
/* arcs are not used for index row, but it doesn't harm to initialize */
|
|
|
|
|
ovs_list_init(&row->src_arcs);
|
|
|
|
|
ovs_list_init(&row->dst_arcs);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Destroys 'row_' and frees all associated memory. This function is intended
|
|
|
|
|
* to be used indirectly through one of the "index_destroy_row" functions
|
|
|
|
|
* generated by ovsdb-idlc.
|
|
|
|
|
*/
|
|
|
|
|
void
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_destroy_row(const struct ovsdb_idl_row *row_)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2017-08-03 14:20:15 -04:00
|
|
|
|
const struct ovsdb_idl_column *c;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovs_assert(is_index_row(row_));
|
2017-10-30 12:21:49 -07:00
|
|
|
|
ovs_assert(ovs_list_is_empty(&row_->src_arcs));
|
|
|
|
|
ovs_assert(ovs_list_is_empty(&row_->dst_arcs));
|
2017-08-03 14:20:15 -04:00
|
|
|
|
BITMAP_FOR_EACH_1 (i, class->n_columns, row->written) {
|
|
|
|
|
c = &class->columns[i];
|
|
|
|
|
(c->unparse) (row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum[i].values);
|
|
|
|
|
free(row->new_datum[i].keys);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
free(row->written);
|
|
|
|
|
free(row);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_row *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_find(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *target)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return skiplist_get_data(skiplist_find(index->skiplist, target));
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_cursor
|
|
|
|
|
ovsdb_idl_cursor_first(struct ovsdb_idl_index *index)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct skiplist_node *node = skiplist_first(index->skiplist);
|
|
|
|
|
return (struct ovsdb_idl_cursor) { index, node };
|
|
|
|
|
}
|
2017-08-03 14:20:15 -04:00
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_cursor
|
|
|
|
|
ovsdb_idl_cursor_first_eq(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *target)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct skiplist_node *node = skiplist_find(index->skiplist, target);
|
|
|
|
|
return (struct ovsdb_idl_cursor) { index, node };
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct ovsdb_idl_cursor
|
|
|
|
|
ovsdb_idl_cursor_first_ge(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *target)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
struct skiplist_node *node = (target
|
|
|
|
|
? skiplist_forward_to(index->skiplist,
|
|
|
|
|
target)
|
|
|
|
|
: skiplist_first(index->skiplist));
|
|
|
|
|
return (struct ovsdb_idl_cursor) { index, node };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_cursor_next(struct ovsdb_idl_cursor *cursor)
|
|
|
|
|
{
|
|
|
|
|
cursor->position = skiplist_next(cursor->position);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_cursor_next_eq(struct ovsdb_idl_cursor *cursor)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *data = skiplist_get_data(cursor->position);
|
|
|
|
|
struct skiplist_node *next_position = skiplist_next(cursor->position);
|
|
|
|
|
struct ovsdb_idl_row *next_data = skiplist_get_data(next_position);
|
|
|
|
|
cursor->position = (!ovsdb_idl_index_compare(cursor->index,
|
|
|
|
|
data, next_data)
|
|
|
|
|
? next_position : NULL);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_row *
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_cursor_data(struct ovsdb_idl_cursor *cursor)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return skiplist_get_data(cursor->position);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the result of comparing two rows using the comparison function
|
|
|
|
|
* for this index.
|
|
|
|
|
* Returns:
|
|
|
|
|
* < 0 if a < b
|
|
|
|
|
* 0 if a == b
|
|
|
|
|
* > 0 if a > b
|
|
|
|
|
* When the pointer to either row is NULL, this function considers NULL to be
|
|
|
|
|
* greater than any other value, and NULL == NULL.
|
|
|
|
|
*/
|
|
|
|
|
int
|
2018-06-07 21:07:34 -07:00
|
|
|
|
ovsdb_idl_index_compare(struct ovsdb_idl_index *index,
|
|
|
|
|
const struct ovsdb_idl_row *a,
|
|
|
|
|
const struct ovsdb_idl_row *b)
|
2017-08-03 14:20:15 -04:00
|
|
|
|
{
|
|
|
|
|
if (a && b) {
|
2018-06-07 21:07:34 -07:00
|
|
|
|
return ovsdb_idl_index_generic_comparer(a, b, index);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
} else if (!a && !b) {
|
|
|
|
|
return 0;
|
|
|
|
|
} else if (a) {
|
|
|
|
|
return -1;
|
|
|
|
|
} else {
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static void
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_old(struct ovsdb_idl_row *row)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(row->old_datum == row->new_datum);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (!ovsdb_idl_row_is_orphan(row)) {
|
2019-05-17 12:56:33 -07:00
|
|
|
|
if (ovsdb_idl_track_is_set(row->table)) {
|
|
|
|
|
row->tracked_old_datum = row->old_datum;
|
|
|
|
|
} else {
|
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
|
|
|
|
size_t i;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2019-05-17 12:56:33 -07:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
|
|
|
|
ovsdb_datum_destroy(&row->old_datum[i],
|
|
|
|
|
&class->columns[i].type);
|
|
|
|
|
}
|
|
|
|
|
free(row->old_datum);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
row->old_datum = row->new_datum = NULL;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_clear_new(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum != row->new_datum) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum) {
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2010-06-24 15:31:18 -07:00
|
|
|
|
if (row->written) {
|
|
|
|
|
BITMAP_FOR_EACH_1 (i, class->n_columns, row->written) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovsdb_datum_destroy(&row->new_datum[i],
|
|
|
|
|
&class->columns[i].type);
|
2010-06-24 15:31:18 -07:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
2017-08-11 11:06:46 -07:00
|
|
|
|
free(row->new_datum);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
free(row->written);
|
|
|
|
|
row->written = NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
row->new_datum = row->old_datum;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_clear_arcs(struct ovsdb_idl_row *row, bool destroy_dsts)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_arc *arc, *next;
|
|
|
|
|
|
|
|
|
|
/* Delete all forward arcs. If 'destroy_dsts', destroy any orphaned rows
|
2018-08-13 10:48:00 -07:00
|
|
|
|
* that this causes to be unreferenced.
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
*/
|
2010-09-17 10:33:10 -07:00
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next, src_node, &row->src_arcs) {
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_remove(&arc->dst_node);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
if (destroy_dsts
|
|
|
|
|
&& ovsdb_idl_row_is_orphan(arc->dst)
|
2016-03-25 14:10:22 -07:00
|
|
|
|
&& ovs_list_is_empty(&arc->dst->dst_arcs)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_row_destroy(arc->dst);
|
|
|
|
|
}
|
|
|
|
|
free(arc);
|
|
|
|
|
}
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_init(&row->src_arcs);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Force nodes that reference 'row' to reparse. */
|
|
|
|
|
static void
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_reparse_backrefs(struct ovsdb_idl_row *row)
|
2009-12-02 11:26:15 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_arc *arc, *next;
|
|
|
|
|
|
|
|
|
|
/* This is trickier than it looks. ovsdb_idl_row_clear_arcs() will destroy
|
|
|
|
|
* 'arc', so we need to use the "safe" variant of list traversal. However,
|
2010-01-25 10:15:17 -08:00
|
|
|
|
* calling an ovsdb_idl_column's 'parse' function will add an arc
|
|
|
|
|
* equivalent to 'arc' to row->arcs. That could be a problem for
|
|
|
|
|
* traversal, but it adds it at the beginning of the list to prevent us
|
|
|
|
|
* from stumbling upon it again.
|
2009-12-02 11:26:15 -08:00
|
|
|
|
*
|
|
|
|
|
* (If duplicate arcs were possible then we would need to make sure that
|
|
|
|
|
* 'next' didn't also point into 'arc''s destination, but we forbid
|
|
|
|
|
* duplicate arcs.) */
|
2010-09-17 10:33:10 -07:00
|
|
|
|
LIST_FOR_EACH_SAFE (arc, next, dst_node, &row->dst_arcs) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *ref = arc->src;
|
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_unparse(ref);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_clear_arcs(ref, false);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_parse(ref);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_row_create__(const struct ovsdb_idl_table_class *class)
|
|
|
|
|
{
|
2009-12-08 17:14:36 -08:00
|
|
|
|
struct ovsdb_idl_row *row = xzalloc(class->allocation_size);
|
2012-05-22 01:53:07 -07:00
|
|
|
|
class->row_init(row);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_init(&row->src_arcs);
|
|
|
|
|
ovs_list_init(&row->dst_arcs);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hmap_node_nullify(&row->txn_node);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_init(&row->track_node);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_row_create(struct ovsdb_idl_table *table, const struct uuid *uuid)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
struct ovsdb_idl_row *row = ovsdb_idl_row_create__(table->class_);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
hmap_insert(&table->rows, &row->hmap_node, uuid_hash(uuid));
|
|
|
|
|
row->uuid = *uuid;
|
|
|
|
|
row->table = table;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
row->map_op_written = NULL;
|
|
|
|
|
row->map_op_lists = NULL;
|
2016-08-06 17:46:29 -05:00
|
|
|
|
row->set_op_written = NULL;
|
|
|
|
|
row->set_op_lists = NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_row_destroy(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (row) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_old(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
hmap_remove(&row->table->rows, &row->hmap_node);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
ovsdb_idl_destroy_all_map_op_lists(row);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
ovsdb_idl_destroy_all_set_op_lists(row);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
if (ovsdb_idl_track_is_set(row->table)) {
|
|
|
|
|
row->change_seqno[OVSDB_IDL_CHANGE_DELETE]
|
|
|
|
|
= row->table->change_seqno[OVSDB_IDL_CHANGE_DELETE]
|
2017-12-15 10:59:36 -08:00
|
|
|
|
= row->table->db->change_seqno + 1;
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
2018-08-13 10:48:01 -07:00
|
|
|
|
if (ovs_list_is_empty(&row->track_node)) {
|
|
|
|
|
ovs_list_push_back(&row->table->track_list, &row->track_node);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_destroy_all_map_op_lists(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (row->map_op_written) {
|
|
|
|
|
/* Clear Map Operation Lists */
|
|
|
|
|
size_t idx, n_columns;
|
|
|
|
|
const struct ovsdb_idl_column *columns;
|
|
|
|
|
const struct ovsdb_type *type;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
n_columns = row->table->class_->n_columns;
|
|
|
|
|
columns = row->table->class_->columns;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
BITMAP_FOR_EACH_1 (idx, n_columns, row->map_op_written) {
|
|
|
|
|
type = &columns[idx].type;
|
|
|
|
|
map_op_list_destroy(row->map_op_lists[idx], type);
|
|
|
|
|
}
|
|
|
|
|
free(row->map_op_lists);
|
|
|
|
|
bitmap_free(row->map_op_written);
|
|
|
|
|
row->map_op_lists = NULL;
|
|
|
|
|
row->map_op_written = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_destroy_all_set_op_lists(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
if (row->set_op_written) {
|
|
|
|
|
/* Clear Set Operation Lists */
|
|
|
|
|
size_t idx, n_columns;
|
|
|
|
|
const struct ovsdb_idl_column *columns;
|
|
|
|
|
const struct ovsdb_type *type;
|
2017-08-11 11:06:44 -07:00
|
|
|
|
n_columns = row->table->class_->n_columns;
|
|
|
|
|
columns = row->table->class_->columns;
|
2016-08-06 17:46:29 -05:00
|
|
|
|
BITMAP_FOR_EACH_1 (idx, n_columns, row->set_op_written) {
|
|
|
|
|
type = &columns[idx].type;
|
|
|
|
|
set_op_list_destroy(row->set_op_lists[idx], type);
|
|
|
|
|
}
|
|
|
|
|
free(row->set_op_lists);
|
|
|
|
|
bitmap_free(row->set_op_written);
|
|
|
|
|
row->set_op_lists = NULL;
|
|
|
|
|
row->set_op_written = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_row_destroy_postprocess(struct ovsdb_idl_db *db)
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
{
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (i = 0; i < db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &db->tables[i];
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (!ovs_list_is_empty(&table->track_list)) {
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
|
|
|
|
LIST_FOR_EACH_SAFE(row, next, track_node, &table->track_list) {
|
|
|
|
|
if (!ovsdb_idl_track_is_set(row->table)) {
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_remove(&row->track_node);
|
2019-05-17 12:56:33 -07:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
free(row);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_insert_row(struct ovsdb_idl_row *row, const struct json *row_json)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2017-08-11 11:06:47 -07:00
|
|
|
|
size_t i, datum_size;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(!row->old_datum && !row->new_datum);
|
|
|
|
|
datum_size = class->n_columns * sizeof *row->old_datum;
|
|
|
|
|
row->old_datum = row->new_datum = xmalloc(datum_size);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
for (i = 0; i < class->n_columns; i++) {
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovsdb_datum_init_default(&row->old_datum[i], &class->columns[i].type);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
ovsdb_idl_row_update(row, row_json, OVSDB_IDL_CHANGE_INSERT);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_parse(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_reparse_backrefs(row);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_delete_row(struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_row_clear_arcs(row, true);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_old(row);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (ovs_list_is_empty(&row->dst_arcs)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_row_destroy(row);
|
|
|
|
|
} else {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_reparse_backrefs(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-11 15:41:41 -07:00
|
|
|
|
/* Returns true if a column with mode OVSDB_IDL_MODE_RW changed, false
|
|
|
|
|
* otherwise. */
|
|
|
|
|
static bool
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_modify_row(struct ovsdb_idl_row *row, const struct json *row_json)
|
|
|
|
|
{
|
2010-08-11 15:41:41 -07:00
|
|
|
|
bool changed;
|
|
|
|
|
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_row_clear_arcs(row, true);
|
ovsdb-idl: Add support for change tracking.
Ovsdb-idl notifies a client that something changed; it does not track
which table, row changed in what way (insert, modify or delete).
As a result, a client has to scan or reconfigure the entire idl after
ovsdb_idl_run(). This is presumably fine for typical ovs schemas where
tables are relatively small. In use-cases where ovsdb is used with
schemas that can have very large tables, the current ovsdb-idl
notification mechanism does not appear to scale - clients need to do a
lot of processing to determine the exact change delta.
This change adds support for:
- Table and row based change sequence numbers to record the
most recent IDL change sequence numbers associated with insert,
modify or delete update on that table or row.
- Change tracking of specific columns. This ensures that changed
rows (inserted, modified, deleted) that have tracked columns, are
tracked by IDL. The client can directly access the changed rows
with get_first, get_next operations without the need to scan the
entire table.
The tracking functionality is not enabled by default and needs to
be turned on per-column by the client after ovsdb_idl_create()
and before ovsdb_idl_run().
/* Example Usage */
idl = ovsdb_idl_create(...);
/* Track specific columns */
ovsdb_idl_track_add_column(idl, column);
/* Or, track all columns */
ovsdb_idl_track_add_all(idl);
for (;;) {
ovsdb_idl_run(idl);
seqno = ovsdb_idl_get_seqno(idl);
/* Process only the changed rows in Table FOO */
FOO_FOR_EACH_TRACKED(row, idl) {
/* Determine the type of change from the row seqnos */
if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_DELETE)
>= seqno)) {
printf("row deleted\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_MODIFY)
>= seqno))
printf("row modified\n");
} else if (foo_row_get_seqno(row, OVSDB_IDL_CHANGE_INSERT)
>= seqno))
printf("row inserted\n");
}
}
/* All changes processed - clear the change track */
ovsdb_idl_track_clear(idl);
}
Signed-off-by: Shad Ansari <shad.ansari@hp.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2015-10-27 13:55:35 -07:00
|
|
|
|
changed = ovsdb_idl_row_update(row, row_json, OVSDB_IDL_CHANGE_MODIFY);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
ovsdb_idl_row_parse(row);
|
2017-08-03 14:20:15 -04:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
|
|
|
|
|
return changed;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
2015-10-15 14:09:37 -07:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_modify_row_by_diff(struct ovsdb_idl_row *row,
|
|
|
|
|
const struct json *diff_json)
|
|
|
|
|
{
|
|
|
|
|
bool changed;
|
|
|
|
|
|
2018-08-10 20:29:46 -07:00
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
ovsdb_idl_row_clear_arcs(row, true);
|
|
|
|
|
changed = ovsdb_idl_row_apply_diff(row, diff_json,
|
|
|
|
|
OVSDB_IDL_CHANGE_MODIFY);
|
|
|
|
|
ovsdb_idl_row_parse(row);
|
2018-08-10 20:29:46 -07:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2015-10-15 14:09:37 -07:00
|
|
|
|
|
|
|
|
|
return changed;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-02 11:26:15 -08:00
|
|
|
|
static bool
|
|
|
|
|
may_add_arc(const struct ovsdb_idl_row *src, const struct ovsdb_idl_row *dst)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_arc *arc;
|
|
|
|
|
|
|
|
|
|
/* No self-arcs. */
|
|
|
|
|
if (src == dst) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* No duplicate arcs.
|
|
|
|
|
*
|
|
|
|
|
* We only need to test whether the first arc in dst->dst_arcs originates
|
|
|
|
|
* at 'src', since we add all of the arcs from a given source in a clump
|
2010-01-25 10:15:17 -08:00
|
|
|
|
* (in a single call to ovsdb_idl_row_parse()) and new arcs are always
|
2009-12-02 11:26:15 -08:00
|
|
|
|
* added at the front of the dst_arcs list. */
|
2016-03-25 14:10:22 -07:00
|
|
|
|
if (ovs_list_is_empty(&dst->dst_arcs)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
arc = CONTAINER_OF(dst->dst_arcs.next, struct ovsdb_idl_arc, dst_node);
|
|
|
|
|
return arc->src != src;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct ovsdb_idl_table *
|
|
|
|
|
ovsdb_idl_db_table_from_class(const struct ovsdb_idl_db *db,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
|
|
|
|
ptrdiff_t idx = table_class - db->class_->tables;
|
|
|
|
|
return idx >= 0 && idx < db->class_->n_tables ? &db->tables[idx] : NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-04 14:55:24 -08:00
|
|
|
|
static struct ovsdb_idl_table *
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_table_from_class(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
2009-12-04 14:55:24 -08:00
|
|
|
|
{
|
2017-12-31 21:15:58 -08:00
|
|
|
|
struct ovsdb_idl_table *table;
|
|
|
|
|
|
|
|
|
|
table = ovsdb_idl_db_table_from_class(&idl->data, table_class);
|
|
|
|
|
if (!table) {
|
|
|
|
|
table = ovsdb_idl_db_table_from_class(&idl->server, table_class);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return table;
|
2009-12-04 14:55:24 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Called by ovsdb-idlc generated code. */
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_get_row_arc(struct ovsdb_idl_row *src,
|
2016-08-24 23:10:15 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *dst_table_class,
|
2009-12-02 11:26:15 -08:00
|
|
|
|
const struct uuid *dst_uuid)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_db *db = src->table->db;
|
2009-12-03 10:35:45 -08:00
|
|
|
|
struct ovsdb_idl_table *dst_table;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
struct ovsdb_idl_arc *arc;
|
|
|
|
|
struct ovsdb_idl_row *dst;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
dst_table = ovsdb_idl_db_table_from_class(db, dst_table_class);
|
2009-12-03 10:35:45 -08:00
|
|
|
|
dst = ovsdb_idl_get_row(dst_table, dst_uuid);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (db->txn || is_index_row(src)) {
|
2017-10-30 12:21:49 -07:00
|
|
|
|
/* There are two cases we should not update any arcs:
|
|
|
|
|
*
|
|
|
|
|
* 1. We're being called from ovsdb_idl_txn_write(). We must not update
|
2010-01-25 10:15:17 -08:00
|
|
|
|
* any arcs, because the transaction will be backed out at commit or
|
|
|
|
|
* abort time and we don't want our graph screwed up.
|
|
|
|
|
*
|
2017-10-30 12:21:49 -07:00
|
|
|
|
* 2. The row is used as an index for querying purpose only.
|
|
|
|
|
*
|
|
|
|
|
* In these cases, just return the destination row, if there is one and
|
|
|
|
|
* it has not been deleted. */
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (dst && (hmap_node_is_null(&dst->txn_node) || dst->new_datum)) {
|
2010-01-25 10:15:17 -08:00
|
|
|
|
return dst;
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
} else {
|
|
|
|
|
/* We're being called from some other context. Update the graph. */
|
|
|
|
|
if (!dst) {
|
|
|
|
|
dst = ovsdb_idl_row_create(dst_table, dst_uuid);
|
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
/* Add a new arc, if it wouldn't be a self-arc or a duplicate arc. */
|
|
|
|
|
if (may_add_arc(src, dst)) {
|
|
|
|
|
/* The arc *must* be added at the front of the dst_arcs list. See
|
|
|
|
|
* ovsdb_idl_row_reparse_backrefs() for details. */
|
|
|
|
|
arc = xmalloc(sizeof *arc);
|
2016-03-25 14:10:22 -07:00
|
|
|
|
ovs_list_push_front(&src->src_arcs, &arc->src_node);
|
|
|
|
|
ovs_list_push_front(&dst->dst_arcs, &arc->dst_node);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
arc->src = src;
|
|
|
|
|
arc->dst = dst;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return !ovsdb_idl_row_is_orphan(dst) ? dst : NULL;
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
}
|
2009-12-02 11:26:15 -08:00
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Searches 'tc''s table in 'idl' for a row with UUID 'uuid'. Returns a
|
|
|
|
|
* pointer to the row if there is one, otherwise a null pointer. */
|
2010-01-25 10:15:17 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_get_row_for_uuid(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *tc,
|
|
|
|
|
const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
return ovsdb_idl_get_row(ovsdb_idl_table_from_class(idl, tc), uuid);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct ovsdb_idl_row *
|
|
|
|
|
next_real_row(struct ovsdb_idl_table *table, struct hmap_node *node)
|
|
|
|
|
{
|
|
|
|
|
for (; node; node = hmap_next(&table->rows, node)) {
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
|
|
|
|
|
row = CONTAINER_OF(node, struct ovsdb_idl_row, hmap_node);
|
2010-03-03 09:59:47 -08:00
|
|
|
|
if (ovsdb_idl_row_exists(row)) {
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a row in 'table_class''s table in 'idl', or a null pointer if that
|
|
|
|
|
* table is empty.
|
|
|
|
|
*
|
|
|
|
|
* Database tables are internally maintained as hash tables, so adding or
|
|
|
|
|
* removing rows while traversing the same table can cause some rows to be
|
|
|
|
|
* visited twice or not at apply. */
|
2010-01-25 10:15:17 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_first_row(const struct ovsdb_idl *idl,
|
|
|
|
|
const struct ovsdb_idl_table_class *table_class)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_table *table = ovsdb_idl_table_from_class(idl,
|
|
|
|
|
table_class);
|
2009-12-02 11:26:15 -08:00
|
|
|
|
return next_real_row(table, hmap_first(&table->rows));
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a row following 'row' within its table, or a null pointer if 'row'
|
|
|
|
|
* is the last row in its table. */
|
2010-01-25 10:15:17 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
2009-12-02 11:26:15 -08:00
|
|
|
|
ovsdb_idl_next_row(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_table *table = row->table;
|
|
|
|
|
|
|
|
|
|
return next_real_row(table, hmap_next(&table->rows, &row->hmap_node));
|
|
|
|
|
}
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
|
|
|
|
/* Reads and returns the value of 'column' within 'row'. If an ongoing
|
|
|
|
|
* transaction has changed 'column''s value, the modified value is returned.
|
|
|
|
|
*
|
|
|
|
|
* The caller must not modify or free the returned value.
|
|
|
|
|
*
|
|
|
|
|
* Various kinds of changes can invalidate the returned value: writing to the
|
|
|
|
|
* same 'column' in 'row' (e.g. with ovsdb_idl_txn_write()), deleting 'row'
|
|
|
|
|
* (e.g. with ovsdb_idl_txn_delete()), or completing an ongoing transaction
|
|
|
|
|
* (e.g. with ovsdb_idl_txn_commit() or ovsdb_idl_txn_abort()). If the
|
|
|
|
|
* returned value is needed for a long time, it is best to make a copy of it
|
|
|
|
|
* with ovsdb_datum_clone(). */
|
|
|
|
|
const struct ovsdb_datum *
|
|
|
|
|
ovsdb_idl_read(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2011-11-15 13:59:41 -08:00
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!ovsdb_idl_row_is_synthetic(row));
|
2011-11-15 13:59:41 -08:00
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2011-11-15 13:59:41 -08:00
|
|
|
|
column_idx = column - class->columns;
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(column_idx < class->n_columns);
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
|
|
|
|
if (row->written && bitmap_is_set(row->written, column_idx)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
return &row->new_datum[column_idx];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum) {
|
|
|
|
|
return &row->old_datum[column_idx];
|
2010-06-16 14:35:48 -07:00
|
|
|
|
} else {
|
|
|
|
|
return ovsdb_datum_default(&column->type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Same as ovsdb_idl_read(), except that it also asserts that 'column' has key
|
|
|
|
|
* type 'key_type' and value type 'value_type'. (Scalar and set types will
|
|
|
|
|
* have a value type of OVSDB_TYPE_VOID.)
|
|
|
|
|
*
|
|
|
|
|
* This is useful in code that "knows" that a particular column has a given
|
|
|
|
|
* type, so that it will abort if someone changes the column's type without
|
|
|
|
|
* updating the code that uses it. */
|
|
|
|
|
const struct ovsdb_datum *
|
|
|
|
|
ovsdb_idl_get(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
enum ovsdb_atomic_type key_type OVS_UNUSED,
|
|
|
|
|
enum ovsdb_atomic_type value_type OVS_UNUSED)
|
|
|
|
|
{
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(column->type.key.type == key_type);
|
|
|
|
|
ovs_assert(column->type.value.type == value_type);
|
2010-06-16 14:35:48 -07:00
|
|
|
|
|
|
|
|
|
return ovsdb_idl_read(row, column);
|
|
|
|
|
}
|
2011-04-13 11:10:44 -07:00
|
|
|
|
|
2014-09-26 16:00:44 -07:00
|
|
|
|
/* Returns true if the field represented by 'column' in 'row' may be modified,
|
|
|
|
|
* false if it is immutable.
|
|
|
|
|
*
|
|
|
|
|
* Normally, whether a field is mutable is controlled by its column's schema.
|
|
|
|
|
* However, an immutable column can be set to any initial value at the time of
|
|
|
|
|
* insertion, so if 'row' is a new row (one that is being added as part of the
|
|
|
|
|
* current transaction, supposing that a transaction is in progress) then even
|
|
|
|
|
* its "immutable" fields are actually mutable. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_mutable(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2017-08-11 11:06:47 -07:00
|
|
|
|
return column->is_mutable || (row->new_datum && !row->old_datum);
|
2014-09-26 16:00:44 -07:00
|
|
|
|
}
|
|
|
|
|
|
2011-04-13 11:10:44 -07:00
|
|
|
|
/* Returns false if 'row' was obtained from the IDL, true if it was initialized
|
|
|
|
|
* to all-zero-bits by some other entity. If 'row' was set up some other way
|
|
|
|
|
* then the return value is indeterminate. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_row_is_synthetic(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
|
|
|
|
return row->table == NULL;
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
|
|
|
|
/* Transactions. */
|
|
|
|
|
|
|
|
|
|
static void ovsdb_idl_txn_complete(struct ovsdb_idl_txn *txn,
|
|
|
|
|
enum ovsdb_idl_txn_status);
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a string representation of 'status'. The caller must not modify or
|
|
|
|
|
* free the returned string.
|
|
|
|
|
*
|
|
|
|
|
* The return value is probably useful only for debug log messages and unit
|
|
|
|
|
* tests. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
const char *
|
|
|
|
|
ovsdb_idl_txn_status_to_string(enum ovsdb_idl_txn_status status)
|
|
|
|
|
{
|
|
|
|
|
switch (status) {
|
2011-06-20 16:17:44 -07:00
|
|
|
|
case TXN_UNCOMMITTED:
|
|
|
|
|
return "uncommitted";
|
2009-12-16 16:26:17 -08:00
|
|
|
|
case TXN_UNCHANGED:
|
|
|
|
|
return "unchanged";
|
2009-12-07 17:08:04 -08:00
|
|
|
|
case TXN_INCOMPLETE:
|
|
|
|
|
return "incomplete";
|
|
|
|
|
case TXN_ABORTED:
|
|
|
|
|
return "aborted";
|
|
|
|
|
case TXN_SUCCESS:
|
|
|
|
|
return "success";
|
2012-03-27 10:16:52 -07:00
|
|
|
|
case TXN_TRY_AGAIN:
|
|
|
|
|
return "try again";
|
2011-07-26 16:49:03 -07:00
|
|
|
|
case TXN_NOT_LOCKED:
|
|
|
|
|
return "not locked";
|
2009-12-07 17:08:04 -08:00
|
|
|
|
case TXN_ERROR:
|
|
|
|
|
return "error";
|
|
|
|
|
}
|
|
|
|
|
return "<unknown>";
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Starts a new transaction on 'idl'. A given ovsdb_idl may only have a single
|
|
|
|
|
* active transaction at a time. See the large comment in ovsdb-idl.h for
|
|
|
|
|
* general information on transactions. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct ovsdb_idl_txn *
|
|
|
|
|
ovsdb_idl_txn_create(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovs_assert(!idl->data.txn);
|
|
|
|
|
idl->data.txn = txn = xmalloc(sizeof *txn);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
txn->request_id = NULL;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
txn->db = &idl->data;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hmap_init(&txn->txn_rows);
|
2011-06-20 16:17:44 -07:00
|
|
|
|
txn->status = TXN_UNCOMMITTED;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
txn->error = NULL;
|
2009-12-11 11:28:36 -08:00
|
|
|
|
txn->dry_run = false;
|
2009-12-16 13:30:53 -08:00
|
|
|
|
ds_init(&txn->comment);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
|
2009-12-16 16:26:17 -08:00
|
|
|
|
txn->inc_table = NULL;
|
|
|
|
|
txn->inc_column = NULL;
|
2010-02-02 14:03:18 -08:00
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
hmap_init(&txn->inserted_rows);
|
2010-02-02 14:03:18 -08:00
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return txn;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-08 14:18:44 -08:00
|
|
|
|
/* Appends 's', which is treated as a printf()-type format string, to the
|
|
|
|
|
* comments that will be passed to the OVSDB server when 'txn' is committed.
|
|
|
|
|
* (The comment will be committed to the OVSDB log, which "ovsdb-tool
|
|
|
|
|
* show-log" can print in a relatively human-readable form.) */
|
2009-12-16 13:30:53 -08:00
|
|
|
|
void
|
2010-03-08 14:18:44 -08:00
|
|
|
|
ovsdb_idl_txn_add_comment(struct ovsdb_idl_txn *txn, const char *s, ...)
|
2009-12-16 13:30:53 -08:00
|
|
|
|
{
|
2010-03-08 14:18:44 -08:00
|
|
|
|
va_list args;
|
|
|
|
|
|
2009-12-16 13:30:53 -08:00
|
|
|
|
if (txn->comment.length) {
|
|
|
|
|
ds_put_char(&txn->comment, '\n');
|
|
|
|
|
}
|
2010-03-08 14:18:44 -08:00
|
|
|
|
|
|
|
|
|
va_start(args, s);
|
|
|
|
|
ds_put_format_valist(&txn->comment, s, args);
|
|
|
|
|
va_end(args);
|
2009-12-16 13:30:53 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Marks 'txn' as a transaction that will not actually modify the database. In
|
|
|
|
|
* almost every way, the transaction is treated like other transactions. It
|
|
|
|
|
* must be committed or aborted like other transactions, it will be sent to the
|
|
|
|
|
* database server like other transactions, and so on. The only difference is
|
|
|
|
|
* that the operations sent to the database server will include, as the last
|
|
|
|
|
* step, an "abort" operation, so that any changes made by the transaction will
|
|
|
|
|
* not actually take effect. */
|
2009-12-11 11:28:36 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_set_dry_run(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
txn->dry_run = true;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:25:10 -07:00
|
|
|
|
/* Causes 'txn', when committed, to increment the value of 'column' within
|
|
|
|
|
* 'row' by 1. 'column' must have an integer type. After 'txn' commits
|
|
|
|
|
* successfully, the client may retrieve the final (incremented) value of
|
|
|
|
|
* 'column' with ovsdb_idl_txn_get_increment_new_value().
|
|
|
|
|
*
|
2016-08-07 20:44:51 -07:00
|
|
|
|
* If at time of commit the transaction is otherwise empty, that is, it doesn't
|
|
|
|
|
* change the database, then 'force' is important. If 'force' is false in this
|
|
|
|
|
* case, the IDL suppresses the increment and skips a round trip to the
|
|
|
|
|
* database server. If 'force' is true, the IDL will still increment the
|
|
|
|
|
* column.
|
|
|
|
|
*
|
2012-04-12 08:25:10 -07:00
|
|
|
|
* The client could accomplish something similar with ovsdb_idl_read(),
|
|
|
|
|
* ovsdb_idl_txn_verify() and ovsdb_idl_txn_write(), or with ovsdb-idlc
|
|
|
|
|
* generated wrappers for these functions. However, ovsdb_idl_txn_increment()
|
|
|
|
|
* will never (by itself) fail because of a verify error.
|
|
|
|
|
*
|
|
|
|
|
* The intended use is for incrementing the "next_cfg" column in the
|
|
|
|
|
* Open_vSwitch table. */
|
2009-12-16 16:26:17 -08:00
|
|
|
|
void
|
2012-04-12 08:25:10 -07:00
|
|
|
|
ovsdb_idl_txn_increment(struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct ovsdb_idl_row *row,
|
2016-08-07 20:44:51 -07:00
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
bool force)
|
2009-12-16 16:26:17 -08:00
|
|
|
|
{
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!txn->inc_table);
|
|
|
|
|
ovs_assert(column->type.key.type == OVSDB_TYPE_INTEGER);
|
|
|
|
|
ovs_assert(column->type.value.type == OVSDB_TYPE_VOID);
|
2012-04-12 08:25:10 -07:00
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
txn->inc_table = row->table->class_->name;
|
2012-04-12 08:25:10 -07:00
|
|
|
|
txn->inc_column = column->name;
|
|
|
|
|
txn->inc_row = row->uuid;
|
2016-08-07 20:44:51 -07:00
|
|
|
|
txn->inc_force = force;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Destroys 'txn' and frees all associated memory. If ovsdb_idl_txn_commit()
|
|
|
|
|
* has been called for 'txn' but the commit is still incomplete (that is, the
|
|
|
|
|
* last call returned TXN_INCOMPLETE) then the transaction may or may not still
|
|
|
|
|
* end up committing at the database server, but the client will not be able to
|
|
|
|
|
* get any further status information back. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_destroy(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_idl_txn_insert *insert, *next;
|
|
|
|
|
|
2010-02-02 14:03:18 -08:00
|
|
|
|
json_destroy(txn->request_id);
|
2009-12-11 16:58:16 -08:00
|
|
|
|
if (txn->status == TXN_INCOMPLETE) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_remove(&txn->db->outstanding_txns, &txn->hmap_node);
|
2009-12-11 16:58:16 -08:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_abort(txn);
|
2009-12-16 13:30:53 -08:00
|
|
|
|
ds_destroy(&txn->comment);
|
2010-02-05 14:11:12 -08:00
|
|
|
|
free(txn->error);
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_SAFE (insert, next, hmap_node, &txn->inserted_rows) {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
free(insert);
|
|
|
|
|
}
|
2010-02-02 14:03:18 -08:00
|
|
|
|
hmap_destroy(&txn->inserted_rows);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
free(txn);
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Causes poll_block() to wake up if 'txn' has completed committing. */
|
2009-12-09 13:29:02 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_wait(const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2011-06-20 16:17:44 -07:00
|
|
|
|
if (txn->status != TXN_UNCOMMITTED && txn->status != TXN_INCOMPLETE) {
|
2009-12-09 13:29:02 -08:00
|
|
|
|
poll_immediate_wake();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct json *
|
|
|
|
|
where_uuid_equals(const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
return
|
|
|
|
|
json_array_create_1(
|
|
|
|
|
json_array_create_3(
|
|
|
|
|
json_string_create("_uuid"),
|
|
|
|
|
json_string_create("=="),
|
|
|
|
|
json_array_create_2(
|
|
|
|
|
json_string_create("uuid"),
|
|
|
|
|
json_string_create_nocopy(
|
|
|
|
|
xasprintf(UUID_FMT, UUID_ARGS(uuid))))));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const struct ovsdb_idl_row *
|
|
|
|
|
ovsdb_idl_txn_get_row(const struct ovsdb_idl_txn *txn, const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_row *row;
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (row, txn_node, uuid_hash(uuid), &txn->txn_rows) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (uuid_equals(&row->uuid, uuid)) {
|
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* XXX there must be a cleaner way to do this */
|
|
|
|
|
static struct json *
|
|
|
|
|
substitute_uuids(struct json *json, const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
if (json->type == JSON_ARRAY) {
|
|
|
|
|
struct uuid uuid;
|
|
|
|
|
size_t i;
|
|
|
|
|
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (json->array.n == 2
|
|
|
|
|
&& json->array.elems[0]->type == JSON_STRING
|
|
|
|
|
&& json->array.elems[1]->type == JSON_STRING
|
|
|
|
|
&& !strcmp(json->array.elems[0]->string, "uuid")
|
|
|
|
|
&& uuid_from_string(&uuid, json->array.elems[1]->string)) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
const struct ovsdb_idl_row *row;
|
|
|
|
|
|
|
|
|
|
row = ovsdb_idl_txn_get_row(txn, &uuid);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row && !row->old_datum && row->new_datum) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
json_destroy(json);
|
|
|
|
|
|
|
|
|
|
return json_array_create_2(
|
|
|
|
|
json_string_create("named-uuid"),
|
2017-12-21 16:41:30 -08:00
|
|
|
|
json_string_create_nocopy(ovsdb_data_row_name(&uuid)));
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-24 10:32:59 -07:00
|
|
|
|
for (i = 0; i < json->array.n; i++) {
|
|
|
|
|
json->array.elems[i] = substitute_uuids(json->array.elems[i],
|
2009-12-07 17:08:04 -08:00
|
|
|
|
txn);
|
|
|
|
|
}
|
|
|
|
|
} else if (json->type == JSON_OBJECT) {
|
|
|
|
|
struct shash_node *node;
|
|
|
|
|
|
|
|
|
|
SHASH_FOR_EACH (node, json_object(json)) {
|
|
|
|
|
node->data = substitute_uuids(node->data, txn);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return json;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_disassemble(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row, *next;
|
|
|
|
|
|
2010-01-25 10:15:17 -08:00
|
|
|
|
/* This must happen early. Otherwise, ovsdb_idl_row_parse() will call an
|
|
|
|
|
* ovsdb_idl_column's 'parse' function, which will call
|
|
|
|
|
* ovsdb_idl_get_row_arc(), which will seen that the IDL is in a
|
|
|
|
|
* transaction and fail to update the graph. */
|
2017-12-15 10:59:36 -08:00
|
|
|
|
txn->db->txn = NULL;
|
2010-01-25 10:15:17 -08:00
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_SAFE (row, next, txn_node, &txn->txn_rows) {
|
2018-08-14 11:31:46 -07:00
|
|
|
|
enum { INSERTED, MODIFIED, DELETED } op
|
|
|
|
|
= (!row->new_datum ? DELETED
|
|
|
|
|
: !row->old_datum ? INSERTED
|
|
|
|
|
: MODIFIED);
|
|
|
|
|
|
|
|
|
|
if (op != DELETED) {
|
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
ovsdb_idl_destroy_all_map_op_lists(row);
|
2016-08-06 17:46:29 -05:00
|
|
|
|
ovsdb_idl_destroy_all_set_op_lists(row);
|
2018-08-14 11:31:46 -07:00
|
|
|
|
if (op != INSERTED) {
|
2010-01-25 10:15:17 -08:00
|
|
|
|
if (row->written) {
|
|
|
|
|
ovsdb_idl_row_unparse(row);
|
|
|
|
|
ovsdb_idl_row_clear_arcs(row, false);
|
|
|
|
|
ovsdb_idl_row_parse(row);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-08 09:48:37 -08:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_new(row);
|
|
|
|
|
|
|
|
|
|
free(row->prereqs);
|
|
|
|
|
row->prereqs = NULL;
|
|
|
|
|
|
|
|
|
|
free(row->written);
|
|
|
|
|
row->written = NULL;
|
|
|
|
|
|
|
|
|
|
hmap_remove(&txn->txn_rows, &row->txn_node);
|
|
|
|
|
hmap_node_nullify(&row->txn_node);
|
2018-08-14 11:31:46 -07:00
|
|
|
|
if (op != INSERTED) {
|
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
|
|
|
|
} else {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
hmap_remove(&row->table->rows, &row->hmap_node);
|
|
|
|
|
free(row);
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
hmap_destroy(&txn->txn_rows);
|
|
|
|
|
hmap_init(&txn->txn_rows);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_txn_extract_mutations(struct ovsdb_idl_row *row,
|
|
|
|
|
struct json *mutations)
|
|
|
|
|
{
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
size_t idx;
|
|
|
|
|
bool any_mutations = false;
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
if (row->map_op_written) {
|
|
|
|
|
BITMAP_FOR_EACH_1(idx, class->n_columns, row->map_op_written) {
|
|
|
|
|
struct map_op_list *map_op_list;
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
const struct ovsdb_datum *old_datum;
|
|
|
|
|
enum ovsdb_atomic_type key_type, value_type;
|
|
|
|
|
struct json *mutation, *map, *col_name, *mutator;
|
|
|
|
|
struct json *del_set, *ins_map;
|
|
|
|
|
bool any_del, any_ins;
|
|
|
|
|
|
|
|
|
|
map_op_list = row->map_op_lists[idx];
|
|
|
|
|
column = &class->columns[idx];
|
|
|
|
|
key_type = column->type.key.type;
|
|
|
|
|
value_type = column->type.value.type;
|
|
|
|
|
|
|
|
|
|
/* Get the value to be changed */
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum && row->written
|
|
|
|
|
&& bitmap_is_set(row->written,idx)) {
|
|
|
|
|
old_datum = &row->new_datum[idx];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum != NULL) {
|
|
|
|
|
old_datum = &row->old_datum[idx];
|
2016-08-06 17:46:29 -05:00
|
|
|
|
} else {
|
|
|
|
|
old_datum = ovsdb_datum_default(&column->type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
del_set = json_array_create_empty();
|
|
|
|
|
ins_map = json_array_create_empty();
|
|
|
|
|
any_del = false;
|
|
|
|
|
any_ins = false;
|
|
|
|
|
|
|
|
|
|
for (struct map_op *map_op = map_op_list_first(map_op_list); map_op;
|
|
|
|
|
map_op = map_op_list_next(map_op_list, map_op)) {
|
|
|
|
|
|
|
|
|
|
if (map_op_type(map_op) == MAP_OP_UPDATE) {
|
|
|
|
|
/* Find out if value really changed. */
|
|
|
|
|
struct ovsdb_datum *new_datum;
|
|
|
|
|
unsigned int pos;
|
|
|
|
|
new_datum = map_op_datum(map_op);
|
|
|
|
|
pos = ovsdb_datum_find_key(old_datum,
|
|
|
|
|
&new_datum->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
if (ovsdb_atom_equals(&new_datum->values[0],
|
|
|
|
|
&old_datum->values[pos],
|
|
|
|
|
value_type)) {
|
|
|
|
|
/* No change in value. Move on to next update. */
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
} else if (map_op_type(map_op) == MAP_OP_DELETE){
|
|
|
|
|
/* Verify that there is a key to delete. */
|
|
|
|
|
unsigned int pos;
|
|
|
|
|
pos = ovsdb_datum_find_key(old_datum,
|
|
|
|
|
&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
if (pos == UINT_MAX) {
|
|
|
|
|
/* No key to delete. Move on to next update. */
|
|
|
|
|
VLOG_WARN("Trying to delete a key that doesn't "
|
|
|
|
|
"exist in the map.");
|
|
|
|
|
continue;
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
2016-08-06 17:46:29 -05:00
|
|
|
|
|
|
|
|
|
if (map_op_type(map_op) == MAP_OP_INSERT) {
|
|
|
|
|
map = json_array_create_2(
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type),
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->values[0],
|
|
|
|
|
value_type));
|
|
|
|
|
json_array_add(ins_map, map);
|
|
|
|
|
any_ins = true;
|
|
|
|
|
} else { /* MAP_OP_UPDATE or MAP_OP_DELETE */
|
|
|
|
|
map = ovsdb_atom_to_json(&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
json_array_add(del_set, map);
|
|
|
|
|
any_del = true;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Generate an additional insert mutate for updates. */
|
|
|
|
|
if (map_op_type(map_op) == MAP_OP_UPDATE) {
|
|
|
|
|
map = json_array_create_2(
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->keys[0],
|
|
|
|
|
key_type),
|
|
|
|
|
ovsdb_atom_to_json(&map_op_datum(map_op)->values[0],
|
|
|
|
|
value_type));
|
|
|
|
|
json_array_add(ins_map, map);
|
|
|
|
|
any_ins = true;
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
if (any_del) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("delete");
|
|
|
|
|
map = json_array_create_2(json_string_create("set"), del_set);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, map);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(del_set);
|
|
|
|
|
}
|
|
|
|
|
if (any_ins) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("insert");
|
|
|
|
|
map = json_array_create_2(json_string_create("map"), ins_map);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, map);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(ins_map);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-06 17:46:29 -05:00
|
|
|
|
}
|
|
|
|
|
if (row->set_op_written) {
|
|
|
|
|
BITMAP_FOR_EACH_1(idx, class->n_columns, row->set_op_written) {
|
|
|
|
|
struct set_op_list *set_op_list;
|
|
|
|
|
const struct ovsdb_idl_column *column;
|
|
|
|
|
const struct ovsdb_datum *old_datum;
|
|
|
|
|
enum ovsdb_atomic_type key_type;
|
|
|
|
|
struct json *mutation, *set, *col_name, *mutator;
|
|
|
|
|
struct json *del_set, *ins_set;
|
|
|
|
|
bool any_del, any_ins;
|
|
|
|
|
|
|
|
|
|
set_op_list = row->set_op_lists[idx];
|
|
|
|
|
column = &class->columns[idx];
|
|
|
|
|
key_type = column->type.key.type;
|
|
|
|
|
|
|
|
|
|
/* Get the value to be changed */
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (row->new_datum && row->written
|
|
|
|
|
&& bitmap_is_set(row->written,idx)) {
|
|
|
|
|
old_datum = &row->new_datum[idx];
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum != NULL) {
|
|
|
|
|
old_datum = &row->old_datum[idx];
|
2016-08-06 17:46:29 -05:00
|
|
|
|
} else {
|
|
|
|
|
old_datum = ovsdb_datum_default(&column->type);
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
del_set = json_array_create_empty();
|
|
|
|
|
ins_set = json_array_create_empty();
|
|
|
|
|
any_del = false;
|
|
|
|
|
any_ins = false;
|
|
|
|
|
|
|
|
|
|
for (struct set_op *set_op = set_op_list_first(set_op_list); set_op;
|
|
|
|
|
set_op = set_op_list_next(set_op_list, set_op)) {
|
|
|
|
|
if (set_op_type(set_op) == SET_OP_INSERT) {
|
|
|
|
|
set = ovsdb_atom_to_json(&set_op_datum(set_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
json_array_add(ins_set, set);
|
|
|
|
|
any_ins = true;
|
|
|
|
|
} else { /* SETP_OP_DELETE */
|
|
|
|
|
/* Verify that there is a key to delete. */
|
|
|
|
|
unsigned int pos;
|
|
|
|
|
pos = ovsdb_datum_find_key(old_datum,
|
|
|
|
|
&set_op_datum(set_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
if (pos == UINT_MAX) {
|
|
|
|
|
/* No key to delete. Move on to next update. */
|
|
|
|
|
VLOG_WARN("Trying to delete a key that doesn't "
|
|
|
|
|
"exist in the set.");
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
set = ovsdb_atom_to_json(&set_op_datum(set_op)->keys[0],
|
|
|
|
|
key_type);
|
|
|
|
|
json_array_add(del_set, set);
|
|
|
|
|
any_del = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (any_del) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("delete");
|
|
|
|
|
set = json_array_create_2(json_string_create("set"), del_set);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, set);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(del_set);
|
|
|
|
|
}
|
|
|
|
|
if (any_ins) {
|
|
|
|
|
col_name = json_string_create(column->name);
|
|
|
|
|
mutator = json_string_create("insert");
|
|
|
|
|
set = json_array_create_2(json_string_create("set"), ins_set);
|
|
|
|
|
mutation = json_array_create_3(col_name, mutator, set);
|
|
|
|
|
json_array_add(mutations, mutation);
|
|
|
|
|
any_mutations = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(ins_set);
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return any_mutations;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Attempts to commit 'txn'. Returns the status of the commit operation, one
|
|
|
|
|
* of the following TXN_* constants:
|
|
|
|
|
*
|
|
|
|
|
* TXN_INCOMPLETE:
|
|
|
|
|
*
|
|
|
|
|
* The transaction is in progress, but not yet complete. The caller
|
|
|
|
|
* should call again later, after calling ovsdb_idl_run() to let the IDL
|
|
|
|
|
* do OVSDB protocol processing.
|
|
|
|
|
*
|
|
|
|
|
* TXN_UNCHANGED:
|
|
|
|
|
*
|
|
|
|
|
* The transaction is complete. (It didn't actually change the database,
|
|
|
|
|
* so the IDL didn't send any request to the database server.)
|
|
|
|
|
*
|
|
|
|
|
* TXN_ABORTED:
|
|
|
|
|
*
|
|
|
|
|
* The caller previously called ovsdb_idl_txn_abort().
|
|
|
|
|
*
|
|
|
|
|
* TXN_SUCCESS:
|
|
|
|
|
*
|
|
|
|
|
* The transaction was successful. The update made by the transaction
|
|
|
|
|
* (and possibly other changes made by other database clients) should
|
|
|
|
|
* already be visible in the IDL.
|
|
|
|
|
*
|
|
|
|
|
* TXN_TRY_AGAIN:
|
|
|
|
|
*
|
|
|
|
|
* The transaction failed for some transient reason, e.g. because a
|
|
|
|
|
* "verify" operation reported an inconsistency or due to a network
|
|
|
|
|
* problem. The caller should wait for a change to the database, then
|
|
|
|
|
* compose a new transaction, and commit the new transaction.
|
|
|
|
|
*
|
|
|
|
|
* Use the return value of ovsdb_idl_get_seqno() to wait for a change in
|
|
|
|
|
* the database. It is important to use its return value *before* the
|
|
|
|
|
* initial call to ovsdb_idl_txn_commit() as the baseline for this
|
|
|
|
|
* purpose, because the change that one should wait for can happen after
|
|
|
|
|
* the initial call but before the call that returns TXN_TRY_AGAIN, and
|
|
|
|
|
* using some other baseline value in that situation could cause an
|
|
|
|
|
* indefinite wait if the database rarely changes.
|
|
|
|
|
*
|
|
|
|
|
* TXN_NOT_LOCKED:
|
|
|
|
|
*
|
|
|
|
|
* The transaction failed because the IDL has been configured to require
|
|
|
|
|
* a database lock (with ovsdb_idl_set_lock()) but didn't get it yet or
|
|
|
|
|
* has already lost it.
|
|
|
|
|
*
|
|
|
|
|
* Committing a transaction rolls back all of the changes that it made to the
|
|
|
|
|
* IDL's copy of the database. If the transaction commits successfully, then
|
|
|
|
|
* the database server will send an update and, thus, the IDL will be updated
|
|
|
|
|
* with the committed changes. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
enum ovsdb_idl_txn_status
|
|
|
|
|
ovsdb_idl_txn_commit(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row;
|
|
|
|
|
struct json *operations;
|
|
|
|
|
bool any_updates;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (txn != txn->db->txn) {
|
2014-05-29 23:44:37 -07:00
|
|
|
|
goto coverage_out;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2018-11-13 09:20:50 -08:00
|
|
|
|
/* If we're still connecting or re-connecting, don't bother sending a
|
|
|
|
|
* transaction. */
|
|
|
|
|
if (txn->db->idl->state != IDL_S_MONITORING) {
|
|
|
|
|
txn->status = TXN_TRY_AGAIN;
|
|
|
|
|
goto disassemble_out;
|
|
|
|
|
}
|
|
|
|
|
|
2011-07-26 16:49:03 -07:00
|
|
|
|
/* If we need a lock but don't have it, give up quickly. */
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (txn->db->lock_name && !txn->db->has_lock) {
|
2011-07-26 16:49:03 -07:00
|
|
|
|
txn->status = TXN_NOT_LOCKED;
|
2014-05-29 23:44:37 -07:00
|
|
|
|
goto disassemble_out;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
2010-02-09 10:17:58 -08:00
|
|
|
|
operations = json_array_create_1(
|
2017-12-15 10:59:36 -08:00
|
|
|
|
json_string_create(txn->db->class_->database));
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2011-07-26 16:49:03 -07:00
|
|
|
|
/* Assert that we have the required lock (avoiding a race). */
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (txn->db->lock_name) {
|
2011-07-26 16:49:03 -07:00
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
json_object_put_string(op, "op", "assert");
|
2017-12-15 10:59:36 -08:00
|
|
|
|
json_object_put_string(op, "lock", txn->db->lock_name);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
/* Add prerequisites and declarations of new rows. */
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH (row, txn_node, &txn->txn_rows) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
/* XXX check that deleted rows exist even if no prereqs? */
|
|
|
|
|
if (row->prereqs) {
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
size_t n_columns = class->n_columns;
|
|
|
|
|
struct json *op, *columns, *row_json;
|
|
|
|
|
size_t idx;
|
|
|
|
|
|
|
|
|
|
op = json_object_create();
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
json_object_put_string(op, "op", "wait");
|
|
|
|
|
json_object_put_string(op, "table", class->name);
|
|
|
|
|
json_object_put(op, "timeout", json_integer_create(0));
|
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
json_object_put_string(op, "until", "==");
|
|
|
|
|
columns = json_array_create_empty();
|
|
|
|
|
json_object_put(op, "columns", columns);
|
|
|
|
|
row_json = json_object_create();
|
|
|
|
|
json_object_put(op, "rows", json_array_create_1(row_json));
|
|
|
|
|
|
|
|
|
|
BITMAP_FOR_EACH_1 (idx, n_columns, row->prereqs) {
|
|
|
|
|
const struct ovsdb_idl_column *column = &class->columns[idx];
|
|
|
|
|
json_array_add(columns, json_string_create(column->name));
|
|
|
|
|
json_object_put(row_json, column->name,
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovsdb_datum_to_json(&row->old_datum[idx],
|
2009-12-07 17:08:04 -08:00
|
|
|
|
&column->type));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add updates. */
|
|
|
|
|
any_updates = false;
|
2018-05-17 13:16:55 -04:00
|
|
|
|
|
|
|
|
|
/* For tables constrained to have only a single row (a fairly common OVSDB
|
|
|
|
|
* pattern for storing global data), identify whether we're inserting a
|
|
|
|
|
* row. If so, then verify that the table is empty before inserting the
|
|
|
|
|
* row. This gives us a clear verification-related failure if there was an
|
|
|
|
|
* insertion race with another client. */
|
|
|
|
|
for (size_t i = 0; i < txn->db->class_->n_tables; i++) {
|
|
|
|
|
struct ovsdb_idl_table *table = &txn->db->tables[i];
|
|
|
|
|
if (table->class_->is_singleton) {
|
|
|
|
|
/* Count the number of rows in the table before and after our
|
|
|
|
|
* transaction commits. This is O(n) in the number of rows in the
|
|
|
|
|
* table, but that's OK since we know that the table should only
|
|
|
|
|
* have one row. */
|
|
|
|
|
size_t initial_rows = 0;
|
|
|
|
|
size_t final_rows = 0;
|
|
|
|
|
HMAP_FOR_EACH (row, hmap_node, &table->rows) {
|
|
|
|
|
initial_rows += row->old_datum != NULL;
|
|
|
|
|
final_rows += row->new_datum != NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (initial_rows == 0 && final_rows == 1) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
json_object_put_string(op, "op", "wait");
|
|
|
|
|
json_object_put_string(op, "table", table->class_->name);
|
|
|
|
|
json_object_put(op, "where", json_array_create_empty());
|
|
|
|
|
json_object_put(op, "timeout", json_integer_create(0));
|
|
|
|
|
json_object_put_string(op, "until", "==");
|
|
|
|
|
json_object_put(op, "rows", json_array_create_empty());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH (row, txn_node, &txn->txn_rows) {
|
2017-08-11 11:06:44 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class = row->table->class_;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
if (!row->new_datum) {
|
2011-04-12 11:31:58 -07:00
|
|
|
|
if (class->is_root) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "delete");
|
|
|
|
|
json_object_put_string(op, "table", class->name);
|
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
any_updates = true;
|
|
|
|
|
} else {
|
|
|
|
|
/* Let ovsdb-server decide whether to really delete it. */
|
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
} else if (row->old_datum != row->new_datum) {
|
2009-12-11 10:46:59 -08:00
|
|
|
|
struct json *row_json;
|
|
|
|
|
size_t idx;
|
|
|
|
|
|
2017-09-12 12:57:46 -07:00
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op",
|
|
|
|
|
row->old_datum ? "update" : "insert");
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_object_put_string(op, "table", class->name);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum) {
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
} else {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_idl_txn_insert *insert;
|
|
|
|
|
|
2011-06-14 15:00:50 -07:00
|
|
|
|
any_updates = true;
|
|
|
|
|
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_object_put(op, "uuid-name",
|
|
|
|
|
json_string_create_nocopy(
|
2017-12-21 16:41:30 -08:00
|
|
|
|
ovsdb_data_row_name(&row->uuid)));
|
2010-01-28 13:23:30 -08:00
|
|
|
|
|
|
|
|
|
insert = xmalloc(sizeof *insert);
|
|
|
|
|
insert->dummy = row->uuid;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
insert->op_index = operations->array.n - 1;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
uuid_zero(&insert->real);
|
|
|
|
|
hmap_insert(&txn->inserted_rows, &insert->hmap_node,
|
|
|
|
|
uuid_hash(&insert->dummy));
|
2009-12-11 10:46:59 -08:00
|
|
|
|
}
|
|
|
|
|
row_json = json_object_create();
|
|
|
|
|
json_object_put(op, "row", row_json);
|
|
|
|
|
|
2010-06-24 15:31:18 -07:00
|
|
|
|
if (row->written) {
|
|
|
|
|
BITMAP_FOR_EACH_1 (idx, class->n_columns, row->written) {
|
|
|
|
|
const struct ovsdb_idl_column *column =
|
|
|
|
|
&class->columns[idx];
|
|
|
|
|
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum
|
2017-08-11 11:06:46 -07:00
|
|
|
|
|| !ovsdb_datum_is_default(&row->new_datum[idx],
|
2010-06-24 15:31:18 -07:00
|
|
|
|
&column->type)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
struct json *value;
|
|
|
|
|
|
|
|
|
|
value = ovsdb_datum_to_json(&row->new_datum[idx],
|
|
|
|
|
&column->type);
|
2010-06-24 15:31:18 -07:00
|
|
|
|
json_object_put(row_json, column->name,
|
2017-08-11 11:06:46 -07:00
|
|
|
|
substitute_uuids(value, txn));
|
2011-06-14 15:00:50 -07:00
|
|
|
|
|
|
|
|
|
/* If anything really changed, consider it an update.
|
|
|
|
|
* We can't suppress not-really-changed values earlier
|
|
|
|
|
* or transactions would become nonatomic (see the big
|
|
|
|
|
* comment inside ovsdb_idl_txn_write()). */
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!any_updates && row->old_datum &&
|
|
|
|
|
!ovsdb_datum_equals(&row->old_datum[idx],
|
2017-08-11 11:06:46 -07:00
|
|
|
|
&row->new_datum[idx],
|
2011-06-14 15:00:50 -07:00
|
|
|
|
&column->type)) {
|
|
|
|
|
any_updates = true;
|
|
|
|
|
}
|
2010-06-24 15:31:18 -07:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
2009-12-11 10:46:59 -08:00
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!row->old_datum || !shash_is_empty(json_object(row_json))) {
|
2009-12-11 10:46:59 -08:00
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(op);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Add mutate operation, for partial map or partial set updates. */
|
|
|
|
|
if (row->map_op_written || row->set_op_written) {
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
struct json *op, *mutations;
|
|
|
|
|
bool any_mutations;
|
|
|
|
|
|
|
|
|
|
op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "mutate");
|
|
|
|
|
json_object_put_string(op, "table", class->name);
|
|
|
|
|
json_object_put(op, "where", where_uuid_equals(&row->uuid));
|
|
|
|
|
mutations = json_array_create_empty();
|
|
|
|
|
any_mutations = ovsdb_idl_txn_extract_mutations(row, mutations);
|
|
|
|
|
json_object_put(op, "mutations", mutations);
|
|
|
|
|
|
|
|
|
|
if (any_mutations) {
|
|
|
|
|
op = substitute_uuids(op, txn);
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
any_updates = true;
|
|
|
|
|
} else {
|
|
|
|
|
json_destroy(op);
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-16 16:26:17 -08:00
|
|
|
|
/* Add increment. */
|
2016-08-07 20:44:51 -07:00
|
|
|
|
if (txn->inc_table && (any_updates || txn->inc_force)) {
|
|
|
|
|
any_updates = true;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
txn->inc_index = operations->array.n - 1;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
|
2016-08-07 20:44:51 -07:00
|
|
|
|
struct json *op = json_object_create();
|
2009-12-16 16:26:17 -08:00
|
|
|
|
json_object_put_string(op, "op", "mutate");
|
|
|
|
|
json_object_put_string(op, "table", txn->inc_table);
|
|
|
|
|
json_object_put(op, "where",
|
2012-04-12 08:25:10 -07:00
|
|
|
|
substitute_uuids(where_uuid_equals(&txn->inc_row),
|
|
|
|
|
txn));
|
2009-12-16 16:26:17 -08:00
|
|
|
|
json_object_put(op, "mutations",
|
|
|
|
|
json_array_create_1(
|
|
|
|
|
json_array_create_3(
|
|
|
|
|
json_string_create(txn->inc_column),
|
|
|
|
|
json_string_create("+="),
|
|
|
|
|
json_integer_create(1))));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
|
|
|
|
|
op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "select");
|
|
|
|
|
json_object_put_string(op, "table", txn->inc_table);
|
|
|
|
|
json_object_put(op, "where",
|
2012-04-12 08:25:10 -07:00
|
|
|
|
substitute_uuids(where_uuid_equals(&txn->inc_row),
|
|
|
|
|
txn));
|
2009-12-16 16:26:17 -08:00
|
|
|
|
json_object_put(op, "columns",
|
|
|
|
|
json_array_create_1(json_string_create(
|
|
|
|
|
txn->inc_column)));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-16 13:30:53 -08:00
|
|
|
|
if (txn->comment.length) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "comment");
|
|
|
|
|
json_object_put_string(op, "comment", ds_cstr(&txn->comment));
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-11 11:28:36 -08:00
|
|
|
|
if (txn->dry_run) {
|
|
|
|
|
struct json *op = json_object_create();
|
|
|
|
|
json_object_put_string(op, "op", "abort");
|
|
|
|
|
json_array_add(operations, op);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-08 17:14:36 -08:00
|
|
|
|
if (!any_updates) {
|
2009-12-16 16:26:17 -08:00
|
|
|
|
txn->status = TXN_UNCHANGED;
|
2010-01-12 10:51:52 -08:00
|
|
|
|
json_destroy(operations);
|
2018-06-18 11:36:49 -07:00
|
|
|
|
} else if (txn->db->idl->session
|
|
|
|
|
&& !jsonrpc_session_send(
|
2017-12-15 10:59:36 -08:00
|
|
|
|
txn->db->idl->session,
|
2009-12-08 17:14:36 -08:00
|
|
|
|
jsonrpc_create_request(
|
|
|
|
|
"transact", operations, &txn->request_id))) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_insert(&txn->db->outstanding_txns, &txn->hmap_node,
|
2009-12-08 17:14:36 -08:00
|
|
|
|
json_hash(txn->request_id, 0));
|
2011-06-20 16:17:44 -07:00
|
|
|
|
txn->status = TXN_INCOMPLETE;
|
2009-12-08 17:14:36 -08:00
|
|
|
|
} else {
|
2012-03-27 10:16:52 -07:00
|
|
|
|
txn->status = TXN_TRY_AGAIN;
|
2009-12-08 17:14:36 -08:00
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2014-05-29 23:44:37 -07:00
|
|
|
|
disassemble_out:
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_disassemble(txn);
|
2014-05-29 23:44:37 -07:00
|
|
|
|
coverage_out:
|
|
|
|
|
switch (txn->status) {
|
|
|
|
|
case TXN_UNCOMMITTED: COVERAGE_INC(txn_uncommitted); break;
|
|
|
|
|
case TXN_UNCHANGED: COVERAGE_INC(txn_unchanged); break;
|
|
|
|
|
case TXN_INCOMPLETE: COVERAGE_INC(txn_incomplete); break;
|
|
|
|
|
case TXN_ABORTED: COVERAGE_INC(txn_aborted); break;
|
|
|
|
|
case TXN_SUCCESS: COVERAGE_INC(txn_success); break;
|
|
|
|
|
case TXN_TRY_AGAIN: COVERAGE_INC(txn_try_again); break;
|
|
|
|
|
case TXN_NOT_LOCKED: COVERAGE_INC(txn_not_locked); break;
|
|
|
|
|
case TXN_ERROR: COVERAGE_INC(txn_error); break;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return txn->status;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-03 12:55:39 -08:00
|
|
|
|
/* Attempts to commit 'txn', blocking until the commit either succeeds or
|
|
|
|
|
* fails. Returns the final commit status, which may be any TXN_* value other
|
2012-04-12 08:27:56 -07:00
|
|
|
|
* than TXN_INCOMPLETE.
|
|
|
|
|
*
|
|
|
|
|
* This function calls ovsdb_idl_run() on 'txn''s IDL, so it may cause the
|
|
|
|
|
* return value of ovsdb_idl_get_seqno() to change. */
|
2010-03-03 12:55:39 -08:00
|
|
|
|
enum ovsdb_idl_txn_status
|
|
|
|
|
ovsdb_idl_txn_commit_block(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
enum ovsdb_idl_txn_status status;
|
|
|
|
|
|
2010-04-13 09:28:13 -07:00
|
|
|
|
fatal_signal_run();
|
2010-03-03 12:55:39 -08:00
|
|
|
|
while ((status = ovsdb_idl_txn_commit(txn)) == TXN_INCOMPLETE) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_run(txn->db->idl);
|
|
|
|
|
ovsdb_idl_wait(txn->db->idl);
|
2010-03-03 12:55:39 -08:00
|
|
|
|
ovsdb_idl_txn_wait(txn);
|
|
|
|
|
poll_block();
|
|
|
|
|
}
|
|
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns the final (incremented) value of the column in 'txn' that was set to
|
|
|
|
|
* be incremented by ovsdb_idl_txn_increment(). 'txn' must have committed
|
|
|
|
|
* successfully. */
|
2009-12-16 16:26:17 -08:00
|
|
|
|
int64_t
|
|
|
|
|
ovsdb_idl_txn_get_increment_new_value(const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(txn->status == TXN_SUCCESS);
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return txn->inc_new_value;
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Aborts 'txn' without sending it to the database server. This is effective
|
|
|
|
|
* only if ovsdb_idl_txn_commit() has not yet been called for 'txn'.
|
|
|
|
|
* Otherwise, it has no effect.
|
|
|
|
|
*
|
|
|
|
|
* Aborting a transaction doesn't free its memory. Use
|
|
|
|
|
* ovsdb_idl_txn_destroy() to do that. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_abort(struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_txn_disassemble(txn);
|
2011-06-20 16:17:44 -07:00
|
|
|
|
if (txn->status == TXN_UNCOMMITTED || txn->status == TXN_INCOMPLETE) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
txn->status = TXN_ABORTED;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns a string that reports the error status for 'txn'. The caller must
|
|
|
|
|
* not modify or free the returned string. A call to ovsdb_idl_txn_destroy()
|
|
|
|
|
* for 'txn' may free the returned string.
|
|
|
|
|
*
|
|
|
|
|
* The return value is ordinarily one of the strings that
|
|
|
|
|
* ovsdb_idl_txn_status_to_string() would return, but if the transaction failed
|
|
|
|
|
* due to an error reported by the database server, the return value is that
|
|
|
|
|
* error. */
|
2010-02-05 14:11:12 -08:00
|
|
|
|
const char *
|
|
|
|
|
ovsdb_idl_txn_get_error(const struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
|
|
|
|
if (txn->status != TXN_ERROR) {
|
|
|
|
|
return ovsdb_idl_txn_status_to_string(txn->status);
|
|
|
|
|
} else if (txn->error) {
|
|
|
|
|
return txn->error;
|
|
|
|
|
} else {
|
|
|
|
|
return "no error details available";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_set_error_json(struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct json *json)
|
|
|
|
|
{
|
2017-12-31 21:15:58 -08:00
|
|
|
|
if (json && txn->error == NULL) {
|
2010-02-05 14:11:12 -08:00
|
|
|
|
txn->error = json_to_string(json, JSSF_SORT);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
/* For transaction 'txn' that completed successfully, finds and returns the
|
|
|
|
|
* permanent UUID that the database assigned to a newly inserted row, given the
|
|
|
|
|
* 'uuid' that ovsdb_idl_txn_insert() assigned locally to that row.
|
|
|
|
|
*
|
|
|
|
|
* Returns NULL if 'uuid' is not a UUID assigned by ovsdb_idl_txn_insert() or
|
|
|
|
|
* if it was assigned by that function and then deleted by
|
|
|
|
|
* ovsdb_idl_txn_delete() within the same transaction. (Rows that are inserted
|
|
|
|
|
* and then deleted within a single transaction are never sent to the database
|
|
|
|
|
* server, so it never assigns them a permanent UUID.) */
|
|
|
|
|
const struct uuid *
|
|
|
|
|
ovsdb_idl_txn_get_insert_uuid(const struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct uuid *uuid)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_txn_insert *insert;
|
|
|
|
|
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(txn->status == TXN_SUCCESS || txn->status == TXN_UNCHANGED);
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_IN_BUCKET (insert, hmap_node,
|
2010-01-28 13:23:30 -08:00
|
|
|
|
uuid_hash(uuid), &txn->inserted_rows) {
|
|
|
|
|
if (uuid_equals(uuid, &insert->dummy)) {
|
|
|
|
|
return &insert->real;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_complete(struct ovsdb_idl_txn *txn,
|
|
|
|
|
enum ovsdb_idl_txn_status status)
|
|
|
|
|
{
|
|
|
|
|
txn->status = status;
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_remove(&txn->db->outstanding_txns, &txn->hmap_node);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2013-03-05 15:30:33 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_write__(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum, bool owns_datum)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
2012-07-13 16:00:29 -07:00
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2011-10-26 15:46:48 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
bool write_only;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
|
2016-10-07 09:47:43 -07:00
|
|
|
|
ovs_assert(!column->is_synthetic);
|
2011-10-26 15:46:48 -07:00
|
|
|
|
if (ovsdb_idl_row_is_synthetic(row)) {
|
2013-03-05 15:30:33 -08:00
|
|
|
|
goto discard_datum;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
column_idx = column - class->columns;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
write_only = row->table->modes[column_idx] == OVSDB_IDL_MONITOR;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(column_idx < class->n_columns);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(row->old_datum == NULL ||
|
2012-11-06 13:14:55 -08:00
|
|
|
|
row->table->modes[column_idx] & OVSDB_IDL_MONITOR);
|
2010-08-11 15:41:41 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (row->table->db->verify_write_only && !write_only) {
|
2012-09-20 11:13:15 -07:00
|
|
|
|
VLOG_ERR("Bug: Attempt to write to a read/write column (%s:%s) when"
|
|
|
|
|
" explicitly configured not to.", class->name, column->name);
|
2013-03-05 15:30:33 -08:00
|
|
|
|
goto discard_datum;
|
2012-09-20 11:13:15 -07:00
|
|
|
|
}
|
|
|
|
|
|
2011-04-01 10:50:52 -07:00
|
|
|
|
/* If this is a write-only column and the datum being written is the same
|
|
|
|
|
* as the one already there, just skip the update entirely. This is worth
|
|
|
|
|
* optimizing because we have a lot of columns that get periodically
|
|
|
|
|
* refreshed into the database but don't actually change that often.
|
|
|
|
|
*
|
|
|
|
|
* We don't do this for read/write columns because that would break
|
|
|
|
|
* atomicity of transactions--some other client might have written a
|
2011-06-14 15:00:50 -07:00
|
|
|
|
* different value in that column since we read it. (But if a whole
|
|
|
|
|
* transaction only does writes of existing values, without making any real
|
|
|
|
|
* changes, we will drop the whole transaction later in
|
|
|
|
|
* ovsdb_idl_txn_commit().) */
|
2020-05-15 06:46:55 -07:00
|
|
|
|
if (datum->keys && datum->values &&
|
|
|
|
|
write_only && ovsdb_datum_equals(ovsdb_idl_read(row, column),
|
2012-09-20 11:13:15 -07:00
|
|
|
|
datum, &column->type)) {
|
2013-03-05 15:30:33 -08:00
|
|
|
|
goto discard_datum;
|
2011-04-01 10:50:52 -07:00
|
|
|
|
}
|
|
|
|
|
|
2018-08-14 11:31:46 -07:00
|
|
|
|
bool index_row = is_index_row(row);
|
|
|
|
|
if (!index_row) {
|
|
|
|
|
ovsdb_idl_remove_from_indexes(row);
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_insert(&row->table->db->txn->txn_rows, &row->txn_node,
|
2009-12-07 17:08:04 -08:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (row->old_datum == row->new_datum) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = xmalloc(class->n_columns * sizeof *row->new_datum);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
if (!row->written) {
|
|
|
|
|
row->written = bitmap_allocate(class->n_columns);
|
|
|
|
|
}
|
|
|
|
|
if (bitmap_is_set(row->written, column_idx)) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovsdb_datum_destroy(&row->new_datum[column_idx], &column->type);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
} else {
|
|
|
|
|
bitmap_set1(row->written, column_idx);
|
|
|
|
|
}
|
2013-03-05 15:30:33 -08:00
|
|
|
|
if (owns_datum) {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum[column_idx] = *datum;
|
2013-03-05 15:30:33 -08:00
|
|
|
|
} else {
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovsdb_datum_clone(&row->new_datum[column_idx], datum, &column->type);
|
2013-03-05 15:30:33 -08:00
|
|
|
|
}
|
2010-01-25 10:15:17 -08:00
|
|
|
|
(column->unparse)(row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
(column->parse)(row, &row->new_datum[column_idx]);
|
ovsdb-idl: Mark row "parsed" in ovsdb_idl_txn_write__
Once a column is set in a row using ovsdb_idl_txn_write__ we also mark
the row "parsed". Otherwise the memory allocated by
sbrec_<table>_parse_<col>() will never be freed. After marking the row
"parsed", the ovsdb_idl_txn_disassemble function will properly free the
newly allocated memory for the column (ovsdb_idl_row_unparse).
The problem is present only for rows that are inserted by the
running application because rows that are loaded from the database
will always have row->parsed == true.
One way to detect the leak is to start northd with valgrind:
valgrind --tool=memcheck --leak-check=yes ./ovn-northd
Then create a logical switch and bind a logical port to it:
ovn-nbctl ls-add ls1
ovn-nbctl lsp-add ls1 ls1-vm1
The valgrind report:
==9270== Memcheck, a memory error detector
==9270== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9270== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright
info
==9270== Command: ./ovn-northd
==9270==
<snip>
==9270==
==9270== 8 bytes in 1 blocks are definitely lost in loss record 30 of
292
==9270== at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==9270== by 0x4D31EF: xmalloc (util.c:138)
==9270== by 0x45CB8E: sbrec_multicast_group_parse_ports (ovn-sb-idl.c:18141)
==9270== by 0x4BB12D: ovsdb_idl_txn_write__ (ovsdb-idl.c:4489)
==9270== by 0x4BB1B5: ovsdb_idl_txn_write (ovsdb-idl.c:4527)
==9270== by 0x45D167: sbrec_multicast_group_set_ports (ovn-sb-idl.c:18561)
==9270== by 0x40F416: ovn_multicast_update_sbrec (ovn-northd.c:2947)
==9270== by 0x41FC55: build_lflows (ovn-northd.c:7981)
==9270== by 0x421830: ovnnb_db_run (ovn-northd.c:8522)
==9270== by 0x422B2D: ovn_db_run (ovn-northd.c:9089)
==9270== by 0x423909: main (ovn-northd.c:9409)
==9270==
==9270== 157 (32 direct, 125 indirect) bytes in 1 blocks are definitely
lost in loss record 199 of 292
==9270== at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==9270== by 0x4D31EF: xmalloc (util.c:138)
==9270== by 0x471E3D: resize (hmap.c:100)
==9270== by 0x4720C8: hmap_expand_at (hmap.c:175)
==9270== by 0x4C74F1: hmap_insert_at (hmap.h:277)
==9270== by 0x4C825A: smap_add__ (smap.c:392)
==9270== by 0x4C7783: smap_add (smap.c:55)
==9270== by 0x451054: sbrec_datapath_binding_parse_external_ids (ovn-sb-idl.c:7181)
==9270== by 0x4BB12D: ovsdb_idl_txn_write__ (ovsdb-idl.c:4489)
==9270== by 0x4BB1B5: ovsdb_idl_txn_write (ovsdb-idl.c:4527)
==9270== by 0x451436: sbrec_datapath_binding_set_external_ids (ovn-sb-idl.c:7444)
==9270== by 0x4090F1: ovn_datapath_update_external_ids (ovn-northd.c:817)
==9270==
<snip>
==9270==
==9270== LEAK SUMMARY:
==9270== definitely lost: 1,322 bytes in 47 blocks
==9270== indirectly lost: 4,653 bytes in 240 blocks
==9270== possibly lost: 0 bytes in 0 blocks
==9270== still reachable: 254,004 bytes in 7,780 blocks
==9270== suppressed: 0 bytes in 0 blocks
==9270== Reachable blocks (those to which a pointer was found) are not
shown.
==9270== To see them, rerun with: --leak-check=full
--show-leak-kinds=all
==9270==
==9270== For counts of detected and suppressed errors, rerun with: -v
==9270== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)
Signed-off-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
2019-07-17 21:05:04 +02:00
|
|
|
|
row->parsed = true;
|
2018-08-14 11:31:46 -07:00
|
|
|
|
if (!index_row) {
|
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
|
|
|
|
}
|
2013-03-05 15:30:33 -08:00
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
discard_datum:
|
|
|
|
|
if (owns_datum) {
|
|
|
|
|
ovsdb_datum_destroy(datum, &column->type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-31 11:34:53 -07:00
|
|
|
|
/* Writes 'datum' to the specified 'column' in 'row_'. Updates both 'row_'
|
|
|
|
|
* itself and the structs derived from it (e.g. the "struct ovsrec_*", for
|
|
|
|
|
* ovs-vswitchd).
|
|
|
|
|
*
|
2016-08-31 11:42:53 -07:00
|
|
|
|
* 'datum' must have the correct type for its column, but it needs not be
|
|
|
|
|
* sorted or unique because this function will take care of that. The IDL does
|
|
|
|
|
* not check that it meets schema constraints, but ovsdb-server will do so at
|
|
|
|
|
* commit time so it had better be correct.
|
2016-08-31 11:34:53 -07:00
|
|
|
|
*
|
|
|
|
|
* A transaction must be in progress. Replication of 'column' must not have
|
|
|
|
|
* been disabled (by calling ovsdb_idl_omit()).
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "set" functions
|
|
|
|
|
* generated by ovsdb-idlc.
|
|
|
|
|
*
|
|
|
|
|
* Takes ownership of what 'datum' points to (and in some cases destroys that
|
|
|
|
|
* data before returning) but makes a copy of 'datum' itself. (Commonly
|
|
|
|
|
* 'datum' is on the caller's stack.) */
|
2013-03-05 15:30:33 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
2016-08-31 11:42:53 -07:00
|
|
|
|
ovsdb_datum_sort_unique(datum,
|
|
|
|
|
column->type.key.type, column->type.value.type);
|
2013-03-05 15:30:33 -08:00
|
|
|
|
ovsdb_idl_txn_write__(row, column, datum, true);
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-31 11:42:53 -07:00
|
|
|
|
/* Similar to ovsdb_idl_txn_write(), except:
|
|
|
|
|
*
|
|
|
|
|
* - The caller retains ownership of 'datum' and what it points to.
|
|
|
|
|
*
|
|
|
|
|
* - The caller must ensure that 'datum' is sorted and unique (e.g. via
|
|
|
|
|
* ovsdb_datum_sort_unique().) */
|
2013-03-05 15:30:33 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write_clone(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
const struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_txn_write__(row, column,
|
|
|
|
|
CONST_CAST(struct ovsdb_datum *, datum), false);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-10-25 10:43:28 -07:00
|
|
|
|
/* Causes the original contents of 'column' in 'row_' to be verified as a
|
|
|
|
|
* prerequisite to completing the transaction. That is, if 'column' in 'row_'
|
|
|
|
|
* changed (or if 'row_' was deleted) between the time that the IDL originally
|
|
|
|
|
* read its contents and the time that the transaction commits, then the
|
2016-09-19 16:23:20 -07:00
|
|
|
|
* transaction aborts and ovsdb_idl_txn_commit() returns TXN_TRY_AGAIN.
|
2010-10-25 10:43:28 -07:00
|
|
|
|
*
|
|
|
|
|
* The intention is that, to ensure that no transaction commits based on dirty
|
|
|
|
|
* reads, an application should call ovsdb_idl_txn_verify() on each data item
|
|
|
|
|
* read as part of a read-modify-write operation.
|
|
|
|
|
*
|
|
|
|
|
* In some cases ovsdb_idl_txn_verify() reduces to a no-op, because the current
|
|
|
|
|
* value of 'column' is already known:
|
|
|
|
|
*
|
|
|
|
|
* - If 'row_' is a row created by the current transaction (returned by
|
|
|
|
|
* ovsdb_idl_txn_insert()).
|
|
|
|
|
*
|
|
|
|
|
* - If 'column' has already been modified (with ovsdb_idl_txn_write())
|
|
|
|
|
* within the current transaction.
|
|
|
|
|
*
|
|
|
|
|
* Because of the latter property, always call ovsdb_idl_txn_verify() *before*
|
|
|
|
|
* ovsdb_idl_txn_write() for a given read-modify-write.
|
|
|
|
|
*
|
|
|
|
|
* A transaction must be in progress.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "verify"
|
|
|
|
|
* functions generated by ovsdb-idlc. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_verify(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column)
|
|
|
|
|
{
|
2012-07-13 16:00:29 -07:00
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2011-10-26 15:46:48 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
|
|
|
|
|
if (ovsdb_idl_row_is_synthetic(row)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2011-10-26 15:46:48 -07:00
|
|
|
|
column_idx = column - class->columns;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
ovs_assert(row->old_datum == NULL ||
|
2012-11-06 13:14:55 -08:00
|
|
|
|
row->table->modes[column_idx] & OVSDB_IDL_MONITOR);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!row->old_datum
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|| (row->written && bitmap_is_set(row->written, column_idx))) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_insert(&row->table->db->txn->txn_rows, &row->txn_node,
|
2009-12-07 17:08:04 -08:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
|
|
|
|
if (!row->prereqs) {
|
|
|
|
|
row->prereqs = bitmap_allocate(class->n_columns);
|
|
|
|
|
}
|
|
|
|
|
bitmap_set1(row->prereqs, column_idx);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-25 10:43:28 -07:00
|
|
|
|
/* Deletes 'row_' from its table. May free 'row_', so it must not be
|
|
|
|
|
* accessed afterward.
|
|
|
|
|
*
|
|
|
|
|
* A transaction must be in progress.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "delete"
|
|
|
|
|
* functions generated by ovsdb-idlc. */
|
2009-12-07 17:08:04 -08:00
|
|
|
|
void
|
2010-01-27 13:04:56 -08:00
|
|
|
|
ovsdb_idl_txn_delete(const struct ovsdb_idl_row *row_)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
2012-07-13 16:00:29 -07:00
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
2010-01-27 13:04:56 -08:00
|
|
|
|
|
2011-10-26 15:46:48 -07:00
|
|
|
|
if (ovsdb_idl_row_is_synthetic(row)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-11 11:06:46 -07:00
|
|
|
|
ovs_assert(row->new_datum != NULL);
|
2018-08-14 11:31:46 -07:00
|
|
|
|
ovs_assert(!is_index_row(row_));
|
|
|
|
|
ovsdb_idl_remove_from_indexes(row_);
|
2017-08-11 11:06:47 -07:00
|
|
|
|
if (!row->old_datum) {
|
2010-02-02 14:03:18 -08:00
|
|
|
|
ovsdb_idl_row_unparse(row);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_row_clear_new(row);
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!row->prereqs);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
hmap_remove(&row->table->rows, &row->hmap_node);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_remove(&row->table->db->txn->txn_rows, &row->txn_node);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
free(row);
|
2010-01-21 10:51:37 -08:00
|
|
|
|
return;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_insert(&row->table->db->txn->txn_rows, &row->txn_node,
|
2009-12-07 17:08:04 -08:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
2009-12-11 13:16:15 -08:00
|
|
|
|
ovsdb_idl_row_clear_new(row);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = NULL;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
|
2010-10-25 10:43:28 -07:00
|
|
|
|
/* Inserts and returns a new row in the table with the specified 'class' in the
|
|
|
|
|
* database with open transaction 'txn'.
|
|
|
|
|
*
|
|
|
|
|
* The new row is assigned a provisional UUID. If 'uuid' is null then one is
|
|
|
|
|
* randomly generated; otherwise 'uuid' should specify a randomly generated
|
|
|
|
|
* UUID not otherwise in use. ovsdb-server will assign a different UUID when
|
|
|
|
|
* 'txn' is committed, but the IDL will replace any uses of the provisional
|
|
|
|
|
* UUID in the data to be to be committed by the UUID assigned by
|
|
|
|
|
* ovsdb-server.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "insert"
|
|
|
|
|
* functions generated by ovsdb-idlc. */
|
2010-01-27 13:04:56 -08:00
|
|
|
|
const struct ovsdb_idl_row *
|
2009-12-07 17:08:04 -08:00
|
|
|
|
ovsdb_idl_txn_insert(struct ovsdb_idl_txn *txn,
|
2010-06-02 11:08:03 -07:00
|
|
|
|
const struct ovsdb_idl_table_class *class,
|
|
|
|
|
const struct uuid *uuid)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = ovsdb_idl_row_create__(class);
|
2010-06-02 11:08:03 -07:00
|
|
|
|
|
|
|
|
|
if (uuid) {
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(!ovsdb_idl_txn_get_row(txn, uuid));
|
2010-06-02 11:08:03 -07:00
|
|
|
|
row->uuid = *uuid;
|
|
|
|
|
} else {
|
|
|
|
|
uuid_generate(&row->uuid);
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
row->table = ovsdb_idl_db_table_from_class(txn->db, class);
|
2017-08-11 11:06:46 -07:00
|
|
|
|
row->new_datum = xmalloc(class->n_columns * sizeof *row->new_datum);
|
2010-01-25 10:15:17 -08:00
|
|
|
|
hmap_insert(&row->table->rows, &row->hmap_node, uuid_hash(&row->uuid));
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hmap_insert(&txn->txn_rows, &row->txn_node, uuid_hash(&row->uuid));
|
2018-08-14 11:31:46 -07:00
|
|
|
|
ovsdb_idl_add_to_indexes(row);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
return row;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_txn_abort_all(struct ovsdb_idl_db *db)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
HMAP_FOR_EACH (txn, hmap_node, &db->outstanding_txns) {
|
2012-03-27 10:16:52 -07:00
|
|
|
|
ovsdb_idl_txn_complete(txn, TXN_TRY_AGAIN);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_abort_all(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_db_txn_abort_all(&idl->server);
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_txn_abort_all(&idl->data);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static struct ovsdb_idl_txn *
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_txn_find(struct ovsdb_idl_db *db, const struct json *id)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH_WITH_HASH (txn, hmap_node,
|
2017-12-15 10:59:36 -08:00
|
|
|
|
json_hash(id, 0), &db->outstanding_txns) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (json_equal(id, txn->request_id)) {
|
|
|
|
|
return txn;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-16 16:26:17 -08:00
|
|
|
|
static bool
|
|
|
|
|
check_json_type(const struct json *json, enum json_type type, const char *name)
|
|
|
|
|
{
|
|
|
|
|
if (!json) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "%s is missing", name);
|
|
|
|
|
return false;
|
|
|
|
|
} else if (json->type != type) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "%s is %s instead of %s",
|
|
|
|
|
name, json_type_to_string(json->type),
|
|
|
|
|
json_type_to_string(type));
|
|
|
|
|
return false;
|
|
|
|
|
} else {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_txn_process_inc_reply(struct ovsdb_idl_txn *txn,
|
|
|
|
|
const struct json_array *results)
|
|
|
|
|
{
|
|
|
|
|
struct json *count, *rows, *row, *column;
|
|
|
|
|
struct shash *mutate, *select;
|
|
|
|
|
|
|
|
|
|
if (txn->inc_index + 2 > results->n) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "reply does not contain enough operations "
|
2013-11-25 23:38:48 -08:00
|
|
|
|
"for increment (has %"PRIuSIZE", needs %u)",
|
2009-12-16 16:26:17 -08:00
|
|
|
|
results->n, txn->inc_index + 2);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
/* We know that this is a JSON object because the loop in
|
2017-12-15 10:59:36 -08:00
|
|
|
|
* ovsdb_idl_db_txn_process_reply() checked. */
|
2009-12-16 16:26:17 -08:00
|
|
|
|
mutate = json_object(results->elems[txn->inc_index]);
|
|
|
|
|
count = shash_find_data(mutate, "count");
|
|
|
|
|
if (!check_json_type(count, JSON_INTEGER, "\"mutate\" reply \"count\"")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (count->integer != 1) {
|
2009-12-16 16:26:17 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl,
|
2010-05-17 15:08:17 +08:00
|
|
|
|
"\"mutate\" reply \"count\" is %lld instead of 1",
|
2018-05-24 10:32:59 -07:00
|
|
|
|
count->integer);
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
select = json_object(results->elems[txn->inc_index + 1]);
|
|
|
|
|
rows = shash_find_data(select, "rows");
|
|
|
|
|
if (!check_json_type(rows, JSON_ARRAY, "\"select\" reply \"rows\"")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (rows->array.n != 1) {
|
2013-11-25 23:38:48 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "\"select\" reply \"rows\" has %"PRIuSIZE" elements "
|
2009-12-16 16:26:17 -08:00
|
|
|
|
"instead of 1",
|
2018-05-24 10:32:59 -07:00
|
|
|
|
rows->array.n);
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
row = rows->array.elems[0];
|
2009-12-16 16:26:17 -08:00
|
|
|
|
if (!check_json_type(row, JSON_OBJECT, "\"select\" reply row")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
column = shash_find_data(json_object(row), txn->inc_column);
|
|
|
|
|
if (!check_json_type(column, JSON_INTEGER,
|
|
|
|
|
"\"select\" reply inc column")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2018-05-24 10:32:59 -07:00
|
|
|
|
txn->inc_new_value = column->integer;
|
2009-12-16 16:26:17 -08:00
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_txn_process_insert_reply(struct ovsdb_idl_txn_insert *insert,
|
|
|
|
|
const struct json_array *results)
|
|
|
|
|
{
|
2010-02-08 14:09:36 -08:00
|
|
|
|
static const struct ovsdb_base_type uuid_type = OVSDB_BASE_UUID_INIT;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_error *error;
|
|
|
|
|
struct json *json_uuid;
|
|
|
|
|
union ovsdb_atom uuid;
|
|
|
|
|
struct shash *reply;
|
|
|
|
|
|
|
|
|
|
if (insert->op_index >= results->n) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "reply does not contain enough operations "
|
2013-11-25 23:38:48 -08:00
|
|
|
|
"for insert (has %"PRIuSIZE", needs %u)",
|
2010-01-28 13:23:30 -08:00
|
|
|
|
results->n, insert->op_index);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We know that this is a JSON object because the loop in
|
|
|
|
|
* ovsdb_idl_txn_process_reply() checked. */
|
|
|
|
|
reply = json_object(results->elems[insert->op_index]);
|
|
|
|
|
json_uuid = shash_find_data(reply, "uuid");
|
|
|
|
|
if (!check_json_type(json_uuid, JSON_ARRAY, "\"insert\" reply \"uuid\"")) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2010-02-08 14:09:36 -08:00
|
|
|
|
error = ovsdb_atom_from_json(&uuid, &uuid_type, json_uuid, NULL);
|
2010-01-28 13:23:30 -08:00
|
|
|
|
if (error) {
|
2017-12-13 11:32:28 -08:00
|
|
|
|
char *s = ovsdb_error_to_string_free(error);
|
2010-01-28 13:23:30 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "\"insert\" reply \"uuid\" is not a JSON "
|
|
|
|
|
"UUID: %s", s);
|
|
|
|
|
free(s);
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
insert->real = uuid.uuid;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2009-12-16 16:26:17 -08:00
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
static bool
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_txn_process_reply(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct jsonrpc_msg *msg)
|
2009-12-07 17:08:04 -08:00
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_txn *txn;
|
|
|
|
|
enum ovsdb_idl_txn_status status;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
txn = ovsdb_idl_db_txn_find(db, msg->id);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (!txn) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (msg->type == JSONRPC_ERROR) {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
if (msg->error
|
|
|
|
|
&& msg->error->type == JSON_STRING
|
|
|
|
|
&& !strcmp(json_string(msg->error), "canceled")) {
|
|
|
|
|
/* ovsdb-server uses this error message to indicate that the
|
|
|
|
|
* transaction was canceled because the database in question was
|
|
|
|
|
* removed, converted, etc. */
|
|
|
|
|
status = TXN_TRY_AGAIN;
|
|
|
|
|
} else {
|
|
|
|
|
status = TXN_ERROR;
|
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, msg->error);
|
|
|
|
|
}
|
2009-12-07 17:08:04 -08:00
|
|
|
|
} else if (msg->result->type != JSON_ARRAY) {
|
|
|
|
|
VLOG_WARN_RL(&syntax_rl, "reply to \"transact\" is not JSON array");
|
|
|
|
|
status = TXN_ERROR;
|
2017-12-31 21:15:58 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, msg->result);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
} else {
|
2018-05-24 10:32:59 -07:00
|
|
|
|
struct json_array *ops = &msg->result->array;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
int hard_errors = 0;
|
|
|
|
|
int soft_errors = 0;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
int lock_errors = 0;
|
2009-12-07 17:08:04 -08:00
|
|
|
|
size_t i;
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
for (i = 0; i < ops->n; i++) {
|
|
|
|
|
struct json *op = ops->elems[i];
|
2009-12-07 17:08:04 -08:00
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
if (op->type == JSON_NULL) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
/* This isn't an error in itself but indicates that some prior
|
|
|
|
|
* operation failed, so make sure that we know about it. */
|
|
|
|
|
soft_errors++;
|
2010-01-28 13:23:30 -08:00
|
|
|
|
} else if (op->type == JSON_OBJECT) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
struct json *error;
|
|
|
|
|
|
2010-01-28 13:23:30 -08:00
|
|
|
|
error = shash_find_data(json_object(op), "error");
|
2009-12-07 17:08:04 -08:00
|
|
|
|
if (error) {
|
|
|
|
|
if (error->type == JSON_STRING) {
|
2018-05-24 10:32:59 -07:00
|
|
|
|
if (!strcmp(error->string, "timed out")) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
soft_errors++;
|
2018-11-13 09:26:40 -08:00
|
|
|
|
} else if (!strcmp(error->string,
|
|
|
|
|
"unknown database")) {
|
|
|
|
|
ovsdb_idl_retry(db->idl);
|
|
|
|
|
soft_errors++;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
} else if (!strcmp(error->string, "not owner")) {
|
2011-07-26 16:49:03 -07:00
|
|
|
|
lock_errors++;
|
2018-05-24 10:32:59 -07:00
|
|
|
|
} else if (!strcmp(error->string, "not allowed")) {
|
2017-05-31 19:04:32 -04:00
|
|
|
|
hard_errors++;
|
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2018-05-24 10:32:59 -07:00
|
|
|
|
} else if (strcmp(error->string, "aborted")) {
|
2009-12-07 17:08:04 -08:00
|
|
|
|
hard_errors++;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2017-05-31 19:04:32 -04:00
|
|
|
|
VLOG_WARN_RL(&other_rl,
|
|
|
|
|
"transaction error: %s", txn->error);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
hard_errors++;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl,
|
|
|
|
|
"\"error\" in reply is not JSON string");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
hard_errors++;
|
2010-02-05 14:11:12 -08:00
|
|
|
|
ovsdb_idl_txn_set_error_json(txn, op);
|
2009-12-07 17:08:04 -08:00
|
|
|
|
VLOG_WARN_RL(&syntax_rl,
|
|
|
|
|
"operation reply is not JSON null or object");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-07-26 16:49:03 -07:00
|
|
|
|
if (!soft_errors && !hard_errors && !lock_errors) {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
struct ovsdb_idl_txn_insert *insert;
|
|
|
|
|
|
|
|
|
|
if (txn->inc_table && !ovsdb_idl_txn_process_inc_reply(txn, ops)) {
|
|
|
|
|
hard_errors++;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-17 10:33:10 -07:00
|
|
|
|
HMAP_FOR_EACH (insert, hmap_node, &txn->inserted_rows) {
|
2010-01-28 13:23:30 -08:00
|
|
|
|
if (!ovsdb_idl_txn_process_insert_reply(insert, ops)) {
|
|
|
|
|
hard_errors++;
|
|
|
|
|
}
|
|
|
|
|
}
|
2009-12-16 16:26:17 -08:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-07 17:08:04 -08:00
|
|
|
|
status = (hard_errors ? TXN_ERROR
|
2011-07-26 16:49:03 -07:00
|
|
|
|
: lock_errors ? TXN_NOT_LOCKED
|
2012-03-27 10:16:52 -07:00
|
|
|
|
: soft_errors ? TXN_TRY_AGAIN
|
2009-12-07 17:08:04 -08:00
|
|
|
|
: TXN_SUCCESS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_complete(txn, status);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2009-12-08 17:14:56 -08:00
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns the transaction currently active for 'row''s IDL. A transaction
|
|
|
|
|
* must currently be active. */
|
2009-12-08 17:14:56 -08:00
|
|
|
|
struct ovsdb_idl_txn *
|
|
|
|
|
ovsdb_idl_txn_get(const struct ovsdb_idl_row *row)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct ovsdb_idl_txn *txn = row->table->db->txn;
|
2012-11-06 13:14:55 -08:00
|
|
|
|
ovs_assert(txn != NULL);
|
2009-12-08 17:14:56 -08:00
|
|
|
|
return txn;
|
|
|
|
|
}
|
2010-03-03 14:27:53 -08:00
|
|
|
|
|
2012-04-12 08:27:56 -07:00
|
|
|
|
/* Returns the IDL on which 'txn' acts. */
|
2010-03-03 14:27:53 -08:00
|
|
|
|
struct ovsdb_idl *
|
|
|
|
|
ovsdb_idl_txn_get_idl (struct ovsdb_idl_txn *txn)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return txn->db->idl;
|
2010-03-03 14:27:53 -08:00
|
|
|
|
}
|
2015-08-04 14:49:11 -07:00
|
|
|
|
|
|
|
|
|
/* Blocks until 'idl' successfully connects to the remote database and
|
|
|
|
|
* retrieves its contents. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_get_initial_snapshot(struct ovsdb_idl *idl)
|
|
|
|
|
{
|
|
|
|
|
while (1) {
|
|
|
|
|
ovsdb_idl_run(idl);
|
|
|
|
|
if (ovsdb_idl_has_ever_connected(idl)) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_wait(idl);
|
|
|
|
|
poll_block();
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct jsonrpc_msg *
|
|
|
|
|
ovsdb_idl_db_set_lock(struct ovsdb_idl_db *db, const char *lock_name)
|
|
|
|
|
{
|
|
|
|
|
ovs_assert(!db->txn);
|
|
|
|
|
ovs_assert(hmap_is_empty(&db->outstanding_txns));
|
|
|
|
|
|
|
|
|
|
if (db->lock_name
|
|
|
|
|
&& (!lock_name || strcmp(lock_name, db->lock_name))) {
|
|
|
|
|
/* Release previous lock. */
|
|
|
|
|
struct jsonrpc_msg *msg = ovsdb_idl_db_compose_unlock_request(db);
|
|
|
|
|
free(db->lock_name);
|
|
|
|
|
db->lock_name = NULL;
|
|
|
|
|
db->is_lock_contended = false;
|
|
|
|
|
return msg;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (lock_name && !db->lock_name) {
|
|
|
|
|
/* Acquire new lock. */
|
|
|
|
|
db->lock_name = xstrdup(lock_name);
|
|
|
|
|
return ovsdb_idl_db_compose_lock_request(db);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2011-07-26 16:49:03 -07:00
|
|
|
|
/* If 'lock_name' is nonnull, configures 'idl' to obtain the named lock from
|
|
|
|
|
* the database server and to avoid modifying the database when the lock cannot
|
|
|
|
|
* be acquired (that is, when another client has the same lock).
|
|
|
|
|
*
|
|
|
|
|
* If 'lock_name' is NULL, drops the locking requirement and releases the
|
|
|
|
|
* lock. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_set_lock(struct ovsdb_idl *idl, const char *lock_name)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
for (;;) {
|
|
|
|
|
struct jsonrpc_msg *msg = ovsdb_idl_db_set_lock(&idl->data, lock_name);
|
|
|
|
|
if (!msg) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2018-06-18 11:36:49 -07:00
|
|
|
|
if (idl->session) {
|
|
|
|
|
jsonrpc_session_send(idl->session, msg);
|
|
|
|
|
}
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'idl' is configured to obtain a lock and owns that lock.
|
|
|
|
|
*
|
|
|
|
|
* Locking and unlocking happens asynchronously from the database client's
|
|
|
|
|
* point of view, so the information is only useful for optimization (e.g. if
|
|
|
|
|
* the client doesn't have the lock then there's no point in trying to write to
|
|
|
|
|
* the database). */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_has_lock(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return idl->data.has_lock;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns true if 'idl' is configured to obtain a lock but the database server
|
|
|
|
|
* has indicated that some other client already owns the requested lock. */
|
|
|
|
|
bool
|
|
|
|
|
ovsdb_idl_is_lock_contended(const struct ovsdb_idl *idl)
|
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return idl->data.is_lock_contended;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_update_has_lock(struct ovsdb_idl_db *db, bool new_has_lock)
|
2011-07-26 16:49:03 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (new_has_lock && !db->has_lock) {
|
2017-12-31 21:15:58 -08:00
|
|
|
|
if (db->idl->state == IDL_S_MONITORING) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->change_seqno++;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
} else {
|
2015-03-19 23:45:42 -07:00
|
|
|
|
/* We're setting up a session, so don't signal that the database
|
|
|
|
|
* changed. Finalizing the session will increment change_seqno
|
2011-07-26 16:49:03 -07:00
|
|
|
|
* anyhow. */
|
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->is_lock_contended = false;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->has_lock = new_has_lock;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_db_process_lock_replies(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct jsonrpc_msg *msg)
|
|
|
|
|
{
|
|
|
|
|
if (msg->type == JSONRPC_REPLY
|
|
|
|
|
&& db->lock_request_id
|
|
|
|
|
&& json_equal(db->lock_request_id, msg->id)) {
|
|
|
|
|
/* Reply to our "lock" request. */
|
|
|
|
|
ovsdb_idl_db_parse_lock_reply(db, msg->result);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (msg->type == JSONRPC_NOTIFY) {
|
|
|
|
|
if (!strcmp(msg->method, "locked")) {
|
|
|
|
|
/* We got our lock. */
|
|
|
|
|
return ovsdb_idl_db_parse_lock_notify(db, msg->params, true);
|
|
|
|
|
} else if (!strcmp(msg->method, "stolen")) {
|
|
|
|
|
/* Someone else stole our lock. */
|
|
|
|
|
return ovsdb_idl_db_parse_lock_notify(db, msg->params, false);
|
|
|
|
|
}
|
|
|
|
|
}
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return false;
|
|
|
|
|
}
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct jsonrpc_msg *
|
|
|
|
|
ovsdb_idl_db_compose_lock_request__(struct ovsdb_idl_db *db,
|
|
|
|
|
const char *method)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_db_update_has_lock(db, false);
|
|
|
|
|
|
|
|
|
|
json_destroy(db->lock_request_id);
|
|
|
|
|
db->lock_request_id = NULL;
|
|
|
|
|
|
|
|
|
|
struct json *params = json_array_create_1(json_string_create(
|
|
|
|
|
db->lock_name));
|
|
|
|
|
return jsonrpc_create_request(method, params, NULL);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
2010-03-03 14:27:53 -08:00
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct jsonrpc_msg *
|
|
|
|
|
ovsdb_idl_db_compose_lock_request(struct ovsdb_idl_db *db)
|
2011-07-26 16:49:03 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
struct jsonrpc_msg *msg = ovsdb_idl_db_compose_lock_request__(db, "lock");
|
|
|
|
|
db->lock_request_id = json_clone(msg->id);
|
|
|
|
|
return msg;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static struct jsonrpc_msg *
|
|
|
|
|
ovsdb_idl_db_compose_unlock_request(struct ovsdb_idl_db *db)
|
2011-07-26 16:49:03 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return ovsdb_idl_db_compose_lock_request__(db, "unlock");
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_parse_lock_reply(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct json *result)
|
2011-07-26 16:49:03 -07:00
|
|
|
|
{
|
|
|
|
|
bool got_lock;
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
json_destroy(db->lock_request_id);
|
|
|
|
|
db->lock_request_id = NULL;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
|
|
|
|
|
if (result->type == JSON_OBJECT) {
|
|
|
|
|
const struct json *locked;
|
|
|
|
|
|
|
|
|
|
locked = shash_find_data(json_object(result), "locked");
|
|
|
|
|
got_lock = locked && locked->type == JSON_TRUE;
|
|
|
|
|
} else {
|
|
|
|
|
got_lock = false;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
ovsdb_idl_db_update_has_lock(db, got_lock);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
if (!got_lock) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->is_lock_contended = true;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
static bool
|
|
|
|
|
ovsdb_idl_db_parse_lock_notify(struct ovsdb_idl_db *db,
|
|
|
|
|
const struct json *params,
|
|
|
|
|
bool new_has_lock)
|
2011-07-26 16:49:03 -07:00
|
|
|
|
{
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (db->lock_name
|
2011-07-26 16:49:03 -07:00
|
|
|
|
&& params->type == JSON_ARRAY
|
|
|
|
|
&& json_array(params)->n > 0
|
|
|
|
|
&& json_array(params)->elems[0]->type == JSON_STRING) {
|
|
|
|
|
const char *lock_name = json_string(json_array(params)->elems[0]);
|
|
|
|
|
|
2017-12-15 10:59:36 -08:00
|
|
|
|
if (!strcmp(db->lock_name, lock_name)) {
|
|
|
|
|
ovsdb_idl_db_update_has_lock(db, new_has_lock);
|
2011-07-26 16:49:03 -07:00
|
|
|
|
if (!new_has_lock) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
db->is_lock_contended = true;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return true;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
|
|
|
|
}
|
2017-12-15 10:59:36 -08:00
|
|
|
|
return false;
|
2011-07-26 16:49:03 -07:00
|
|
|
|
}
|
2015-08-04 09:52:26 -07:00
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
/* Inserts a new Map Operation into current transaction. */
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_add_map_op(struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum,
|
|
|
|
|
enum map_op_type op_type)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
struct map_op *map_op;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
/* Check if a map operation list exists for this column. */
|
|
|
|
|
if (!row->map_op_written) {
|
|
|
|
|
row->map_op_written = bitmap_allocate(class->n_columns);
|
|
|
|
|
row->map_op_lists = xzalloc(class->n_columns *
|
|
|
|
|
sizeof *row->map_op_lists);
|
|
|
|
|
}
|
|
|
|
|
if (!row->map_op_lists[column_idx]) {
|
|
|
|
|
row->map_op_lists[column_idx] = map_op_list_create();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add a map operation to the corresponding list. */
|
|
|
|
|
map_op = map_op_create(datum, op_type);
|
|
|
|
|
bitmap_set1(row->map_op_written, column_idx);
|
|
|
|
|
map_op_list_add(row->map_op_lists[column_idx], map_op, &column->type);
|
|
|
|
|
|
|
|
|
|
/* Add this row to transaction's list of rows. */
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_insert(&row->table->db->txn->txn_rows, &row->txn_node,
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Inserts a new Set Operation into current transaction. */
|
|
|
|
|
static void
|
|
|
|
|
ovsdb_idl_txn_add_set_op(struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum,
|
|
|
|
|
enum set_op_type op_type)
|
|
|
|
|
{
|
|
|
|
|
const struct ovsdb_idl_table_class *class;
|
|
|
|
|
size_t column_idx;
|
|
|
|
|
struct set_op *set_op;
|
|
|
|
|
|
2017-08-11 11:06:44 -07:00
|
|
|
|
class = row->table->class_;
|
2016-08-06 17:46:29 -05:00
|
|
|
|
column_idx = column - class->columns;
|
|
|
|
|
|
|
|
|
|
/* Check if a set operation list exists for this column. */
|
|
|
|
|
if (!row->set_op_written) {
|
|
|
|
|
row->set_op_written = bitmap_allocate(class->n_columns);
|
|
|
|
|
row->set_op_lists = xzalloc(class->n_columns *
|
|
|
|
|
sizeof *row->set_op_lists);
|
|
|
|
|
}
|
|
|
|
|
if (!row->set_op_lists[column_idx]) {
|
|
|
|
|
row->set_op_lists[column_idx] = set_op_list_create();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add a set operation to the corresponding list. */
|
|
|
|
|
set_op = set_op_create(datum, op_type);
|
|
|
|
|
bitmap_set1(row->set_op_written, column_idx);
|
|
|
|
|
set_op_list_add(row->set_op_lists[column_idx], set_op, &column->type);
|
|
|
|
|
|
|
|
|
|
/* Add this row to the transactions's list of rows. */
|
|
|
|
|
if (hmap_node_is_null(&row->txn_node)) {
|
2017-12-15 10:59:36 -08:00
|
|
|
|
hmap_insert(&row->table->db->txn->txn_rows, &row->txn_node,
|
2016-08-06 17:46:29 -05:00
|
|
|
|
uuid_hash(&row->uuid));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
static bool
|
|
|
|
|
is_valid_partial_update(const struct ovsdb_idl_row *row,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
/* Verify that this column is being monitored. */
|
2017-08-11 11:06:44 -07:00
|
|
|
|
unsigned int column_idx = column - row->table->class_->columns;
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
if (!(row->table->modes[column_idx] & OVSDB_IDL_MONITOR)) {
|
|
|
|
|
VLOG_WARN("cannot partially update non-monitored column");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Verify that the update affects a single element. */
|
|
|
|
|
if (datum->n != 1) {
|
|
|
|
|
VLOG_WARN("invalid datum for partial update");
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-06 17:46:29 -05:00
|
|
|
|
/* Inserts the value described in 'datum' into the map in 'column' in
|
|
|
|
|
* 'row_'. If the value doesn't already exist in 'column' then it's value
|
|
|
|
|
* is added. The value in 'datum' must be of the same type as the values
|
|
|
|
|
* in 'column'. This function takes ownership of 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write_partial_set(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
enum set_op_type op_type;
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
ovsdb_datum_destroy(datum, &column->type);
|
|
|
|
|
free(datum);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
op_type = SET_OP_INSERT;
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_add_set_op(row, column, datum, op_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Deletes the value specified in 'datum' from the set in 'column' in 'row_'.
|
|
|
|
|
* The value in 'datum' must be of the same type as the keys in 'column'.
|
|
|
|
|
* This function takes ownership of 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_delete_partial_set(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
struct ovsdb_type type_ = column->type;
|
|
|
|
|
type_.value.type = OVSDB_TYPE_VOID;
|
|
|
|
|
ovsdb_datum_destroy(datum, &type_);
|
|
|
|
|
free(datum);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_txn_add_set_op(row, column, datum, SET_OP_DELETE);
|
|
|
|
|
}
|
|
|
|
|
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
/* Inserts the key-value specified in 'datum' into the map in 'column' in
|
|
|
|
|
* 'row_'. If the key already exist in 'column', then it's value is updated
|
|
|
|
|
* with the value in 'datum'. The key-value in 'datum' must be of the same type
|
|
|
|
|
* as the keys-values in 'column'. This function takes ownership of 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_write_partial_map(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
enum ovsdb_atomic_type key_type;
|
|
|
|
|
enum map_op_type op_type;
|
|
|
|
|
unsigned int pos;
|
|
|
|
|
const struct ovsdb_datum *old_datum;
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
ovsdb_datum_destroy(datum, &column->type);
|
2016-06-13 16:06:48 +00:00
|
|
|
|
free(datum);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Find out if this is an insert or an update. */
|
|
|
|
|
key_type = column->type.key.type;
|
|
|
|
|
old_datum = ovsdb_idl_read(row, column);
|
|
|
|
|
pos = ovsdb_datum_find_key(old_datum, &datum->keys[0], key_type);
|
|
|
|
|
op_type = pos == UINT_MAX ? MAP_OP_INSERT : MAP_OP_UPDATE;
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_txn_add_map_op(row, column, datum, op_type);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Deletes the key specified in 'datum' from the map in 'column' in 'row_'.
|
|
|
|
|
* The key in 'datum' must be of the same type as the keys in 'column'.
|
|
|
|
|
* The value in 'datum' must be NULL. This function takes ownership of
|
|
|
|
|
* 'datum'.
|
|
|
|
|
*
|
|
|
|
|
* Usually this function is used indirectly through one of the "update"
|
|
|
|
|
* functions generated by vswitch-idl. */
|
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_txn_delete_partial_map(const struct ovsdb_idl_row *row_,
|
|
|
|
|
const struct ovsdb_idl_column *column,
|
|
|
|
|
struct ovsdb_datum *datum)
|
|
|
|
|
{
|
|
|
|
|
struct ovsdb_idl_row *row = CONST_CAST(struct ovsdb_idl_row *, row_);
|
|
|
|
|
|
|
|
|
|
if (!is_valid_partial_update(row, column, datum)) {
|
|
|
|
|
struct ovsdb_type type_ = column->type;
|
|
|
|
|
type_.value.type = OVSDB_TYPE_VOID;
|
|
|
|
|
ovsdb_datum_destroy(datum, &type_);
|
2016-06-13 16:06:48 +00:00
|
|
|
|
free(datum);
|
ovsdb-idl: Add partial map updates functionality.
In the current implementation, every time an element of either a map or set
column has to be modified, the entire content of the column is sent to the
server to be updated. This is not a major problem if the information contained
in the column for the corresponding row is small, but there are cases where
these columns can have a significant amount of elements per row, or these
values are updated frequently, therefore the cost of the modifications becomes
high in terms of time and bandwidth.
In this solution, the ovsdb-idl code is modified to use the RFC 7047 'mutate'
operation, to allow sending partial modifications on map columns to the server.
The functionality is exposed to clients in the vswitch idl. This was
implemented through map operations.
A map operation is defined as an insertion, update or deletion of a key-value
pair inside a map. The idea is to minimize the amount of map operations
that are send to the OVSDB server when a transaction is committed.
In order to keep track of the requested map operations, structs map_op and
map_op_list were defined with accompanying functions to manipulate them. These
functions make sure that only one operation is send to the server for each
key-value that wants to be modified, so multiple operation on a key value are
collapsed into a single operation.
As an example, if a client using the IDL updates several times the value for
the same key, the functions will ensure that only the last value is send to
the server, instead of multiple updates. Or, if the client inserts a key-value,
and later on deletes the key before committing the transaction, then both
actions cancel out and no map operation is send for that key.
To keep track of the desired map operations on each transaction, a list of map
operations (struct map_op_list) is created for every column on the row on which
a map operation is performed. When a new map operation is requested on the same
column, the corresponding map_op_list is checked to verify if a previous
operations was performed on the same key, on the same transaction. If there is
no previous operation, then the new operation is just added into the list. But
if there was a previous operation on the same key, then the previous operation
is collapsed with the new operation into a single operation that preserves the
final result if both operations were to be performed sequentially. This design
keep a small memory footprint during transactions.
When a transaction is committed, the map operations lists are checked and
all map operations that belong to the same map are grouped together into a
single JSON RPC "mutate" operation, in which each map_op is transformed into
the necessary "insert" or "delete" mutators. Then the "mutate" operation is
added to the operations that will be send to the server.
Once the transaction is finished, all map operation lists are cleared and
deleted, so the next transaction starts with a clean board for map operations.
Using different structures and logic to handle map operations, instead of
trying to force the current structures (like 'old' and 'new' datums in the row)
to handle then, ensures that map operations won't mess up with the current
logic to generate JSON messages for other operations, avoids duplicating the
whole map for just a few changes, and is faster for insert and delete
operations, because there is no need to maintain the invariants in the 'new'
datum.
Signed-off-by: Edward Aymerich <edward.aymerich@hpe.com>
Signed-off-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
Co-authored-by: Arnoldo Lutz <arnoldo.lutz.guevara@hpe.com>
[blp@ovn.org made style changes and factored out error checking]
Signed-off-by: Ben Pfaff <blp@ovn.org>
2016-05-02 13:59:44 -06:00
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_txn_add_map_op(row, column, datum, MAP_OP_DELETE);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-04 09:52:26 -07:00
|
|
|
|
void
|
|
|
|
|
ovsdb_idl_loop_destroy(struct ovsdb_idl_loop *loop)
|
|
|
|
|
{
|
|
|
|
|
if (loop) {
|
|
|
|
|
ovsdb_idl_destroy(loop->idl);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_txn *
|
|
|
|
|
ovsdb_idl_loop_run(struct ovsdb_idl_loop *loop)
|
|
|
|
|
{
|
|
|
|
|
ovsdb_idl_run(loop->idl);
|
|
|
|
|
loop->open_txn = (loop->committing_txn
|
|
|
|
|
|| ovsdb_idl_get_seqno(loop->idl) == loop->skip_seqno
|
|
|
|
|
? NULL
|
|
|
|
|
: ovsdb_idl_txn_create(loop->idl));
|
|
|
|
|
return loop->open_txn;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-21 22:16:19 -07:00
|
|
|
|
/* Attempts to commit the current transaction, if one is open, and sets up the
|
|
|
|
|
* poll loop to wake up when some more work might be needed.
|
|
|
|
|
*
|
|
|
|
|
* If a transaction was open, in this or a previous iteration of the main loop,
|
|
|
|
|
* and had not before finished committing (successfully or unsuccessfully), the
|
|
|
|
|
* return value is one of:
|
|
|
|
|
*
|
|
|
|
|
* 1: The transaction committed successfully (or it did not change anything in
|
|
|
|
|
* the database).
|
|
|
|
|
* 0: The transaction failed.
|
|
|
|
|
* -1: The commit is still in progress.
|
|
|
|
|
*
|
|
|
|
|
* Thus, the return value is -1 if the transaction is in progress and otherwise
|
|
|
|
|
* true for success, false for failure.
|
|
|
|
|
*
|
|
|
|
|
* (In the corner case where the IDL sends a transaction to the database and
|
|
|
|
|
* the database commits it, and the connection between the IDL and the database
|
|
|
|
|
* drops before the IDL receives the message confirming the commit, this
|
|
|
|
|
* function can return 0 even though the transaction succeeded.)
|
|
|
|
|
*/
|
|
|
|
|
int
|
2015-08-04 09:52:26 -07:00
|
|
|
|
ovsdb_idl_loop_commit_and_wait(struct ovsdb_idl_loop *loop)
|
|
|
|
|
{
|
|
|
|
|
if (loop->open_txn) {
|
|
|
|
|
loop->committing_txn = loop->open_txn;
|
|
|
|
|
loop->open_txn = NULL;
|
|
|
|
|
|
|
|
|
|
loop->precommit_seqno = ovsdb_idl_get_seqno(loop->idl);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct ovsdb_idl_txn *txn = loop->committing_txn;
|
2016-09-21 22:16:19 -07:00
|
|
|
|
int retval;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
if (txn) {
|
|
|
|
|
enum ovsdb_idl_txn_status status = ovsdb_idl_txn_commit(txn);
|
|
|
|
|
if (status != TXN_INCOMPLETE) {
|
|
|
|
|
switch (status) {
|
|
|
|
|
case TXN_TRY_AGAIN:
|
|
|
|
|
/* We want to re-evaluate the database when it's changed from
|
|
|
|
|
* the contents that it had when we started the commit. (That
|
|
|
|
|
* might have already happened.) */
|
|
|
|
|
loop->skip_seqno = loop->precommit_seqno;
|
|
|
|
|
if (ovsdb_idl_get_seqno(loop->idl) != loop->skip_seqno) {
|
|
|
|
|
poll_immediate_wake();
|
|
|
|
|
}
|
2016-09-21 22:16:19 -07:00
|
|
|
|
retval = 0;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_SUCCESS:
|
2016-07-26 23:55:25 -07:00
|
|
|
|
/* Possibly some work on the database was deferred because no
|
|
|
|
|
* further transaction could proceed. Wake up again. */
|
2016-09-21 22:16:19 -07:00
|
|
|
|
retval = 1;
|
2016-07-24 13:14:59 -07:00
|
|
|
|
loop->cur_cfg = loop->next_cfg;
|
2016-07-26 23:55:25 -07:00
|
|
|
|
poll_immediate_wake();
|
2015-08-04 09:52:26 -07:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_UNCHANGED:
|
2016-09-21 22:16:19 -07:00
|
|
|
|
retval = 1;
|
2016-07-24 13:14:59 -07:00
|
|
|
|
loop->cur_cfg = loop->next_cfg;
|
|
|
|
|
break;
|
|
|
|
|
|
2015-08-04 09:52:26 -07:00
|
|
|
|
case TXN_ABORTED:
|
|
|
|
|
case TXN_NOT_LOCKED:
|
|
|
|
|
case TXN_ERROR:
|
2016-09-21 22:16:19 -07:00
|
|
|
|
retval = 0;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case TXN_UNCOMMITTED:
|
|
|
|
|
case TXN_INCOMPLETE:
|
2016-09-21 22:16:19 -07:00
|
|
|
|
default:
|
2015-08-04 09:52:26 -07:00
|
|
|
|
OVS_NOT_REACHED();
|
|
|
|
|
}
|
|
|
|
|
ovsdb_idl_txn_destroy(txn);
|
|
|
|
|
loop->committing_txn = NULL;
|
2016-09-21 22:16:19 -07:00
|
|
|
|
} else {
|
|
|
|
|
retval = -1;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
}
|
2016-09-21 22:16:19 -07:00
|
|
|
|
} else {
|
|
|
|
|
/* Not a meaningful return value: no transaction was in progress. */
|
|
|
|
|
retval = 1;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ovsdb_idl_wait(loop->idl);
|
2016-09-21 22:16:19 -07:00
|
|
|
|
|
|
|
|
|
return retval;
|
2015-08-04 09:52:26 -07:00
|
|
|
|
}
|