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