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

[Anil Jangam]

Ok, that answers my question. Thank you.

On Thu, Mar 8, 2018, 11:13 AM Ben Pfaff  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  wrote:
> >
> > >  is a JSON object.  A JSON object maps from keys to
> > > values, so we only need one.
> > >
> > > Your specification for  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
> > > > 
> > > > in one monitor RPC method. If it is expected to have only one
> > > > 
> > > > i.e. one table and an array of , then the current
> > > > specification is good.
> > > >
> > > > o  "method": "monitor"
> > > >
> > > > o  "params": [, , ]
> > > >
> > > > o  "id": 
> > > >
> > > >
> > > > 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": [, , *]
> > > >
> > > > o  "id": 
> > > >
> > > >
> > > > For completeness, I am also specifying the syntax for
> .
> > > >
> > > > monitor-requests : [, *]
> > > >
> > > >
> > > > 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  wrote:
> > > >
> > > > > Ah, OK, you're saying that there's a missing [] around the
> > > > > .  This goes back to a change that we made to the
> > > > > ovsdb-server protocol a long time ago to allow multiple
> > > > >  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
> > > > >  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  object maps the name of the table to be
> > > monitored
> > > > > >
> > > > > > to an array of  objects. Each 
> is
> > > an
> > > > > >
> > > > > > object with the following members:
> > > > > >
> > > > > >"columns": [*]optional
> > > > > >
> > > > > >"select": optional
> > > > > >
> > > > > >
> > > > > >
> > > > > > As the  maps the table name to be monitored to
> an
> > > array
> > > > > > of , my interpretation of it is as "Table Name
> <-->
> > > > > Array
> > > > > > of "
> > > > > >
> > > > > > 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  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 

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

[Ben Pfaff]

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  wrote:
> 
> >  is a JSON object.  A JSON object maps from keys to
> > values, so we only need one.
> >
> > Your specification for  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
> > > 
> > > in one monitor RPC method. If it is expected to have only one
> > > 
> > > i.e. one table and an array of , then the current
> > > specification is good.
> > >
> > > o  "method": "monitor"
> > >
> > > o  "params": [, , ]
> > >
> > > o  "id": 
> > >
> > >
> > > 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": [, , *]
> > >
> > > o  "id": 
> > >
> > >
> > > For completeness, I am also specifying the syntax for .
> > >
> > > monitor-requests : [, *]
> > >
> > >
> > > 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  wrote:
> > >
> > > > Ah, OK, you're saying that there's a missing [] around the
> > > > .  This goes back to a change that we made to the
> > > > ovsdb-server protocol a long time ago to allow multiple
> > > >  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
> > > >  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  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > > > > object with the following members:
> > > > >
> > > > >"columns": [*]optional
> > > > >
> > > > >"select": optional
> > > > >
> > > > >
> > > > >
> > > > > As the  maps the table name to be monitored to an
> > array
> > > > > of , my interpretation of it is as "Table Name <-->
> > > > Array
> > > > > of "
> > > > >
> > > > > 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  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": [, , ]
> > > > > > >
> > > > > > >o  "id": 
> > > > > > >
> > > > > > >
> > > > > > > The  parameter is used to match subsequent update
> > > > > > >
> > > > > > > notifications (see below) to this request.
> > > > > > >
> > > > > > >
> > > > > > > The  object maps the name 

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

[Ben Pfaff]

 is a JSON object.  A JSON object maps from keys to
values, so we only need one.

Your specification for  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
> 
> in one monitor RPC method. If it is expected to have only one
> 
> i.e. one table and an array of , then the current
> specification is good.
> 
> o  "method": "monitor"
> 
> o  "params": [, , ]
> 
> o  "id": 
> 
> 
> 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": [, , *]
> 
> o  "id": 
> 
> 
> For completeness, I am also specifying the syntax for .
> 
> monitor-requests : [, *]
> 
> 
> 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  wrote:
> 
> > Ah, OK, you're saying that there's a missing [] around the
> > .  This goes back to a change that we made to the
> > ovsdb-server protocol a long time ago to allow multiple
> >  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
> >  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  object maps the name of the table to be monitored
> > >
> > > to an array of  objects. Each  is an
> > >
> > > object with the following members:
> > >
> > >"columns": [*]optional
> > >
> > >"select": optional
> > >
> > >
> > >
> > > As the  maps the table name to be monitored to an array
> > > of , my interpretation of it is as "Table Name <-->
> > Array
> > > of "
> > >
> > > 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  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": [, , ]
> > > > >
> > > > >o  "id": 
> > > > >
> > > > >
> > > > > The  parameter is used to match subsequent update
> > > > >
> > > > > notifications (see below) to this request.
> > > > >
> > > > >
> > > > > The  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > > > > object with the following members:
> > > > >
> > > > >"columns": [*]optional
> > > > >
> > > > >"select": optional
> > > > >
> > > > > The columns, if present, define the columns within the table to be
> > > > monitored.
> > > > >
> > > > >  is an object with the following members:
> > > > >
> > > > >"initial":   optional
> > > > >
> > > > >"insert":optional
> > > > >
> > > > >"delete":optional
> > > > >
> > > > >"modify":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 

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

[Anil Jangam]

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

in one monitor RPC method. If it is expected to have only one

i.e. one table and an array of , then the current
specification is good.

o  "method": "monitor"

