[ovs-discuss] The discrepancy in the Monitor request composition.

Anil Jangam anilj.mailing at gmail.com
Wed Mar 7 04:38:34 UTC 2018


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 <blp at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20180306/a48eb4c8/attachment-0001.html>


More information about the discuss mailing list