2
0
mirror of https://github.com/openvswitch/ovs synced 2025-08-31 14:25:26 +00:00

ovn: Rename "ovn" database to "ovn-sb".

It was confusing having a database called "ovn", since it's also the
name of the project.  Since we have an "ovn-nb", rename "ovn" to
"ovn-sb".

Signed-off-by: Justin Pettit <jpettit@nicira.com>
This commit is contained in:
Justin Pettit
2015-04-07 17:40:48 -07:00
parent 65fb682673
commit ec78987fef
10 changed files with 176 additions and 165 deletions

12
ovn/.gitignore vendored
View File

@@ -1,17 +1,17 @@
/ovn.5
/ovn.gv
/ovn.pic
/ovn-architecture.7
/ovn-controller.8
/ovn-idl.c
/ovn-idl.h
/ovn-idl.ovsidl
/ovn-nb.5
/ovn-nb.gv
/ovn-nb.pic
/ovn-nb-idl.c
/ovn-nb-idl.h
/ovn-nb-idl.ovsidl
/ovn-sb.5
/ovn-sb.gv
/ovn-sb.pic
/ovn-sb-idl.c
/ovn-sb-idl.h
/ovn-sb-idl.ovsidl
/ovn-nbctl
/ovn-nbctl.8
/ovn-nbd

View File