o  "params": [, , ]

o  "id": 


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": [, , *]

o  "id": 


For completeness, I am also specifying the syntax for .

monitor-requests : [, *]


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  wrote:

> Ah, OK, you're saying that there's a missing [] around the
> .  This goes back to a change that we made to the
> ovsdb-server protocol a long time ago to allow multiple
>  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
>  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  object maps the name of the table to be monitored
> >
> > to an array of  objects. Each  is an
> >
> > object with the following members:
> >
> >"columns": [*]optional
> >
> >"select": optional
> >
> >
> >
> > As the  maps the table name to be monitored to an array
> > of , my interpretation of it is as "Table Name <-->
> Array
> > of "
> >
> > 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  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": [, , ]
> > > >
> > > >o  "id": 
> > > >
> > > >
> > > > The  parameter is used to match subsequent update
> > > >
> > > > notifications (see below) to this request.
> > > >
> > > >
> > > > The  object maps the name of the table to be
> monitored
> > > >
> > > > to an array of  objects. Each  is
> an
> > > >
> > > > object with the following members:
> > > >
> > > >"columns": [*]optional
> > > >
> > > >"select": optional
> > > >
> > > > The columns, if present, define the columns within the table to be
> > > monitored.
> > > >
> > > >  is an object with the following members:
> > > >
> > > >"initial":   optional
> > > >
> > > >"insert":optional
> > > >
> > > >"delete":optional
> > > >
> > > >"modify":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": 

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

[Ben Pfaff]

No.  The "Reported-by:" tag is really just a kind of "thank-you".
Thanks again.

On Wed, Mar 07, 2018 at 02:50:32PM -0800, Anil Jangam wrote:
> 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  wrote:
> 
> > Ah, OK, you're saying that there's a missing [] around the
> > .  This goes back to a change that we made to the
> > ovsdb-server protocol a long time ago to allow multiple
> >  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
> >  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  object maps the name of the table to be monitored
> > >
> > > to an array of  objects. Each  is an
> > >
> > > object with the following members:
> > >
> > >"columns": [*]optional
> > >
> > >"select": optional
> > >
> > >
> > >
> > > As the  maps the table name to be monitored to an array
> > > of , my interpretation of it is as "Table Name <-->
> > Array
> > > of "
> > >
> > > 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  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": [, , ]
> > > > >
> > > > >o  "id": 
> > > > >
> > > > >
> > > > > The  parameter is used to match subsequent update
> > > > >
> > > > > notifications (see below) to this request.
> > > > >
> > > > >
> > > > > The  object maps the name of the table to be
> > monitored
> > > > >
> > > > > to an array of  objects. Each  is
> > an
> > > > >
> > > > > object with the following members:
> > > > >
> > > > >"columns": [*]optional
> > > > >
> > > > >"select": optional
> > > > >
> > > > > The columns, if present, define the columns within the table to be
> > > > monitored.
> > > > >
> > > > >  is an object with the following members:
> > > > >
> > > > >"initial":   optional
> > > > >
> > > > >"insert":optional
> > > > >
> > > > >"delete":optional
> > > > >
> > > > >"modify":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
> > > > > }
> > > > >   

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

[Anil Jangam]

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  wrote:

> Ah, OK, you're saying that there's a missing [] around the
> .  This goes back to a change that we made to the
> ovsdb-server protocol a long time ago to allow multiple
>  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
>  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  object maps the name of the table to be monitored
> >
> > to an array of  objects. Each  is an
> >
> > object with the following members:
> >
> >"columns": [*]optional
> >
> >"select": optional
> >
> >
> >
> > As the  maps the table name to be monitored to an array
> > of , my interpretation of it is as "Table Name <-->
> Array
> > of "
> >
> > 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  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": [, , ]
> > > >
> > > >o  "id": 
> > > >
> > > >
> > > > The  parameter is used to match subsequent update
> > > >
> > > > notifications (see below) to this request.
> > > >
> > > >
> > > > The  object maps the name of the table to be
> monitored
> > > >
> > > > to an array of  objects. Each  is
> an
> > > >
> > > > object with the following members:
> > > >
> > > >"columns": [*]optional
> > > >
> > > >"select": optional
> > > >
> > > > The columns, if present, define the columns within the table to be
> > > monitored.
> > > >
> > > >  is an object with the following members:
> > > >
> > > >"initial":   optional
> > > >
> > > >"insert":optional
> > > >
> > > >"delete":optional
> > > >
> > > >"modify":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
> > > > , 

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

[Ben Pfaff]

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": [, , ]
> 
>o  "id": 
> 
> 
> The  parameter is used to match subsequent update
> 
> notifications (see below) to this request.
> 
> 
> The  object maps the name of the table to be monitored
> 
> to an array of  objects. Each  is an
> 
> object with the following members:
> 
>"columns": [*]optional
> 
>"select": optional
> 
> The columns, if present, define the columns within the table to be monitored.
> 
>  is an object with the following members:
> 
>"initial":   optional
> 
>"insert":optional
> 
>"delete":optional
> 
>"modify":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
> , which maps the "Table name" to an array of
>  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  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  is an
> 
> object with the following members:
> 
>"columns": [*]optional
> 
>"select": optional
> 
> 
> However, in the message payload that I have, shows the tuple, which
> contains "Table : Columns : Select". This list of  constitute
> the  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