<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
