Re: [ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

2016-02-12 Thread Suryanarayan Ramamurthy
thanks !, I will make these updates in the next version From: Justin Pettit To: Ramu Ramamurthy Cc: dev@openvswitch.org, Badri Ramaswamy/Santa Clara/IBM@IBMUS Date: 02/11/2016 11:22 PM Subject:Re: [ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently Sent by

Re: [ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

2016-02-12 Thread Russell Bryant
On 02/12/2016 12:31 PM, Russell Bryant wrote: > On 02/11/2016 08:18 PM, Ramu Ramamurthy wrote: >> Currently, ovn-controller does not record the >> lport->zoneid map, and so, after ovn-controller restart, >> zone-ids may get set inconsistently on lports, resulting >> in possible hits to already esta

Re: [ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

2016-02-12 Thread Russell Bryant
On 02/11/2016 08:18 PM, Ramu Ramamurthy wrote: > Currently, ovn-controller does not record the > lport->zoneid map, and so, after ovn-controller restart, > zone-ids may get set inconsistently on lports, resulting > in possible hits to already established connections. > > Set zone-id as an external

Re: [ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

2016-02-11 Thread Justin Pettit
> On Feb 11, 2016, at 5:18 PM, Ramu Ramamurthy > wrote: I'll let Russell do the full review, but I had one other small suggestion from looking at the code: > @@ -72,13 +75,65 @@ get_local_iface_ids(const struct ovsrec_bridge *br_int, > struct shash *lports) > continue; >

Re: [ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

2016-02-11 Thread Justin Pettit
> On Feb 11, 2016, at 5:18 PM, Ramu Ramamurthy > wrote: > > @@ -65,6 +66,8 @@ get_local_iface_ids(const struct ovsrec_bridge *br_int, > struct shash *lports) > > for (j = 0; j < port_rec->n_interfaces; j++) { > const struct ovsrec_interface *iface_rec; > +const

[ovs-dev] [PATCH v3] ovn-controller: Assign zone-id consistently

2016-02-11 Thread Ramu Ramamurthy
Currently, ovn-controller does not record the lport->zoneid map, and so, after ovn-controller restart, zone-ids may get set inconsistently on lports, resulting in possible hits to already established connections. Set zone-id as an external-id of the interface record, and recover the zone-id from t