[ovs-discuss] The discrepancy in the Monitor request composition.
Anil Jangam
anilj.mailing at gmail.com
Wed Mar 7 22:50:32 UTC 2018
Thanks you Ben! I saw the other patch email as well. Since it is says that
"reported-by" me, do I have any further action item on me?
/anil.
On Wed, Mar 7, 2018 at 10:27 AM, Ben Pfaff <blp at 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 <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/20180307/06fb100a/attachment-0001.html>
More information about the discuss
mailing list