Ok, that answers my question. Thank you.

On Thu, Mar 8, 2018, 11:13 AM Ben Pfaff <b...@ovn.org> wrote:

> No.  A JSON object can have any number of members.
>
> On Thu, Mar 08, 2018 at 11:06:21AM -0800, Anil Jangam wrote:
> > Thanks Ben for clarification. So it means one Monitor request can request
> > for only one Table monitoring, correct?
> >
> > On Thu, Mar 8, 2018 at 10:36 AM, Ben Pfaff <b...@ovn.org> wrote:
> >
> > > <monitor-requests> is a JSON object.  A JSON object maps from keys to
> > > values, so we only need one.
> > >
> > > Your specification for <monitor-requests> is wrong because it says that
> > > it is a JSON array.  It is not.
> > >
> > > On Wed, Mar 07, 2018 at 09:32:06PM -0800, Anil Jangam wrote:
> > > > Hello Ben,
> > > >
> > > > I have one more observation. I request you to please read it
> carefully.
> > > If
> > > > we go by the current monitor method definition, there can be only
> > > > <monitor-requests>
> > > > in one monitor RPC method. If it is expected to have only one
> > > > <monitor-requests>
> > > > i.e. one table and an array of <monitor-request>, then the current
> > > > specification is good.
> > > >
> > > > o  "method": "monitor"
> > > >
> > > > o  "params": [<db-name>, <json-value>, <monitor-requests>]
> > > >
> > > > o  "id": <nonnull-json-value>
> > > >
> > > >
> > > > However, if it is possible to specify multiple table monitoring in
> one
> > > RPC
> > > > method, IMHO the above syntax would change as below.
> > > >
> > > >
> > > > o  "method": "monitor"
> > > >
> > > > o  "params": [<db-name>, <json-value>, <monitor-requests>*]
> > > >
> > > > o  "id": <nonnull-json-value>
> > > >
> > > >
> > > > For completeness, I am also specifying the syntax for
> <monitor-requests>.
> > > >
> > > > monitor-requests : [<table-name>, <monitor-request>*]
> > > >
> > > >
> > > > Let me know if this would be correct or if you think otherwise.
> > > >
> > > > /anil.
> > > >
> > > >
> > > >
> > > > On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff <b...@ovn.org> wrote:
> > > >
> > > > > Ah, OK, you're saying that there's a missing [] around the
> > > > > <monitor-request>.  This goes back to a change that we made to the
> > > > > ovsdb-server protocol a long time ago to allow multiple
> > > > > <monitor-request> objects instead of just a single one.
> ovsdb-server
> > > > > still supports this form.  You can see this documented in
> > > > > Documentation/ref/ovsdb-server.7.rst:
> > > > >
> > > > >     For backward compatibility, ``ovsdb-server`` currently permits
> a
> > > single
> > > > >     <monitor-request> to be used instead of an array; it is
> treated as
> > > a
> > > > >     single-element array.  Future versions of ``ovsdb-server``
> might
> > > > > remove this
> > > > >     compatibility feature.
> > > > >
> > > > > I guess we should change ovsdb-idl.c to use an array now.  Oops.
> > > > >
> > > > > Anyway, that's easy enough, so I sent a patch:
> > > > >         https://patchwork.ozlabs.org/patch/882710/
> > > > >
> > > > > On Tue, Mar 06, 2018 at 08:38:34PM -0800, Anil Jangam wrote:
> > > > > > Hello Ben,
> > > > > >
> > > > > > The <monitor-requests> object maps the name of the table to be
> > > monitored
> > > > > >
> > > > > > to an array of <monitor-request> objects. Each <monitor-request>
> is
> > > an
> > > > > >
> > > > > > object with the following members:
> > > > > >
> > > > > >        "columns": [<column>*]            optional
> > > > > >
> > > > > >        "select": <monitor-select>        optional
> > > > > >
> > > > > >
> > > > > >
> > > > > > As the <monitor-requests> maps the table name to be monitored to
> an
> > > array
> > > > > > of <monitor-request>, my interpretation of it is as "Table Name
> <-->
> > > > > Array
> > > > > > of <monitor-request>"
> > > > > >
> > > > > > I am giving an example message is given below.
> > > > > >
> > > > > > {
> > > > > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > > > > >   "method": "monitor",
> > > > > >   "params": [
> > > > > >     "hardware_vtep",
> > > > > >     "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > > > >     {
> > > > > >       "Physical_Locator": [
> > > > > >         {
> > > > > >           "columns": [
> > > > > >             "dst_ip",
> > > > > >             "encapsulation_type",
> > > > > >             "_uuid"
> > > > > >           ],
> > > > > >           "select": {
> > > > > >             "initial": true,
> > > > > >             "insert": true,
> > > > > >             "delete": true,
> > > > > >             "modify": true
> > > > > >           }
> > > > > >         },
> > > > > >         {
> > > > > >           "columns": [
> > > > > >             "_uuid",
> > > > > >             "locators"
> > > > > >           ],
> > > > > >           "select": {
> > > > > >             "initial": true,
> > > > > >             "insert": true,
> > > > > >             "delete": true,
> > > > > >             "modify": true
> > > > > >           }
> > > > > >         }
> > > > > >       ]
> > > > > >     }
> > > > > >   ]
> > > > > > }
> > > > > >
> > > > > >
> > > > > > /anil.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 6, 2018 at 11:30 AM, Ben Pfaff <b...@ovn.org> wrote:
> > > > > >
> > > > > > > On Mon, Mar 05, 2018 at 10:03:13PM -0800, Anil Jangam wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > The RFC7047 states below about the Monitor request.
> > > > > > > >
> > > > > > > > The request object has the
> > > > > > > >
> > > > > > > >    following members:
> > > > > > > >
> > > > > > > >    o  "method": "monitor"
> > > > > > > >
> > > > > > > >    o  "params": [<db-name>, <json-value>, <monitor-requests>]
> > > > > > > >
> > > > > > > >    o  "id": <nonnull-json-value>
> > > > > > > >
> > > > > > > >
> > > > > > > > The <json-value> parameter is used to match subsequent update
> > > > > > > >
> > > > > > > > notifications (see below) to this request.
> > > > > > > >
> > > > > > > >
> > > > > > > > The <monitor-requests> object maps the name of the table to
> be
> > > > > monitored
> > > > > > > >
> > > > > > > > to an array of <monitor-request> objects. Each
> <monitor-request>
> > > is
> > > > > an
> > > > > > > >
> > > > > > > > object with the following members:
> > > > > > > >
> > > > > > > >        "columns": [<column>*]            optional
> > > > > > > >
> > > > > > > >        "select": <monitor-select>        optional
> > > > > > > >
> > > > > > > > The columns, if present, define the columns within the table
> to
> > > be
> > > > > > > monitored.
> > > > > > > >
> > > > > > > > <monitor-select> is an object with the following members:
> > > > > > > >
> > > > > > > >        "initial": <boolean>              optional
> > > > > > > >
> > > > > > > >        "insert": <boolean>               optional
> > > > > > > >
> > > > > > > >        "delete": <boolean>               optional
> > > > > > > >
> > > > > > > >        "modify": <boolean>               optional
> > > > > > > >
> > > > > > > > The contents of this object specify how the columns or table
> are
> > > to
> > > > > be
> > > > > > > > monitored,
> > > > > > > >
> > > > > > > > as explained in more detail below.
> > > > > > > >
> > > > > > > >
> > > > > > > > However, when I look at some of the legitimate samples of the
> > > Monitor
> > > > > > > > requests, they are encoded as below.
> > > > > > > >
> > > > > > > > {
> > > > > > > >   "id": "c5c09c07-11c1-449b-8f04-016fefe15844",
> > > > > > > >   "method": "monitor",
> > > > > > > >   "params": [
> > > > > > > >     "hardware_vtep",
> > > > > > > >     "91c9eed4-00bb-48e3-b2d9-51e0364bbdc2",
> > > > > > > >     {
> > > > > > > >       "Physical_Locator": {
> > > > > > > >         "columns": [
> > > > > > > >           "dst_ip",
> > > > > > > >           "encapsulation_type",
> > > > > > > >           "_uuid"
> > > > > > > >         ],
> > > > > > > >         "select": {
> > > > > > > >           "initial": true,
> > > > > > > >           "insert": true,
> > > > > > > >           "delete": true,
> > > > > > > >           "modify": true
> > > > > > > >         }
> > > > > > > >       },
> > > > > > > >       "Physical_Locator_Set": {
> > > > > > > >         "columns": [
> > > > > > > >           "_uuid",
> > > > > > > >           "locators"
> > > > > > > >         ],
> > > > > > > >         "select": {
> > > > > > > >           "initial": true,
> > > > > > > >           "insert": true,
> > > > > > > >           "delete": true,
> > > > > > > >           "modify": true
> > > > > > > >         }
> > > > > > > >       }
> > > > > > > >     }
> > > > > > > >   ]
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > If we go by the RFC encoding rules, "params" contains the
> > > > > > > > <monitor-requests>, which maps the "Table name" to an array
> of
> > > > > > > > <Monitor-request> object. So IMHO, the table names comes only
> > > once
> > > > > in the
> > > > > > > > message. Correct?
> > > > > > >
> > > > > > > Yes.  That's what I see above.  The table names are
> > > Physical_Locator
> > > > > and
> > > > > > > Physical_Locator_Set, and each of them is mentioned once.
> > > > > > > In the <monitor-requests> object "Physical_Locator" is mapped
> to:
> > > > > > >
> > > > > > >        {
> > > > > > >          "columns": [
> > > > > > >            "dst_ip",
> > > > > > >            "encapsulation_type",
> > > > > > >            "_uuid"
> > > > > > >          ],
> > > > > > >          "select": {
> > > > > > >            "initial": true,
> > > > > > >            "insert": true,
> > > > > > >            "delete": true,
> > > > > > >            "modify": true
> > > > > > >          }
> > > > > > >        }
> > > > > > >
> > > > > > > and similarly for "Physical_Locator_Set".
> > > > > > >
> > > > > > > > Also, it is explicitly mentioned that (as below) and it does
> NOT
> > > > > contain
> > > > > > > > the "Table name" in it.
> > > > > > > >
> > > > > > > >
> > > > > > > > Each <monitor-request> is an
> > > > > > > >
> > > > > > > > object with the following members:
> > > > > > > >
> > > > > > > >        "columns": [<column>*]            optional
> > > > > > > >
> > > > > > > >        "select": <monitor-select>        optional
> > > > > > > >
> > > > > > > >
> > > > > > > > However, in the message payload that I have, shows the tuple,
> > > which
> > > > > > > > contains "Table : Columns : Select". This list of
> > > <monitor-request>
> > > > > > > constitute
> > > > > > > > the <monitor-requests> as per the RFC definition.
> > > > > > > >
> > > > > > > > I see this as the discrepancy between the RFC definition and
> how
> > > the
> > > > > > > > message is actually sent by the controller.
> > > > > > >
> > > > > > > I don't understand what discrepancy you see.  Can you show an
> > > example,
> > > > > > > for example by providing how you think the above example should
> > > > > actually
> > > > > > > be encoded?
> > > > > > >
> > > > >
> > >
>
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Reply via email to