@@ -159,7 +159,7 @@
We can probably use the same default as ovs-vsctl.
*** Location of OVN database.
*** Location of OVN Southbound database.
Probably no useful default.
@@ -183,16 +183,16 @@
Initially, the simplest way to do this is probably to write
straight C code to do a full translation of the entire
OVN_Northbound database into the format for the Pipeline table in
the OVN database. As scale increases, this will probably be too
inefficient since a small change in OVN_Northbound requires a full
recomputation. At that point, we probably want to adopt a more
systematic approach, such as something akin to the "nlog" system
used in NVP (see Koponen et al. "Network Virtualization in
Multi-tenant Datacenters", NSDI 2014).
the OVN Southbound database. As scale increases, this will probably
be too inefficient since a small change in OVN_Northbound requires a
full recomputation. At that point, we probably want to adopt a more
systematic approach, such as something akin to the "nlog" system used
in NVP (see Koponen et al. "Network Virtualization in Multi-tenant
Datacenters", NSDI 2014).
** Push logical datapath flows to Pipeline table.
** Monitor OVN database Bindings table.
** Monitor OVN Southbound database Bindings table.
Sync rows in the OVN Bindings table to the "up" column in the
OVN_Northbound database.
@@ -208,9 +208,9 @@
** Scaling number of connections.
In typical use today a given ovsdb-server has only a single-digit
number of simultaneous connections. The OVN database will have a
connection from every hypervisor. This use case needs testing and
probably coding work. Here are some possible improvements.
number of simultaneous connections. The OVN Southbound database will
have a connection from every hypervisor. This use case needs testing
and probably coding work. Here are some possible improvements.
*** Reducing amount of data sent to clients.

View File

@@ -1,35 +1,35 @@
# OVN schema and IDL
EXTRA_DIST += ovn/ovn.ovsschema
pkgdata_DATA += ovn/ovn.ovsschema
# OVN southbound schema and IDL
EXTRA_DIST += ovn/ovn-sb.ovsschema
pkgdata_DATA += ovn/ovn-sb.ovsschema
# OVN E-R diagram
# OVN southbound E-R diagram
#
# If "python" or "dot" is not available, then we do not add graphical diagram
# to the documentation.
if HAVE_PYTHON
if HAVE_DOT
ovn/ovn.gv: ovsdb/ovsdb-dot.in ovn/ovn.ovsschema
$(AM_V_GEN)$(OVSDB_DOT) --no-arrows $(srcdir)/ovn/ovn.ovsschema > $@
ovn/ovn.pic: ovn/ovn.gv ovsdb/dot2pic
$(AM_V_GEN)(dot -T plain < ovn/ovn.gv | $(PERL) $(srcdir)/ovsdb/dot2pic -f 3) > $@.tmp && \
ovn/ovn-sb.gv: ovsdb/ovsdb-dot.in ovn/ovn-sb.ovsschema
$(AM_V_GEN)$(OVSDB_DOT) --no-arrows $(srcdir)/ovn/ovn-sb.ovsschema > $@
ovn/ovn-sb.pic: ovn/ovn-sb.gv ovsdb/dot2pic
$(AM_V_GEN)(dot -T plain < ovn/ovn-sb.gv | $(PERL) $(srcdir)/ovsdb/dot2pic -f 3) > $@.tmp && \
mv $@.tmp $@
OVN_PIC = ovn/ovn.pic
OVN_DOT_DIAGRAM_ARG = --er-diagram=$(OVN_PIC)
DISTCLEANFILES += ovn/ovn.gv ovn/ovn.pic
OVN_SB_PIC = ovn/ovn-sb.pic
OVN_SB_DOT_DIAGRAM_ARG = --er-diagram=$(OVN_SB_PIC)
DISTCLEANFILES += ovn/ovn-sb.gv ovn/ovn-sb.pic
endif
endif
# OVN schema documentation
EXTRA_DIST += ovn/ovn.xml
DISTCLEANFILES += ovn/ovn.5
man_MANS += ovn/ovn.5
ovn/ovn.5: \
ovsdb/ovsdb-doc ovn/ovn.xml ovn/ovn.ovsschema $(OVN_PIC)
# OVN southbound schema documentation
EXTRA_DIST += ovn/ovn-sb.xml
DISTCLEANFILES += ovn/ovn-sb.5
man_MANS += ovn/ovn-sb.5
ovn/ovn-sb.5: \
ovsdb/ovsdb-doc ovn/ovn-sb.xml ovn/ovn-sb.ovsschema $(OVN_SB_PIC)
$(AM_V_GEN)$(OVSDB_DOC) \
$(OVN_DOT_DIAGRAM_ARG) \
$(OVN_SB_DOT_DIAGRAM_ARG) \
--version=$(VERSION) \
$(srcdir)/ovn/ovn.ovsschema \
$(srcdir)/ovn/ovn.xml > $@.tmp && \
$(srcdir)/ovn/ovn-sb.ovsschema \
$(srcdir)/ovn/ovn-sb.xml > $@.tmp && \
mv $@.tmp $@
# OVN northbound schema and IDL
@@ -78,19 +78,19 @@ EXTRA_DIST += \
ovn/TODO \
ovn/CONTAINERS.OpenStack.md
# ovn IDL
# ovn-sb IDL
OVSIDL_BUILT += \
$(srcdir)/ovn/ovn-idl.c \
$(srcdir)/ovn/ovn-idl.h \
$(srcdir)/ovn/ovn.ovsidl
EXTRA_DIST += $(srcdir)/ovn/ovn-idl.ann
OVN_IDL_FILES = \
$(srcdir)/ovn/ovn.ovsschema \
$(srcdir)/ovn/ovn-idl.ann
$(srcdir)/ovn/ovn-idl.ovsidl: $(OVN_IDL_FILES)
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(OVN_IDL_FILES) > $@.tmp && \
$(srcdir)/ovn/ovn-sb-idl.c \
$(srcdir)/ovn/ovn-sb-idl.h \
$(srcdir)/ovn/ovn-sb.ovsidl
EXTRA_DIST += $(srcdir)/ovn/ovn-sb-idl.ann
OVN_SB_IDL_FILES = \
$(srcdir)/ovn/ovn-sb.ovsschema \
$(srcdir)/ovn/ovn-sb-idl.ann
$(srcdir)/ovn/ovn-sb-idl.ovsidl: $(OVN_SB_IDL_FILES)
$(AM_V_GEN)$(OVSDB_IDLC) annotate $(OVN_SB_IDL_FILES) > $@.tmp && \
mv $@.tmp $@
CLEANFILES += ovn/ovn-idl.c ovn/ovn-idl.h
CLEANFILES += ovn/ovn-sb-idl.c ovn/ovn-sb-idl.h
# ovn-nb IDL
OVSIDL_BUILT += \
@@ -113,8 +113,8 @@ ovn_libovn_la_LDFLAGS = \
-Wl,--version-script=$(top_builddir)/ovn/libovn.sym \
$(AM_LDFLAGS)
ovn_libovn_la_SOURCES = \
ovn/ovn-idl.c \
ovn/ovn-idl.h \
ovn/ovn-sb-idl.c \
ovn/ovn-sb-idl.h \
ovn/ovn-nb-idl.c \
ovn/ovn-nb-idl.h

View File

@@ -109,21 +109,21 @@
<li>
<code>ovn-nbd</code>(8) connects to the OVN Northbound Database above it
and the OVN Database below it. It translates the logical network
configuration in terms of conventional network concepts, taken from the
OVN Northbound Database, into logical datapath flows in the OVN Database
below it.
and the OVN Southbound Database below it. It translates the
logical network configuration in terms of conventional network
concepts, taken from the OVN Northbound Database, into logical
datapath flows in the OVN Southbound Database below it.
</li>
<li>
<p>
The <dfn>OVN Database</dfn> is the center of the system. Its clients
are <code>ovn-nbd</code>(8) above it and <code>ovn-controller</code>(8)
on every transport node below it.
The <dfn>OVN Southbound Database</dfn> is the center of the system.
Its clients are <code>ovn-nbd</code>(8) above it and
<code>ovn-controller</code>(8) on every transport node below it.
</p>
<p>
The OVN Database contains three kinds of data: <dfn>Physical
The OVN Southbound Database contains three kinds of data: <dfn>Physical
Network</dfn> (PN) tables that specify how to reach hypervisor and
other nodes, <dfn>Logical Network</dfn> (LN) tables that describe the
logical network in terms of ``logical datapath flows,'' and
@@ -134,9 +134,10 @@
</p>
<p>
OVN Database performance must scale with the number of transport nodes.
This will likely require some work on <code>ovsdb-server</code>(1) as
we encounter bottlenecks. Clustering for availability may be needed.
OVN Southbound Database performance must scale with the number of
transport nodes. This will likely require some work on
<code>ovsdb-server</code>(1) as we encounter bottlenecks.
Clustering for availability may be needed.
</p>
</li>
</ul>
@@ -148,13 +149,14 @@
<ul>
<li>
<code>ovn-controller</code>(8) is OVN's agent on each hypervisor and
software gateway. Northbound, it connects to the OVN Database to learn
about OVN configuration and status and to populate the PN table and the
<code>Chassis</code> column in <code>Bindings</code> table with the
hypervisor's status. Southbound, it connects to
<code>ovs-vswitchd</code>(8) as an OpenFlow controller, for control over
network traffic, and to the local <code>ovsdb-server</code>(1) to allow
it to monitor and control Open vSwitch configuration.
software gateway. Northbound, it connects to the OVN Southbound
Database to learn about OVN configuration and status and to
populate the PN table and the <code>Chassis</code> column in
<code>Bindings</code> table with the hypervisor's status.
Southbound, it connects to <code>ovs-vswitchd</code>(8) as an
OpenFlow controller, for control over network traffic, and to the
local <code>ovsdb-server</code>(1) to allow it to monitor and
control Open vSwitch configuration.
</li>
<li>
@@ -180,14 +182,14 @@
+-----------|-----------+
|
|
+------+
|OVN DB|
+------+
+-------------------+
| OVN Southbound DB |
+-------------------+
|
|
+------------------+------------------+
| | |
HV 1 | | HV n |
HV 1 | | HV n |
+---------------|---------------+ . +---------------|---------------+
| | | . | | |
| ovn-controller | . | ovn-controller |
@@ -267,7 +269,7 @@
<p>
The steps in this example refer often to details of the OVN and OVN
Northbound database schemas. Please see <code>ovn</code>(5) and
Northbound database schemas. Please see <code>ovn-sb</code>(5) and
<code>ovn-nb</code>(5), respectively, for the full story on these
databases.
</p>
@@ -290,14 +292,15 @@
</li>
<li>
<code>ovn-nbd</code> receives the OVN Northbound database update. In
turn, it makes the corresponding updates to the OVN database, by adding
rows to the OVN database <code>Pipeline</code> table to reflect the new
port, e.g. add a flow to recognize that packets destined to the new
port's MAC address should be delivered to it, and update the flow that
delivers broadcast and multicast packets to include the new port. It
also creates a record in the <code>Bindings</code> table and populates
all its columns except the column that identifies the
<code>ovn-nbd</code> receives the OVN Northbound database update.
In turn, it makes the corresponding updates to the OVN Southbound
database, by adding rows to the OVN Southbound database
<code>Pipeline</code> table to reflect the new port, e.g. add a
flow to recognize that packets destined to the new port's MAC
address should be delivered to it, and update the flow that
delivers broadcast and multicast packets to include the new port.
It also creates a record in the <code>Bindings</code> table and
populates all its columns except the column that identifies the
<code>chassis</code>.
</li>
@@ -386,9 +389,10 @@
<li>
<code>ovn-nbd</code> receives the OVN Northbound update and in turn
updates the OVN database accordingly, by removing or updating the
rows from the OVN database <code>Pipeline</code> table and
<code>Bindings</code> table that were related to the now-destroyed VIF.
updates the OVN Southbound database accordingly, by removing or
updating the rows from the OVN Southbound database
<code>Pipeline</code> table and <code>Bindings</code> table that
were related to the now-destroyed VIF.
</li>
<li>
@@ -482,10 +486,11 @@
<li>
<code>ovn-nbd</code> receives the OVN Northbound database update. In
turn, it makes the corresponding updates to the OVN database, by adding
rows to the OVN database's <code>Pipeline</code> table to reflect the new
port and also by creating a new row in the <code>Bindings</code> table
and populating all its columns except the column that identifies the
turn, it makes the corresponding updates to the OVN Southbound
database, by adding rows to the OVN Southbound database's
<code>Pipeline</code> table to reflect the new port and also by
creating a new row in the <code>Bindings</code> table and
populating all its columns except the column that identifies the
<code>chassis</code>.
</li>
@@ -521,10 +526,11 @@
<li>
<code>ovn-nbd</code> receives the OVN Northbound update and in turn
updates the OVN database accordingly, by removing or updating the
rows from the OVN database <code>Pipeline</code> table that were related
to the now-destroyed CIF. It also deletes the row in the
<code>Bindings</code> table for that CIF.
updates the OVN Southbound database accordingly, by removing or
updating the rows from the OVN Southbound database
<code>Pipeline</code> table that were related to the now-destroyed
CIF. It also deletes the row in the <code>Bindings</code> table
for that CIF.
</li>
<li>

View File

@@ -15,8 +15,8 @@ ovn\-controller \- OVN local controller
.
.SH DESCRIPTION
\fBovn\-controller\fR is the local controller daemon for OVN, the Open
Virtual Network. It connects northbound to the OVN database (see
\fBovn\fR(5)) over the OVSDB protocol, and southbound to the Open
Virtual Network. It connects up to the OVN Southbound database (see
\fBovn\-sb\fR(5)) over the OVSDB protocol, and down to the Open
vSwitch database (see \fBovs-vswitchd.conf.db\fR(5)) over the OVSDB
protocol and to \fBovs\-vswitchd\fR(8) via OpenFlow. Each hypervisor
and software gateway in an OVN deployment runs its own independent

View File

@@ -5,7 +5,7 @@
(CMS), such as OpenStack, running above it. The CMS produces almost all of
the contents of the database. The <code>ovn-nbd</code> program monitors
the database contents, transforms it, and stores it into the <ref
db="OVN"/> database.
db="OVN_Southbound"/> database.
</p>
<p>
@@ -117,13 +117,13 @@
<column name="up">
This column is populated by <code>ovn-nbd</code>, rather than by the CMS
plugin as is most of this database. When a logical port is bound to a
physical location in the OVN database <ref db="OVN" table="Bindings"/>
table, <code>ovn-nbd</code> sets this column to <code>true</code>;
otherwise, or if the port becomes unbound later, it sets it to
<code>false</code>. This allows the CMS to wait for a VM's
(or container's) networking to become active before it allows the
VM (or container) to start.
plugin as is most of this database. When a logical port is bound
to a physical location in the OVN Southbound database <ref
db="OVN_Southbound" table="Bindings"/> table, <code>ovn-nbd</code>
sets this column to <code>true</code>; otherwise, or if the port
becomes unbound later, it sets it to <code>false</code>. This
allows the CMS to wait for a VM's (or container's) networking to
become active before it allows the VM (or container) to start.
</column>
<column name="macs">
@@ -144,11 +144,12 @@
</p>
<p>
Exact syntax is TBD. One could simply use comma- or space-separated L2
and L3 addresses in each set member, or replace this by a subset of the
general-purpose expression language used for the <ref column="match"
table="Pipeline" db="OVN"/> column in the OVN database's <ref
table="Pipeline" db="OVN"/> table.
Exact syntax is TBD. One could simply use comma- or
space-separated L2 and L3 addresses in each set member, or
replace this by a subset of the general-purpose expression
language used for the <ref column="match" table="Pipeline"
db="OVN_Southbound"/> column in the OVN Southbound database's
<ref table="Pipeline" db="OVN_Southbound"/> table.
</p>
</column>
@@ -184,13 +185,15 @@
</column>
<column name="match">
The packets that the ACL should match, in the same expression language
used for the <ref column="match" table="Pipeline" db="OVN"/> column in
the OVN database's <ref table="Pipeline" db="OVN"/> table. Match
<code>inport</code> and <code>outport</code> against names of logical
ports within <ref column="lswitch"/> to implement ingress and egress ACLs,
respectively. In logical switches connected to logical routers, the
special port name <code>ROUTER</code> refers to the logical router port.
The packets that the ACL should match, in the same expression
language used for the <ref column="match" table="Pipeline"
db="OVN_Southbound"/> column in the OVN Southbound database's <ref
table="Pipeline" db="OVN_Southbound"/> table. Match
<code>inport</code> and <code>outport</code> against names of
logical ports within <ref column="lswitch"/> to implement ingress
and egress ACLs, respectively. In logical switches connected to
logical routers, the special port name <code>ROUTER</code> refers
to the logical router port.
</column>
<column name="action">

View File

@@ -24,8 +24,8 @@
#include "fatal-signal.h"
#include "hash.h"
#include "hmap.h"
#include "ovn/ovn-idl.h"
#include "ovn/ovn-nb-idl.h"
#include "ovn/ovn-sb-idl.h"
#include "poll-loop.h"
#include "stream.h"
#include "stream-ssl.h"
@@ -37,13 +37,13 @@ VLOG_DEFINE_THIS_MODULE(ovn_nbd);
struct nbd_context {
struct ovsdb_idl *ovnnb_idl;
struct ovsdb_idl *ovn_idl;
struct ovsdb_idl *ovnsb_idl;
struct ovsdb_idl_txn *ovnnb_txn;
struct ovsdb_idl_txn *ovn_txn;
};
static const char *ovnnb_db;
static const char *ovn_db;
static const char *ovnsb_db;
static const char *default_db(void);
@@ -57,7 +57,7 @@ usage: %s [OPTIONS]\n\
Options:\n\
--ovnnb-db=DATABASE connect to ovn-nb database at DATABASE\n\
(default: %s)\n\
--ovn-db=DATABASE connect to ovn database at DATABASE\n\
--ovnsb-db=DATABASE connect to ovn-sb database at DATABASE\n\
(default: %s)\n\
-h, --help display this help message\n\
-o, --options list available options\n\
@@ -116,19 +116,20 @@ macs_equal(char **binding_macs_, size_t b_n_macs,
/*
* When a change has occurred in the OVN_Northbound database, we go through and
* make sure that the contents of the Bindings table in the OVN database are up
* to date with the logical ports defined in the OVN_Northbound database.
* make sure that the contents of the Bindings table in the OVN_Southbound
* database are up to date with the logical ports defined in the
* OVN_Northbound database.
*/
static void
set_bindings(struct nbd_context *ctx)
{
struct hmap bindings_hmap;
const struct ovnrec_bindings *binding;
const struct sbrec_bindings *binding;
const struct nbrec_logical_port *lport;
struct binding_hash_node {
struct hmap_node node;
const struct ovnrec_bindings *binding;
const struct sbrec_bindings *binding;
} *hash_node, *hash_node_next;
/*
@@ -143,7 +144,7 @@ set_bindings(struct nbd_context *ctx)
*/
hmap_init(&bindings_hmap);
OVNREC_BINDINGS_FOR_EACH(binding, ctx->ovn_idl) {
SBREC_BINDINGS_FOR_EACH(binding, ctx->ovnsb_idl) {
struct binding_hash_node *hash_node = xzalloc(sizeof *hash_node);
hash_node->binding = binding;
@@ -171,22 +172,22 @@ set_bindings(struct nbd_context *ctx)
if (!macs_equal(binding->mac, binding->n_mac,
lport->macs, lport->n_macs)) {
ovnrec_bindings_set_mac(binding,
sbrec_bindings_set_mac(binding,
(const char **) lport->macs, lport->n_macs);
}
} else {
/* There is no binding for this logical port, so create one. */
binding = ovnrec_bindings_insert(ctx->ovn_txn);
ovnrec_bindings_set_logical_port(binding, lport->name);
ovnrec_bindings_set_mac(binding,
binding = sbrec_bindings_insert(ctx->ovn_txn);
sbrec_bindings_set_logical_port(binding, lport->name);
sbrec_bindings_set_mac(binding,
(const char **) lport->macs, lport->n_macs);
}
}
HMAP_FOR_EACH_SAFE(hash_node, hash_node_next, node, &bindings_hmap) {
hmap_remove(&bindings_hmap, &hash_node->node);
ovnrec_bindings_delete(hash_node->binding);
sbrec_bindings_delete(hash_node->binding);
free(hash_node);
}
hmap_destroy(&bindings_hmap);
@@ -206,13 +207,13 @@ ovnnb_db_changed(struct nbd_context *ctx)
* set the corresponding logical port as 'up' in the northbound DB.
*/
static void
ovn_db_changed(struct nbd_context *ctx)
ovnsb_db_changed(struct nbd_context *ctx)
{
const struct ovnrec_bindings *bindings;
const struct sbrec_bindings *bindings;
VLOG_DBG("Recalculating port up states for ovn-nb db.");
OVNREC_BINDINGS_FOR_EACH(bindings, ctx->ovn_idl) {
SBREC_BINDINGS_FOR_EACH(bindings, ctx->ovnsb_idl) {
const struct nbrec_logical_port *lport;
struct uuid lport_uuid;
@@ -257,7 +258,7 @@ parse_options(int argc OVS_UNUSED, char *argv[] OVS_UNUSED)
VLOG_OPTION_ENUMS,
};
static const struct option long_options[] = {
{"ovn-db", required_argument, NULL, 'd'},
{"ovnsb-db", required_argument, NULL, 'd'},
{"ovnnb-db", required_argument, NULL, 'D'},
{"help", no_argument, NULL, 'h'},
{"options", no_argument, NULL, 'o'},
@@ -283,7 +284,7 @@ parse_options(int argc OVS_UNUSED, char *argv[] OVS_UNUSED)
STREAM_SSL_OPTION_HANDLERS;
case 'd':
ovn_db = optarg;
ovnsb_db = optarg;
break;
case 'D':
@@ -307,8 +308,8 @@ parse_options(int argc OVS_UNUSED, char *argv[] OVS_UNUSED)
}
}
if (!ovn_db) {
ovn_db = default_db();
if (!ovnsb_db) {
ovnsb_db = default_db();
}
if (!ovnnb_db) {
@@ -322,7 +323,7 @@ int
main(int argc, char *argv[])
{
extern struct vlog_module VLM_reconnect;
struct ovsdb_idl *ovnnb_idl, *ovn_idl;
struct ovsdb_idl *ovnnb_idl, *ovnsb_idl;
unsigned int ovnnb_seqno, ovn_seqno;
int res = EXIT_SUCCESS;
struct nbd_context ctx = {
@@ -340,7 +341,7 @@ main(int argc, char *argv[])
daemonize();
nbrec_init();
ovnrec_init();
sbrec_init();
/* We want to detect all changes to the ovn-nb db. */
ctx.ovnnb_idl = ovnnb_idl = ovsdb_idl_create(ovnnb_db,
@@ -348,12 +349,12 @@ main(int argc, char *argv[])
/* There is only a small subset of changes to the ovn db that ovn-nbd has to
* care about, so we'll enable monitoring those directly. */
ctx.ovn_idl = ovn_idl = ovsdb_idl_create(ovn_db,
&ovnrec_idl_class, false, true);
ovsdb_idl_add_table(ovn_idl, &ovnrec_table_bindings);
ovsdb_idl_add_column(ovn_idl, &ovnrec_bindings_col_logical_port);
ovsdb_idl_add_column(ovn_idl, &ovnrec_bindings_col_chassis);
ovsdb_idl_add_column(ovn_idl, &ovnrec_bindings_col_mac);
ctx.ovnsb_idl = ovnsb_idl = ovsdb_idl_create(ovnsb_db,
&sbrec_idl_class, false, true);
ovsdb_idl_add_table(ovnsb_idl, &sbrec_table_bindings);
ovsdb_idl_add_column(ovnsb_idl, &sbrec_bindings_col_logical_port);
ovsdb_idl_add_column(ovnsb_idl, &sbrec_bindings_col_chassis);
ovsdb_idl_add_column(ovnsb_idl, &sbrec_bindings_col_mac);
/*
* The loop here just runs the IDL in a loop waiting for the seqno to
@@ -368,10 +369,10 @@ main(int argc, char *argv[])
*/
ovnnb_seqno = ovsdb_idl_get_seqno(ovnnb_idl);
ovn_seqno = ovsdb_idl_get_seqno(ovn_idl);
ovn_seqno = ovsdb_idl_get_seqno(ovnsb_idl);
for (;;) {
ovsdb_idl_run(ovnnb_idl);
ovsdb_idl_run(ovn_idl);
ovsdb_idl_run(ovnsb_idl);
if (!ovsdb_idl_is_alive(ovnnb_idl)) {
int retval = ovsdb_idl_get_last_error(ovnnb_idl);
@@ -381,10 +382,10 @@ main(int argc, char *argv[])
break;
}
if (!ovsdb_idl_is_alive(ovn_idl)) {
int retval = ovsdb_idl_get_last_error(ovn_idl);
if (!ovsdb_idl_is_alive(ovnsb_idl)) {
int retval = ovsdb_idl_get_last_error(ovnsb_idl);
VLOG_ERR("%s: database connection failed (%s)",
ovn_db, ovs_retval_to_string(retval));
ovnsb_db, ovs_retval_to_string(retval));
res = EXIT_FAILURE;
break;
}
@@ -394,8 +395,8 @@ main(int argc, char *argv[])
ovnnb_changes_pending = true;
}
if (ovn_seqno != ovsdb_idl_get_seqno(ovn_idl)) {
ovn_seqno = ovsdb_idl_get_seqno(ovn_idl);
if (ovn_seqno != ovsdb_idl_get_seqno(ovnsb_idl)) {
ovn_seqno = ovsdb_idl_get_seqno(ovnsb_idl);
ovn_changes_pending = true;
}
@@ -413,7 +414,7 @@ main(int argc, char *argv[])
* The OVN-nb db contents have changed, so create a transaction for
* updating the OVN DB.
*/
ctx.ovn_txn = ovsdb_idl_txn_create(ctx.ovn_idl);
ctx.ovn_txn = ovsdb_idl_txn_create(ctx.ovnsb_idl);
ovnnb_db_changed(&ctx);
ovnnb_changes_pending = false;
}
@@ -424,7 +425,7 @@ main(int argc, char *argv[])
* updating the northbound DB.
*/
ctx.ovnnb_txn = ovsdb_idl_txn_create(ctx.ovnnb_idl);
ovn_db_changed(&ctx);
ovnsb_db_changed(&ctx);
ovn_changes_pending = false;
}
@@ -471,9 +472,9 @@ main(int argc, char *argv[])
}
if (ovnnb_seqno == ovsdb_idl_get_seqno(ovnnb_idl) &&
ovn_seqno == ovsdb_idl_get_seqno(ovn_idl)) {
ovn_seqno == ovsdb_idl_get_seqno(ovnsb_idl)) {
ovsdb_idl_wait(ovnnb_idl);
ovsdb_idl_wait(ovn_idl);
ovsdb_idl_wait(ovnsb_idl);
if (ctx.ovnnb_txn) {
ovsdb_idl_txn_wait(ctx.ovnnb_txn);
}
@@ -484,7 +485,7 @@ main(int argc, char *argv[])
}
}
ovsdb_idl_destroy(ovn_idl);
ovsdb_idl_destroy(ovnsb_idl);
ovsdb_idl_destroy(ovnnb_idl);
exit(res);

View File

@@ -5,5 +5,5 @@
# the ovsdb-idl engine information about the types involved, so that
# it can generate more programmer-friendly data structures.
s["idlPrefix"] = "ovnrec_"
s["idlHeader"] = "\"ovn/ovn-idl.h\""
s["idlPrefix"] = "sbrec_"
s["idlHeader"] = "\"ovn/ovn-sb-idl.h\""

View File

@@ -1,5 +1,5 @@
{
"name": "OVN",
"name": "OVN_Southbound",
"tables": {
"Chassis": {
"columns": {

View File

@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="utf-8"?>
<database name="ovn" title="OVN Database">
<database name="ovn-sb" title="OVN Southbound Database">
<p>
This database holds logical and physical configuration and state for the
Open Virtual Network (OVN) system to support virtual network abstraction.
@@ -7,17 +7,18 @@
</p>
<p>
The OVN database sits at the center of the OVN architecture. It is the one
component that speaks both southbound directly to all the hypervisors and
gateways, via <code>ovn-controller</code>, and northbound to the Cloud
Management System, via <code>ovn-nbd</code>:
The OVN Southbound database sits at the center of the OVN
architecture. It is the one component that speaks both southbound
directly to all the hypervisors and gateways, via
<code>ovn-controller</code>, and northbound to the Cloud Management
System, via <code>ovn-nbd</code>:
</p>
<h2>Database Structure</h2>
<p>
The OVN database contains three classes of data with different properties,
as described in the sections below.
The OVN Southbound database contains three classes of data with
different properties, as described in the sections below.
</p>
<h3>Physical Network (PN) data</h3>