[ovs-dev] [PATCH] ovsdb: Remove SPECS in favor of referring to RFC 7047.

Ben Pfaff blp at nicira.com
Fri Apr 4 20:52:37 UTC 2014


Thanks, applied to master.

On Fri, Apr 04, 2014 at 11:35:50AM -0700, Justin Pettit wrote:
> Acked-by: Justin Pettit <jpettit at nicira.com>
> 
> 
> 
> On April 4, 2014 at 9:45:53 AM, Ben Pfaff (blp at nicira.com) wrote:
> > Also, add some clarifications relative to RFC 7047 to ovsdb-server(1).
> > 
> > Signed-off-by: Ben Pfaff 
> > ---
> > lib/ovsdb-data.c | 23 +-
> > ovsdb/SPECS | 1320 -----------------------------------------------
> > ovsdb/automake.mk | 1 -
> > ovsdb/jsonrpc-server.c | 10 +-
> > ovsdb/ovsdb-server.1.in | 48 ++
> > python/ovs/db/data.py | 4 +-
> > 6 files changed, 65 insertions(+), 1341 deletions(-)
> > delete mode 100644 ovsdb/SPECS
> > 
> > diff --git a/lib/ovsdb-data.c b/lib/ovsdb-data.c
> > index 3aae9f4..0706dd0 100644
> > --- a/lib/ovsdb-data.c
> > +++ b/lib/ovsdb-data.c
> > @@ -1,4 +1,4 @@
> > -/* Copyright (c) 2009, 2010, 2011, 2012 Nicira, Inc.
> > +/* Copyright (c) 2009, 2010, 2011, 2012, 2014 Nicira, Inc.
> > *
> > * Licensed under the Apache License, Version 2.0 (the "License");
> > * you may not use this file except in compliance with the License.
> > @@ -41,7 +41,7 @@ wrap_json(const char *name, struct json *wrapped)
> > 
> > /* Initializes 'atom' with the default value of the given 'type'.
> > *
> > - * The default value for an atom is as defined in ovsdb/SPECS:
> > + * The default value for an atom is as defined in RFC 7047:
> > *
> > * - "integer" or "real": 0
> > *
> > @@ -409,10 +409,9 @@ ovsdb_atom_from_json__(union ovsdb_atom *atom,
> > * Violations of constraints expressed by 'base' are treated as errors.
> > *
> > * If 'symtab' is nonnull, then named UUIDs in 'symtab' are accepted. Refer to
> > - * ovsdb/SPECS for information about this, and for the syntax that this
> > - * function accepts. If 'base' is a reference and a symbol is parsed, then the
> > - * symbol's 'strong_ref' or 'weak_ref' member is set to true, as
> > - * appropriate. */
> > + * RFC 7047 for information about this, and for the syntax that this function
> > + * accepts. If 'base' is a reference and a symbol is parsed, then the symbol's
> > + * 'strong_ref' or 'weak_ref' member is set to true, as appropriate. */
> > struct ovsdb_error *
> > ovsdb_atom_from_json(union ovsdb_atom *atom,
> > const struct ovsdb_base_type *base,
> > @@ -436,8 +435,7 @@ ovsdb_atom_from_json(union ovsdb_atom *atom,
> > /* Converts 'atom', of the specified 'type', to JSON format, and returns the
> > * JSON. The caller is responsible for freeing the returned JSON.
> > *
> > - * Refer to ovsdb/SPECS for the format of the JSON that this function
> > - * produces. */
> > + * Refer to RFC 7047 for the format of the JSON that this function produces. */
> > struct json *
> > ovsdb_atom_to_json(const union ovsdb_atom *atom, enum ovsdb_atomic_type type) 
> > {
> > @@ -843,7 +841,7 @@ ovsdb_datum_init_empty(struct ovsdb_datum *datum)
> > 
> > /* Initializes 'datum' as a datum that has the default value for 'type'.
> > *
> > - * The default value for a particular type is as defined in ovsdb/SPECS:
> > + * The default value for a particular type is as defined in RFC 7047:
> > *
> > * - If n_min is 0, then the default value is the empty set (or map).
> > *
> > @@ -1248,8 +1246,8 @@ ovsdb_datum_from_json__(struct ovsdb_datum *datum,
> > * Violations of constraints expressed by 'type' are treated as errors.
> > *
> > * If 'symtab' is nonnull, then named UUIDs in 'symtab' are accepted. Refer to
> > - * ovsdb/SPECS for information about this, and for the syntax that this
> > - * function accepts. */
> > + * RFC 7047 for information about this, and for the syntax that this function
> > + * accepts. */
> > struct ovsdb_error *
> > ovsdb_datum_from_json(struct ovsdb_datum *datum,
> > const struct ovsdb_type *type,
> > @@ -1275,8 +1273,7 @@ ovsdb_datum_from_json(struct ovsdb_datum *datum,
> > *
> > * 'type' constraints on datum->n are ignored.
> > *
> > - * Refer to ovsdb/SPECS for the format of the JSON that this function
> > - * produces. */
> > + * Refer to RFC 7047 for the format of the JSON that this function produces. */
> > struct json *
> > ovsdb_datum_to_json(const struct ovsdb_datum *datum,
> > const struct ovsdb_type *type)
> > diff --git a/ovsdb/SPECS b/ovsdb/SPECS
> > deleted file mode 100644
> > index 5656b9d..0000000
> > --- a/ovsdb/SPECS
> > +++ /dev/null
> > @@ -1,1320 +0,0 @@
> > - ===================================================
> > - Open vSwitch Configuration Database Specification
> > - ===================================================
> > -
> > -Basic Notation
> > ---------------
> > -
> > -OVSDB uses JSON, as defined by RFC 4627, for its schema format and its
> > -wire protocol format. The JSON implementation in Open vSwitch has the
> > -following limitations:
> > -
> > - - Null bytes (\u0000) are not allowed in strings.
> > -
> > - - Only UTF-8 encoding is supported. (RFC 4627 also mentions
> > - UTF-16BE, UTF-16LE, and UTF-32.)
> > -
> > - - RFC 4627 says that names within a JSON object should be unique.
> > - The Open vSwitch JSON parser discards all but the last value
> > - for a name that is specified more than once.
> > -
> > -The descriptions below use the following shorthand notations for JSON
> > -values. Additional notation is presented later.
> > -
> > -
> > -
> > - A JSON string. Any Unicode string is allowed, as specified by RFC
> > - 4627. Implementations may disallow null bytes.
> > -
> > -
> > -
> > - A JSON string matching [a-zA-Z_][a-zA-Z0-9_]*.
> > -
> > - s that begin with _ are reserved to the implementation and may
> > - not be used by the user.
> > -
> > -
> > -
> > - A JSON string that contains a version number that matches
> > - [0-9]+\.[0-9]+\.[0-9]+
> > -
> > -
> > -
> > - A JSON true or false value.
> > -
> > -
> > -
> > - A JSON number.
> > -
> > -
> > -
> > - A JSON number with an integer value, within a certain range
> > - (currently -2**63...+2**63-1).
> > -
> > -
> > -
> > - Any JSON value.
> > -
> > -
> > -
> > - Any JSON value except null.
> > -
> > -
> > -
> > - A JSON object with the following members:
> > -
> > - "error": required
> > - "details": optional
> > -
> > - The value of the "error" member is a short string, specified in
> > - this document, that broadly indicates the class of the error.
> > - Most "error" strings are specific to contexts described elsewhere
> > - in this document, but the following "error" strings may appear in
> > - any context where an is permitted:
> > -
> > - "error": "resources exhausted"
> > -
> > - The operation requires more resources (memory, disk, CPU,
> > - etc.) than are currently available to the database server.
> > -
> > - "error": "I/O error"
> > -
> > - Problems accessing the disk, network, or other required
> > - resources prevented the operation from completing.
> > -
> > - Database implementations may use "error" strings not specified
> > - in this document to indicate errors that do not fit into any of
> > - the specified categories.
> > -
> > - Optionally, an may include a "details" member, whose value
> > - is a string that describes the error in more detail for the
> > - benefit of a human user or administrator. This document does not
> > - specify the format or content of the "details" string.
> > -
> > - An may also have other members that describe the error in
> > - more detail. This document does not specify the names or values
> > - of these members.
> > -
> > -Schema Format
> > --------------
> > -
> > -An Open vSwitch configuration database consists of a set of tables,
> > -each of which has a number of columns and zero or more rows. A schema
> > -is represented by , as described below.
> > -
> > -
> > -
> > - A JSON object with the following members:
> > -
> > - "name": required
> > - "version": required
> > - "cksum": optional
> > - "tables": {: , ...} required
> > -
> > - The "name" identifies the database as a whole. It must be
> > - provided to most JSON-RPC requests to identify the database being
> > - operated on. The value of "tables" is a JSON object whose names
> > - are table names and whose values are s.
> > -
> > - The "version" reports the version of the database schema. Because
> > - this is a recent addition to the schema format, OVSDB permits it
> > - to be omitted, but future versions of OVSDB will require it to be
> > - present. Open vSwitch semantics for "version" are described in
> > - ovs-vswitchd.conf.db(5).
> > -
> > - The "cksum" optionally reports an implementation-defined checksum
> > - for the database schema.
> > -
> > -
> > -
> > - A JSON object with the following members:
> > -
> > - "columns": {: , ...} required
> > - "maxRows": optional
> > - "isRoot": optional
> > - "indexes": [*] optional
> > -
> > - The value of "columns" is a JSON object whose names are column
> > - names and whose values are s.
> > -
> > - Every table has the following columns whose definitions are not
> > - included in the schema:
> > -
> > - "_uuid": This column, which contains exactly one UUID value,
> > - is initialized to a random value by the database engine when
> > - it creates a row. It is read-only, and its value never
> > - changes during the lifetime of a row.
> > -
> > - "_version": Like "_uuid", this column contains exactly one
> > - UUID value, initialized to a random value by the database
> > - engine when it creates a row, and it is read-only. However,
> > - its value changes to a new random value whenever any other
> > - field in the row changes. Furthermore, its value is
> > - ephemeral: when the database is closed and reopened, or when
> > - the database process is stopped and then started again, each
> > - "_version" also changes to a new random value.
> > -
> > - If "isRoot" is omitted or specified as false, then any given row
> > - in the table may exist only when there is at least one reference
> > - to it, with refType "strong", from a different row (in the same
> > - table or a different table). This is a "deferred" action:
> > - unreferenced rows in the table are deleted just before transaction
> > - commit. If "isRoot" is specified as true, then rows in the table
> > - exist independent of any references (they can be thought of as
> > - part of the "root set" in a garbage collector).
> > -
> > - For compatibility with schemas created before "isRoot" was
> > - introduced, if "isRoot" is omitted or false in every
> > - in a given , then every table is
> > - part of the root set.
> > -
> > - If "maxRows" is specified, as a positive integer, it limits the
> > - maximum number of rows that may be present in the table. This is
> > - a "deferred" constraint, enforced only at transaction commit time
> > - (see the "transact" request below). If "maxRows" is not
> > - specified, the size of the table is limited only by the resources
> > - available to the database server. "maxRows" constraints are
> > - enforced after unreferenced rows are deleted from tables with a
> > - false "isRoot".
> > -
> > - If "indexes" is specified, it must be an array of zero or more
> > - s. A is an array of one or more strings,
> > - each of which names a column. Each is a set of
> > - columns whose values, taken together within any given row, must be
> > - unique within the table. This is a "deferred" constraint,
> > - enforced only at transaction commit time, after unreferenced rows
> > - are deleted and dangling weak references are removed. Ephemeral
> > - columns may not be part of indexes.
> > -
> > -
> > -
> > - A JSON object with the following members:
> > -
> > - "type": required
> > - "ephemeral": optional
> > - "mutable": optional
> > -
> > - The "type" specifies the type of data stored in this column.
> > -
> > - If "ephemeral" is specified as true, then this column's values are
> > - not guaranteed to be durable; they may be lost when the database
> > - restarts. A column whose type (either key or value) is a strong
> > - reference to a table that is not part of the root set is always
> > - durable, regardless of this value. (Otherwise, restarting the
> > - database could lose entire rows.)
> > -
> > - If "mutable" is specified as false, then this column's values may
> > - not be modified after they are initially set with the "insert"
> > - operation.
> > -
> > -
> > -
> > - The type of a database column. Either an or a JSON
> > - object that describes the type of a database column, with the
> > - following members:
> > -
> > - "key": required
> > - "value": optional
> > - "min": optional
> > - "max": or "unlimited" optional
> > -
> > - If "min" or "max" is not specified, each defaults to 1. If "max"
> > - is specified as "unlimited", then there is no specified maximum
> > - number of elements, although the implementation will enforce some
> > - limit. After considering defaults, "min" must be exactly 0 or
> > - exactly 1, "max" must be at least 1, and "max" must be greater
> > - than or equal to "min".
> > -
> > - If "min" and "max" are both 1 and "value" is not specified, the
> > - type is the scalar type specified by "key".
> > -
> > - If "min" is not 1 or "max" is not 1, or both, and "value" is not
> > - specified, the type is a set of scalar type "key".
> > -
> > - If "value" is specified, the type is a map from type "key" to type
> > - "value".
> > -
> > -
> > -
> > - The type of a key or value in a database column. Either an
> > - or a JSON object with the following members:
> > -
> > - "type": required
> > - "enum": optional
> > - "minInteger": optional, integers only
> > - "maxInteger": optional, integers only
> > - "minReal": optional, reals only
> > - "maxReal": optional, reals only
> > - "minLength": optional, strings only
> > - "maxLength": optional, strings only
> > - "refTable": optional, uuids only
> > - "refType": "strong" or "weak" optional, only with "refTable"
> > -
> > - An by itself is equivalent to a JSON object with a
> > - single member "type" whose value is the .
> > -
> > - "enum" may be specified as a whose type is a set of one
> > - or more values specified for the member "type". If "enum" is
> > - specified, then the valid values of the are limited to
> > - those in the .
> > -
> > - "enum" is mutually exclusive with the following constraints.
> > -
> > - If "type" is "integer", then "minInteger" or "maxInteger" or both
> > - may also be specified, restricting the valid integer range. If
> > - both are specified, then the maxInteger must be greater than or
> > - equal to minInteger.
> > -
> > - If "type" is "real", then "minReal" or "maxReal" or both may also
> > - be specified, restricting the valid real range. If both are
> > - specified, then the maxReal must be greater than or equal to
> > - minReal.
> > -
> > - If "type" is "string", then "minLength" and "maxLength" or both
> > - may be specified, restricting the valid length of value strings.
> > - If both are specified, then maxLength must be greater than or
> > - equal to minLength. String length is measured in characters (not
> > - bytes or UTF-16 code units).
> > -
> > - If "type" is "uuid", then "refTable", if present, must be the name
> > - of a table within this database. If "refTable" is specified, then
> > - "refType" may also be specified. If "refTable" is set, the effect
> > - depends on "refType":
> > -
> > - - If "refType" is "strong" or if "refType" is omitted, the
> > - allowed UUIDs are limited to UUIDs for rows in the named
> > - table.
> > -
> > - - If "refType" is "weak", then any UUIDs are allowed, but
> > - UUIDs that do not correspond to rows in the named table will
> > - be automatically deleted.
> > -
> > - "refTable" constraints are "deferred" constraints: they are
> > - enforced only at transaction commit time (see the "transact"
> > - request below). The other contraints on are
> > - "immediate", enforced immediately by each operation.
> > -
> > -
> > -
> > - One of the strings "integer", "real", "boolean", "string", or
> > - "uuid", representing the specified scalar type.
> > -
> > -Wire Protocol
> > --------------
> > -
> > -The database wire protocol is implemented in JSON-RPC 1.0. We
> > -encourage use of JSON-RPC over stream connections instead of JSON-RPC
> > -over HTTP, for these reasons:
> > -
> > - * JSON-RPC is a peer-to-peer protocol, but HTTP is a client-server
> > - protocol, which is a poor match. Thus, JSON-RPC over HTTP
> > - requires the client to periodically poll the server to receive
> > - server requests.
> > -
> > - * HTTP is more complicated than stream connections and doesn't
> > - provide any corresponding advantage.
> > -
> > - * The JSON-RPC specification for HTTP transport is incomplete.
> > -
> > -We are currently using TCP port 6632 for the database JSON-RPC
> > -connection, but future versions will switch to using IANA-assigned TCP
> > -port 6640.
> > -
> > -The database wire protocol consists of the following JSON-RPC methods:
> > -
> > -list_dbs
> > -........
> > -
> > -Request object members:
> > -
> > - "method": "list_dbs" required
> > - "params": [] required
> > - "id": required
> > -
> > -Response object members:
> > -
> > - "result": [, ...]
> > - "error": null
> > - "id": same "id" as request
> > -
> > -This operation retrieves an array whose elements are s
> > -that name the databases that can be accessed over this JSON-RPC
> > -connection.
> > -
> > -get_schema
> > -..........
> > -
> > -Request object members:
> > -
> > - "method": "get_schema" required
> > - "params": [] required
> > - "id": required
> > -
> > -Response object members:
> > -
> > - "result": 
> > - "error": null
> > - "id": same "id" as request
> > -
> > -This operation retrieves a that describes hosted
> > -database .
> > -
> > -transact
> > -........
> > -
> > -Request object members:
> > -
> > - "method": "transact" required
> > - "params": [, *] required
> > - "id": required
> > -
> > -Response object members:
> > -
> > - "result": [*]
> > - "error": null
> > - "id": same "id" as request
> > -
> > -The "params" array for this method consists of a that
> > -identifies the database to which the transaction applies, followed by
> > -zero or more JSON objects, each of which represents a single database
> > -operation. The "Operations" section below describes the valid
> > -operations.
> > -
> > -The value of "id" must be unique among all in-flight transactions
> > -within the current JSON-RPC session. Otherwise, the server may return
> > -a JSON-RPC error.
> > -
> > -The database server executes each of the specified operations in the
> > -specified order, except that if an operation fails, then the remaining
> > -operations are not executed.
> > -
> > -The set of operations is executed as a single atomic, consistent,
> > -isolated transaction. The transaction is committed only if every
> > -operation succeeds. Durability of the commit is not guaranteed unless
> > -the "commit" operation, with "durable" set to true, is included in the
> > -operation set (see below).
> > -
> > -Regardless of whether errors occur, the response is always a JSON-RPC
> > -response with null "error" and a "result" member that is an array with
> > -the same number of elements as "params". Each element of the "result"
> > -array corresponds to the same element of the "params" array. The
> > -"result" array elements may be interpreted as follows:
> > -
> > - - A JSON object that does not contain an "error" member indicates
> > - that the operation completed successfully. The specific members
> > - of the object are specified below in the descriptions of
> > - individual operations. Some operations do not produce any
> > - results, in which case the object will have no members.
> > -
> > - - An , which indicates that the operation completed with an
> > - error.
> > -
> > - - A JSON null value indicates that the operation was not attempted
> > - because a prior operation failed.
> > -
> > -In general, "result" contains some number of successful results,
> > -possibly followed by an error, in turn followed by enough JSON null
> > -values to match the number of elements in "params". There is one
> > -exception: if all of the operations succeed, but the results cannot be
> > -committed, then "result" will have one more element than "params",
> > -with the additional element an . The possible "error" strings
> > -include at least the following:
> > -
> > - "error": "referential integrity violation"
> > -
> > - When the commit was attempted, a column's value referenced the
> > - UUID for a row that did not exist in the table named by the
> > - column's key or value "refTable" that has a
> > - "refType" of "strong". (This can be caused by inserting a row
> > - that references a nonexistent row, by deleting a row that is
> > - still referenced by another row, by specifying the UUID for a
> > - row in the wrong table, and other ways.)
> > -
> > - "error": "constraint violation"
> > -
> > - A column with a key or value "refTable" whose
> > - "refType" is "weak" became empty due to deletion(s) caused
> > - because the rows that it referenced were deleted (or never
> > - existed, if the column's row was inserted within the
> > - transaction), and this column is not allowed to be empty
> > - because its has a "min" of 1.
> > -
> > - "error": "constraint violation"
> > -
> > - The number of rows in a table exceeds the maximum number
> > - permitted by the table's "maxRows" value (see ).
> > -
> > - "error": "constraint violation"
> > -
> > - Two or more rows in a table had the same values in the columns
> > - that comprise an index.
> > -
> > - "error": "resources exhausted"
> > - "error": "I/O error"
> > -
> > - As described in the definition of above.
> > -
> > -If "params" contains one or more "wait" operations, then the
> > -transaction may take an arbitrary amount of time to complete. The
> > -database implementation must be capable of accepting, executing, and
> > -replying to other transactions and other JSON-RPC requests while a
> > -transaction or transactions containing "wait" operations are
> > -outstanding on the same or different JSON-RPC sessions.
> > -
> > -The section "Notation for the Wire Protocol" below describes
> > -additional notation for use with the wire protocol. After that, the
> > -"Operations" section describes each operation.
> > -
> > -cancel
> > -......
> > -
> > -Request object members:
> > -
> > - "method": "cancel" required
> > - "params": [the "id" for an outstanding request] required
> > - "id": null required
> > -
> > -Response object members:
> > -
> > - 
> > -
> > -This JSON-RPC notification instructs the database server to
> > -immediately complete or cancel the "transact" request whose "id" is
> > -the same as the notification's "params" value.
> > -
> > -If the "transact" request can be completed immediately, then the
> > -server sends a response in the form described for "transact", above.
> > -Otherwise, the server sends a JSON-RPC error response of the following
> > -form:
> > -
> > - "result": null
> > - "error": "canceled"
> > - "id": the request "id" member
> > -
> > -The "cancel" notification itself has no reply.
> > -
> > -monitor
> > -.......
> > -
> > -Request object members:
> > -
> > - "method": "monitor" required
> > - "params": [, , ] required
> > - "id": required
> > -
> > - is an object that maps from a table name to an
> > -array of objects. For backward compatibility, a
> > -single may be used instead of an array; it is
> > -treated as a single-element array.
> > -
> > -Each is an object with the following members:
> > -
> > - "columns": [*] optional
> > - "select": optional
> > -
> > - is an object with the following members:
> > -
> > - "initial": optional
> > - "insert": optional
> > - "delete": optional
> > - "modify": optional
> > -
> > -Response object members:
> > -
> > - "result": 
> > - "error": null
> > - "id": same "id" as request
> > -
> > -This JSON-RPC request enables a client to replicate tables or subsets
> > -of tables within database . Each element of
> > - specifies a table to be replicated. The JSON-RPC
> > -response to the "monitor" includes the initial contents of each table,
> > -unless disabled (see below). Afterward, when changes to those tables
> > -are committed, the changes are automatically sent to the client using
> > -the "update" monitor notification. This monitoring persists until the
> > -JSON-RPC session terminates or until the client sends a
> > -"monitor_cancel" JSON-RPC request.
> > -
> > -Each describes how to monitor columns in a table:
> > -
> > - The circumstances in which an "update" notification is sent for a
> > - row within the table are determined by :
> > -
> > - If "initial" is omitted or true, every row in the table is
> > - sent as part of the reply to the "monitor" request.
> > -
> > - If "insert" is omitted or true, "update" notifications are
> > - sent for rows newly inserted into the table.
> > -
> > - If "delete" is omitted or true, "update" notifications are
> > - sent for rows deleted from the table.
> > -
> > - If "modify" is omitted or true, "update" notifications are
> > - sent whenever when a row in the table is modified.
> > -
> > - The "columns" member specifies the columns whose values are
> > - monitored. It must not contain duplicates. If "columns" is
> > - omitted, all columns in the table, except for "_uuid", are
> > - monitored.
> > -
> > -If there is more than one in an array of them, then
> > -each in the array should specify both "columns" and
> > -"select", and the "columns" must be non-overlapping sets.
> > -
> > -The "result" in the JSON-RPC response to the "monitor" request is a
> > - object (see below) that contains the contents of the
> > -tables for which "initial" rows are selected. If no tables' initial
> > -contents are requested, then "result" is an empty object.
> > -
> > -update
> > -......
> > -
> > -Notification object members:
> > -
> > - "method": "update"
> > - "params": [, ]
> > - "id": null
> > -
> > -The in "params" is the same as the value passed as the
> > - in "params" for the "monitor" request.
> > -
> > - is an object that maps from a table name to a
> > -.
> > -
> > -A is an object that maps from the row's UUID (as a
> > -36-byte string) to a object.
> > -
> > -A is an object with the following members:
> > -
> > - "old": present for "delete" and "modify" updates
> > - "new": present for "initial", "insert", and "modify" updates
> > -
> > -This JSON-RPC notification is sent from the server to the client to
> > -tell it about changes to a monitored table (or the initial state of a
> > -modified table). Each table in which one or more rows has changed (or
> > -whose initial view is being presented) is represented in "updates".
> > -Each row that has changed (or whose initial view is being presented)
> > -is represented in its as a member with its name taken
> > -from the row's _uuid member. The corresponding value is a
> > -:
> > -
> > - The "old" member is present for "delete" and "modify" updates.
> > - For "delete" updates, each monitored column is included. For
> > - "modify" updates, the prior value of each monitored column whose
> > - value has changed is included (monitored columns that have not
> > - changed are represented in "new").
> > -
> > - The "new" member is present for "initial", "insert", and "modify"
> > - updates. For "initial" and "insert" updates, each monitored
> > - column is included. For "modify" updates, the new value of each
> > - monitored column is included.
> > -
> > -monitor_cancel
> > -..............
> > -
> > -Request object members:
> > -
> > - "method": "monitor_cancel" required
> > - "params": [] required
> > - "id": required
> > -
> > -Response object members:
> > -
> > - "result": {}
> > - "error": null
> > - "id": the request "id" member
> > -
> > -Cancels the ongoing table monitor request, identified by the
> > - in "params" matching the in "params" for an
> > -ongoing "monitor" request. No more "update" messages will be sent for
> > -this table monitor.
> > -
> > -lock operations
> > -...............
> > -
> > -Request object members:
> > -
> > - "method": "lock", "steal", or "unlock" required
> > - "params": [] required
> > - "id": required
> > -
> > -Response object members:
> > -
> > - "result": {"locked": } for "lock"
> > - "result": {"locked": true} for "steal"
> > - "result": {} for "unlock"
> > - "error": null
> > - "id": same "id" as request
> > -
> > -Performs an operation on a "lock" object. The database server
> > -supports an arbitrary number of locks, each of which is identified by
> > -a client-defined id (given in "params"). At any given time, each lock
> > -may have at most one owner.
> > -
> > -The locking operation depends on "method":
> > -
> > - - "lock": The database will assign this client ownership of the
> > - lock as soon as it becomes available. When multiple clients
> > - request the same lock, they will receive it in first-come, first
> > - served order.
> > -
> > - - "steal": The database immediately assigns this client ownership
> > - of the lock. If there is an existing owner, it loses ownership.
> > -
> > - - "unlock": If the client owns the lock, releases it. If the
> > - client is waiting to obtain the lock, cancels the request and
> > - stops waiting.
> > -
> > - (Closing or otherwise disconnecting a database client connection
> > - unlocks all of its locks.)
> > -
> > -For any given lock, the client must alternate "lock" or "steal"
> > -operations with "unlock" operations. That is, if the previous
> > -operation on a lock was "lock" or "steal", it must be followed by an
> > -"unlock" operation, and vice versa.
> > -
> > -For a "lock" operation, the "locked" member in the response object is
> > -true if the lock has already been acquired, false if another client
> > -holds the lock and the client's request for it was queued. In the
> > -latter case, the client will be notified later with a "locked" message
> > -when acquisition succeeds.
> > -
> > -These requests complete and send a response quickly, without waiting.
> > -The "locked" and "stolen" notifications (see below) report
> > -asynchronous changes to ownership.
> > -
> > -The scope of a lock is a database server, not a database hosted by
> > -that server. A naming convention, such as "__",
> > -can effectively limit the scope of a lock to a particular database.
> > -
> > -locked
> > -......
> > -
> > -Notification object members:
> > -
> > - "method": "locked"
> > - "params": []
> > - "id": null
> > -
> > -Notifies the client that a "lock" operation that it previously
> > -requested has succeeded. The client now owns the lock named in
> > -"params".
> > -
> > -The database server sends this notification after the reply to the
> > -corresponding "lock" request (but only if the "locked" member of the
> > -response was false), and before the reply to the client's subsequent
> > -"unlock" request.
> > -
> > -stolen
> > -......
> > -
> > -Notification object members:
> > -
> > - "method": "stolen"
> > - "params": []
> > - "id": null
> > -
> > -Notifies the client that owns a lock that another database client has
> > -stolen ownership of the lock. The client no longer owns the lock
> > -named in "params". The client must still issue an "unlock" request
> > -before performing any subsequent "lock" or "steal" operation on the
> > -lock.
> > -
> > -If the client originally obtained the lock through a "lock" request,
> > -then it will automatically regain the lock later after the client that
> > -stole it releases it. (The database server will send the client a
> > -"locked" notification at that point to let it know.)
> > -
> > -If the client originally obtained the lock through a "steal" request,
> > -the database server won't automatically reassign it ownership of the
> > -lock when it later becomes available. To regain ownership, the client
> > -must "unlock" and then "lock" or "steal" the lock again.
> > -
> > -echo
> > -....
> > -
> > -Request object members:
> > -
> > - "method": "echo" required
> > - "params": JSON array with any contents required
> > - "id": required
> > -
> > -Response object members:
> > -
> > - "result": same as "params"
> > - "error": null
> > - "id": the request "id" member
> > -
> > -Both the JSON-RPC client and the server must implement this request.
> > -
> > -This JSON-RPC request and response can be used to implement connection
> > -keepalives, by allowing the server to check that the client is still
> > -there or vice versa.
> > -
> > -
> > -Notation for the Wire Protocol
> > -------------------------------
> > -
> > -
> > -
> > - An that names a database. The valid s can be
> > - obtained using a "list-db" request. The is taken from
> > - the "name" member of .
> > -
> > -
> > -
> > - An that names a table.
> > -
> > -
> > -
> > - An that names a table column.
> > -
> > -
> > -
> > - A JSON object that describes a table row or a subset of a table
> > - row. Each member is the name of a table column paired with the
> > - of that column.
> > -
> > -
> > -
> > - A JSON value that represents the value of a column in a table row,
> > - one of , a , or a .
> > -
> > -
> > -
> > - A JSON value that represents a scalar value for a column, one of
> > - , , , , .
> > -
> > -
> > -
> > - Either an , representing a set with exactly one element, or
> > - a 2-element JSON array that represents a database set value. The
> > - first element of the array must be the string "set" and the second
> > - element must be an array of zero or more s giving the values
> > - in the set. All of the s must have the same type.
> > -
> > -
> > -
> > - A 2-element JSON array that represents a database map value. The
> > - first element of the array must be the string "map" and the second
> > - element must be an array of zero or more s giving the values
> > - in the map. All of the s must have the same key and value
> > - types.
> > -
> > - (JSON objects are not used to represent because JSON only
> > - allows string names in an object.)
> > -
> > -
> > -
> > - A 2-element JSON array that represents a pair within a database
> > - map. The first element is an that represents the key, the
> > - second element is an that represents the value.
> > -
> > -
> > -
> > - A 2-element JSON array that represents a UUID. The first element
> > - of the array must be the string "uuid" and the second element must
> > - be a 36-character string giving the UUID in the format described
> > - by RFC 4122. For example, the following represents the
> > - UUID 550e8400-e29b-41d4-a716-446655440000:
> > -
> > - ["uuid", "550e8400-e29b-41d4-a716-446655440000"]
> > -
> > -
> > -
> > - A 2-element JSON array that represents the UUID of a row inserted
> > - in an "insert" operation within the same transaction. The first
> > - element of the array must be the string "named-uuid" and the
> > - second element should be the specified as the "uuid-name"
> > - for an "insert" operation within the same transaction. For
> > - example, if an "insert" operation within this transaction
> > - specifies a "uuid-name" of "myrow", the following 
> > - represents the UUID created by that operation:
> > -
> > - ["named-uuid", "myrow"]
> > -
> > - A may be used anywhere a is valid.
> > -
> > -
> > -
> > - A 3-element JSON array of the form [, ,
> > - ] that represents a test on a column value.
> > -
> > - Except as otherwise specified below, must have the same
> > - type as .
> > -
> > - The meaning depends on the type of :
> > -
> > - integer
> > - real
> > -
> > - must be "<", "<=", "==", "!=", ">=", ">",
> > - "includes", or "excludes".
> > -
> > - The test is true if the column's value satisfies the
> > - relation , e.g. if the column has value
> > - 1 and is 2, the test is true if is "<",
> > - "<=" or "!=", but not otherwise.
> > -
> > - "includes" is equivalent to "=="; "excludes" is equivalent
> > - to "!=".
> > -
> > - boolean
> > - string
> > - uuid
> > -
> > - must be "!=", "==", "includes", or "excludes".
> > -
> > - If is "==" or "includes", the test is true if
> > - the column's value equals . If is "!="
> > - or "excludes", the test is inverted.
> > -
> > - set
> > - map
> > -
> > - must be "!=", "==", "includes", or "excludes".
> > -
> > - If is "==", the test is true if the column's
> > - value contains exactly the same values (for sets) or pairs
> > - (for maps). If is "!=", the test is inverted.
> > -
> > - If is "includes", the test is true if the
> > - column's value contains all of the values (for sets) or
> > - pairs (for maps) in . The column's value may also
> > - contain other values or pairs.
> > -
> > - If is "excludes", the test is true if the
> > - column's value does not contain any of the values (for
> > - sets) or pairs (for maps) in . The column's value
> > - may contain other values or pairs not in .
> > -
> > - If is "includes" or "excludes", then the
> > - required type of is slightly relaxed, in that it
> > - may have fewer than the minimum number of elements
> > - specified by the column's type. If is
> > - "excludes", then the required type is additionally relaxed
> > - in that may have more than the maximum number of
> > - elements specified by the column's type.
> > -
> > -
> > -
> > - One of "<", "<=", "==", "!=", ">=", ">", "includes", "excludes".
> > -
> > -
> > -
> > - A 3-element JSON array of the form [, , ]
> > - that represents a change to a column value.
> > -
> > - Except as otherwise specified below, must have the same
> > - type as .
> > -
> > - The meaning depends on the type of :
> > -
> > - integer
> > - real
> > -
> > - must be "+=", "-=", "*=", "/=" or (integer only)
> > - "%=". The value of is changed to the sum,
> > - difference, product, quotient, or remainder, respectively,
> > - of and .
> > -
> > - Constraints on are ignored when parsing .
> > -
> > - boolean
> > - string
> > - uuid
> > -
> > - No valid s are currently defined for these types.
> > -
> > - set
> > -
> > - Any valid for the set's element type may be
> > - applied to the set, in which case the mutation is applied
> > - to each member of the set individually. must be a
> > - scalar value of the same type as the set's element type,
> > - except that contraints are ignored.
> > -
> > - If is "insert", then each of the values in the
> > - set in is added to if it is not already
> > - present. The required type of is slightly
> > - relaxed, in that it may have fewer than the minimum number
> > - of elements specified by the column's type.
> > -
> > - If is "delete", then each of the values in the
> > - set in is removed from if it is present
> > - there. The required type is slightly relaxed in that
> > - may have more or less than the maximum number of
> > - elements specified by the column's type.
> > -
> > - map
> > -
> > - must be "insert" or "delete".
> > -
> > - If is "insert", then each of the key-value pairs
> > - in the map in is added to only if its key
> > - is not already present. The required type of is
> > - slightly relaxed, in that it may have fewer than the
> > - minimum number of elements specified by the column's type.
> > -
> > - If is "delete", then may have the same
> > - type as (a map type) or it may be a set whose
> > - element type is the same as 's key type:
> > -
> > - - If is a map, the mutation deletes each
> > - key-value pair in whose key and value equal
> > - one of the key-value pairs in .
> > -
> > - - If is a set, the mutation deletes each
> > - key-value pair in whose key equals one of
> > - the values in .
> > -
> > - For "delete", may have any number of elements,
> > - regardless of restrictions on the number of elements in
> > - .
> > -
> > -
> > -
> > - One of "+=", "-=", "*=", "/=", "%=", "insert", "delete".
> > -
> > -Operations
> > -----------
> > -
> > -Each of the available operations is described below.
> > -
> > -insert
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "insert" required
> > - "table":
> required
> > - "row": required
> > - "uuid-name": optional
> > -
> > -Result object members:
> > -
> > - "uuid": 
> > -
> > -Semantics:
> > -
> > - Inserts "row" into "table".
> > -
> > - If "row" does not specify values for all the columns in "table",
> > - those columns receive default values. The default value for a
> > - column depends on its type. The default for a column whose 
> > - specifies a "min" of 0 is an empty set or empty map. Otherwise,
> > - the default is a single value or a single key-value pair, whose
> > - value(s) depend on its :
> > -
> > - - "integer" or "real": 0
> > -
> > - - "boolean": false
> > -
> > - - "string": "" (the empty string)
> > -
> > - - "uuid": 00000000-0000-0000-0000-000000000000
> > -
> > - The new row receives a new, randomly generated UUID.
> > -
> > - If "uuid-name" is supplied, then it is an error if is not
> > - unique among the "uuid-name"s supplied on all the "insert"
> > - operations within this transaction.
> > -
> > - The UUID for the new row is returned as the "uuid" member of the
> > - result.
> > -
> > -Errors:
> > -
> > - "error": "duplicate uuid-name"
> > -
> > - The same "uuid-name" appears on another "insert" operation
> > - within this transaction.
> > -
> > - "error": "constraint violation"
> > -
> > - One of the values in "row" does not satisfy the immediate
> > - constraints for its column's . This error will
> > - occur for columns that are not explicitly set by "row" if the
> > - default value does not satisfy the column's constraints.
> > -
> > -select
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "select" required
> > - "table":
> required
> > - "where": [*] required
> > - "columns": [*] optional
> > -
> > -Result object members:
> > -
> > - "rows": [*]
> > -
> > -Semantics:
> > -
> > - Searches "table" for rows that match all the conditions specified
> > - in "where". If "where" is an empty array, every row in "table" is
> > - selected.
> > -
> > - The "rows" member of the result is an array of objects. Each
> > - object corresponds to a matching row, with each column
> > - specified in "columns" as a member, the column's name as the
> > - member name and its value as the member value. If "columns"
> > - is not specified, all the table's columns are included. If
> > - two rows of the result have the same values for all included
> > - columns, only one copy of that row is included in "rows".
> > - Specifying "_uuid" within "columns" will avoid dropping
> > - duplicates, since every row has a unique UUID.
> > -
> > - The ordering of rows within "rows" is unspecified.
> > -
> > -update
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "update" required
> > - "table":
> required
> > - "where": [*] required
> > - "row": required
> > -
> > -Result object members:
> > -
> > - "count": 
> > -
> > -Semantics:
> > -
> > - Updates rows in a table.
> > -
> > - Searches "table" for rows that match all the conditions
> > - specified in "where". For each matching row, changes the
> > - value of each column specified in "row" to the value for that
> > - column specified in "row".
> > -
> > - The "_uuid" and "_version" columns of a table may not be directly
> > - updated with this operation. Columns designated read-only in the
> > - schema also may not be updated.
> > -
> > - The "count" member of the result specifies the number of rows
> > - that matched.
> > -
> > -Errors:
> > -
> > - "error": "constraint violation"
> > -
> > - One of the values in "row" does not satisfy the immediate
> > - constraints for its column's .
> > -mutate
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "mutate" required
> > - "table":
> required
> > - "where": [*] required
> > - "mutations": [*] required
> > -
> > -Result object members:
> > -
> > - "count": 
> > -
> > -Semantics:
> > -
> > - Mutates rows in a table.
> > -
> > - Searches "table" for rows that match all the conditions specified
> > - in "where". For each matching row, mutates its columns as
> > - specified by each in "mutations", in the order
> > - specified.
> > -
> > - The "_uuid" and "_version" columns of a table may not be directly
> > - modified with this operation. Columns designated read-only in the
> > - schema also may not be updated.
> > -
> > - The "count" member of the result specifies the number of rows
> > - that matched.
> > -
> > -Errors:
> > -
> > - "error": "domain error"
> > -
> > - The result of the mutation is not mathematically defined,
> > - e.g. division by zero.
> > -
> > - "error": "range error"
> > -
> > - The result of the mutation is not representable within the
> > - database's format, e.g. an integer result outside the range
> > - INT64_MIN...INT64_MAX or a real result outside the range
> > - -DBL_MAX...DBL_MAX.
> > -
> > - "error": "constraint violation"
> > -
> > - The mutation caused the column's value to violate a
> > - constraint, e.g. it caused a column to have more or fewer
> > - values than are allowed, an arithmetic operation caused a set
> > - or map to have duplicate elements, or it violated a constraint
> > - specified by a column's .
> > -
> > -delete
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "delete" required
> > - "table":
> required
> > - "where": [*] required
> > -
> > -Result object members:
> > -
> > - "count": 
> > -
> > -Semantics:
> > -
> > - Deletes all the rows from "table" that match all the conditions
> > - specified in "where".
> > -
> > - The "count" member of the result specifies the number of deleted
> > - rows.
> > -
> > -wait
> > -....
> > -
> > -Request object members:
> > -
> > - "op": "wait" required
> > - "timeout": optional
> > - "table":
> required
> > - "where": [*] required
> > - "columns": [*] required
> > - "until": "==" or "!=" required
> > - "rows": [*] required
> > -
> > -Result object members:
> > -
> > - none
> > -
> > -Semantics:
> > -
> > - Waits until a condition becomes true.
> > -
> > - If "until" is "==", checks whether the query on "table" specified
> > - by "where" and "columns", which is evaluated in the same way as
> > - specified for "select", returns the result set specified by
> > - "rows". If it does, then the operation completes successfully.
> > - Otherwise, the entire transaction rolls back. It is automatically
> > - restarted later, after a change in the database makes it possible
> > - for the operation to succeed. The client will not receive a
> > - response until the operation permanently succeeds or fails.
> > -
> > - If "until" is "!=", the sense of the test is negated. That is, as
> > - long as the query on "table" specified by "where" and "columns"
> > - returns "rows", the transaction will be rolled back and restarted
> > - later.
> > -
> > - If "timeout" is specified, then the transaction aborts after the
> > - specified number of milliseconds. The transaction is guaranteed
> > - to be attempted at least once before it aborts. A "timeout" of 0
> > - will abort the transaction on the first mismatch.
> > -
> > -Errors:
> > -
> > - "error": "not supported"
> > -
> > - One or more of the columns in this table do not support
> > - triggers. This error will not occur if "timeout" is 0.
> > -
> > - "error": "timed out"
> > -
> > - The "timeout" was reached before the transaction was able to
> > - complete.
> > -
> > -commit
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "commit" required
> > - "durable": required
> > -
> > -Result object members:
> > -
> > - none
> > -
> > -Semantics:
> > -
> > - If "durable" is specified as true, then the transaction, if it
> > - commits, will be stored durably (to disk) before the reply is sent
> > - to the client.
> > -
> > -Errors:
> > -
> > - "error": "not supported"
> > -
> > - When "durable" is true, this database implementation does not
> > - support durable commits.
> > -
> > -abort
> > -.....
> > -
> > -Request object members:
> > -
> > - "op": "abort" required
> > -
> > -Result object members:
> > -
> > - (never succeeds)
> > -
> > -Semantics:
> > -
> > - Aborts the transaction with an error. This may be useful for
> > - testing.
> > -
> > -Errors:
> > -
> > - "error": "aborted"
> > -
> > - This operation always fails with this error.
> > -
> > -comment
> > -.......
> > -
> > -
> > -Request object members:
> > -
> > - "op": "comment" required
> > - "comment": required
> > -
> > -Result object members:
> > -
> > - none
> > -
> > -Semantics:
> > -
> > - Provides information to a database administrator on the purpose of
> > - a transaction. The OVSDB server, for example, adds comments in
> > - transactions that modify the database to the database journal.
> > -
> > -assert
> > -......
> > -
> > -Request object members:
> > -
> > - "op": "assert" required
> > - "lock": required
> > -
> > -Result object members:
> > -
> > - none
> > -
> > -Semantics:
> > -
> > - If the client does not own the lock named , aborts the
> > - transaction.
> > -
> > -Errors:
> > -
> > - "error": "not owner"
> > -
> > - The client does not own the named lock.
> > diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
> > index dfb900a..404848e 100644
> > --- a/ovsdb/automake.mk
> > +++ b/ovsdb/automake.mk
> > @@ -65,7 +65,6 @@ DISTCLEANFILES += ovsdb/ovsdb-server.1
> > MAN_ROOTS += ovsdb/ovsdb-server.1.in
> > 
> > # ovsdb-idlc
> > -EXTRA_DIST += ovsdb/SPECS
> > noinst_SCRIPTS += ovsdb/ovsdb-idlc
> > EXTRA_DIST += ovsdb/ovsdb-idlc.in
> > MAN_ROOTS += ovsdb/ovsdb-idlc.1
> > diff --git a/ovsdb/jsonrpc-server.c b/ovsdb/jsonrpc-server.c
> > index 692830c..cfaa656 100644
> > --- a/ovsdb/jsonrpc-server.c
> > +++ b/ovsdb/jsonrpc-server.c
> > @@ -1512,8 +1512,8 @@ ovsdb_jsonrpc_monitor_change_cb(const struct ovsdb_row *old, 
> > return true;
> > }
> > 
> > -/* Returns JSON for a (as described in ovsdb/SPECS) for 'row'
> > - * within 'mt', or NULL if no row update should be sent.
> > +/* Returns JSON for a (as described in RFC 7047) for 'row' within
> > + * 'mt', or NULL if no row update should be sent.
> > *
> > * The caller should specify 'initial' as true if the returned JSON is going to
> > * be used as part of the initial reply to a "monitor" request, false if it is
> > @@ -1596,9 +1596,9 @@ ovsdb_jsonrpc_monitor_compose_row_update(
> > }
> > 
> > /* Constructs and returns JSON for a object (as described in
> > - * ovsdb/SPECS) for all the outstanding changes within 'monitor', and deletes
> > - * all the outstanding changes from 'monitor'. Returns NULL if no update needs
> > - * to be sent.
> > + * RFC 7047) for all the outstanding changes within 'monitor', and deletes all
> > + * the outstanding changes from 'monitor'. Returns NULL if no update needs to
> > + * be sent.
> > *
> > * The caller should specify 'initial' as true if the returned JSON is going to
> > * be used as part of the initial reply to a "monitor" request, false if it is
> > diff --git a/ovsdb/ovsdb-server.1.in b/ovsdb/ovsdb-server.1.in
> > index a4cf344..15382b4 100644
> > --- a/ovsdb/ovsdb-server.1.in
> > +++ b/ovsdb/ovsdb-server.1.in
> > @@ -183,6 +183,54 @@ the command line or through the \fBovsdb\-server/add\-db\fR command. 
> > .so lib/vlog-unixctl.man
> > .so lib/memory-unixctl.man
> > .so lib/coverage-unixctl.man
> > +.SH "SPECIFICATIONS"
> > +.
> > +.PP
> > +\fBovsdb\-server\fR implements the Open vSwitch Database (OVSDB)
> > +protocol specified in RFC 7047, with the following clarifications:
> > +.
> > +.IP "3.1. JSON Usage"
> > +RFC 4627 says that names within a JSON object should be unique.
> > +The Open vSwitch JSON parser discards all but the last value
> > +for a name that is specified more than once.
> > +.
> > +.IP "3.2. Schema Format"
> > +RFC 7047 requires the "version" field in . Current
> > +versions of \fBovsdb\-server\fR allow it to be omitted (future
> > +versions are likely to require it).
> > +.
> > +.IP "4. Wire Protocol"
> > +The original OVSDB specifications included the following reason,
> > +omitted from RFC 7047, to operate JSON-RPC directly over a stream
> > +instead of over HTTP:
> > +.
> > +.RS
> > +.IP \(bu
> > +JSON-RPC is a peer-to-peer protocol, but HTTP is a client-server
> > +protocol, which is a poor match. Thus, JSON-RPC over HTTP requires
> > +the client to periodically poll the server to receive server requests.
> > +.IP \(bu
> > +HTTP is more complicated than stream connections and doesn't provide
> > +any corresponding advantage.
> > +.IP \(bu
> > +The JSON-RPC specification for HTTP transport is incomplete.
> > +.RE
> > +.
> > +.IP "4.1.5. Monitor"
> > +For backward compatibility, \fBovsdb\-server\fR currently permits a
> > +single to be used instead of an array; it is treated
> > +as a single-element array. Future versions of \fBovsdb\-server\fR
> > +might remove this compatibility feature.
> > +.IP
> > +Because the parameter is used to match subsequent update
> > +notifications (see below) to the request, it must be unique among all
> > +active monitors. \fBovsdb\-server\fR rejects attempt to create two
> > +monitors with the same identifier.
> > +.
> > +.IP "6. IANA Considerations"
> > +\fBovsdb\-server\fR currently defaults to its historical port number
> > +6632. Future versions will adopt IANA-assigned port 6640 as default.
> > +
> > .SH "SEE ALSO"
> > .
> > .BR ovsdb\-tool (1).
> > diff --git a/python/ovs/db/data.py b/python/ovs/db/data.py
> > index e21a1cc..6baff38 100644
> > --- a/python/ovs/db/data.py
> > +++ b/python/ovs/db/data.py
> > @@ -1,4 +1,4 @@
> > -# Copyright (c) 2009, 2010, 2011 Nicira, Inc.
> > +# Copyright (c) 2009, 2010, 2011, 2014 Nicira, Inc.
> > #
> > # Licensed under the Apache License, Version 2.0 (the "License");
> > # you may not use this file except in compliance with the License.
> > @@ -307,7 +307,7 @@ class Datum(object):
> > Violations of constraints expressed by 'type' are treated as errors.
> > 
> > If 'symtab' is nonnull, then named UUIDs in 'symtab' are accepted.
> > - Refer to ovsdb/SPECS for information about this, and for the syntax
> > + Refer to RFC 7047 for information about this, and for the syntax
> > that this function accepts."""
> > is_map = type_.is_map()
> > if (is_map or
> > --
> > 1.8.5.3
> > 
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> > 
> 



More information about the dev mailing list