ovsdb connection flap handling
Hi ovsdb devs,
I would like to understand how we deal with ovsdb connection flap.
The following are the requirements.
When a client connection gets disconnected, That particular node should be removed from operational topology.
When a client gets connected again, Pull its tables and put the node in operational topology.
The following scenarios needs to be addressed.
1. client got disconnected from controller1 and connected to controller2
2. client got disconnected from controller1 and connected back to controller1 again
3. The same client got connected to controller1 & controller2, but got disconnected and connected back to controller1.
The node creation should wait for previously created node deletion before proceeding , otherwise we may end up deleting the node from operational datastore.
I have raised the following gerrit review to understand this better.
https://git.opendaylight.org/gerrit/65400
Thanks,
Suneelu
Hi ovsdb devs,
I would like to understand how we deal with ovsdb connection flap.
The following are the requirements.
When a client connection gets disconnected, That particular node should be removed from operational topology.
When a client gets connected again, Pull its tables and put the node in operational topology.
The following scenarios needs to be addressed.
1. client got disconnected from controller1 and connected to controller2
2. client got disconnected from controller1 and connected back to controller1 again
3. The same client got connected to controller1 & controller2, but got disconnected and connected back to controller1.
The node creation should wait for previously created node deletion before proceeding , otherwise we may end up deleting the node from operational datastore.
I have raised the following gerrit review to understand this better.
https://git.opendaylight.
org/gerrit/65400
Thanks,
Suneelu
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@....org
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
Hi Anil,
I agree with the dampening algorithm in the library code.
If someone uses haproxy in front of the controllers ovsdb port, and client ip is changed to haproxy ip, then all the client connections appear as though they are originated from same client.
I was wondering how to handle such scenarios in library code.
Where as at plugin level it can understand whether the connection is from same client or not by querying some table UUID.
May be some dampening abstraction should be built which can be used by plugin itself ?
Thanks,
Suneelu
Sent: Friday, November 10, 2017 1:56 PM
To: K.V Suneelu Verma
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] ovsdb connection flap handling
In my opinion, if connection is flapping, we need to detect it at the library level and dampen the connection till it's stable, rather than taking care of the side effect of the flapping in the upper layer ( southbound plugin code). I would suggest to implement a simple dampening algorithm in the library code (with configuration parameters) to dampen the connection. That will avoid these ordering issues and also help us avoiding writing any complex login in the plugin layer.
On Thu, Nov 9, 2017 at 11:42 PM, K.V Suneelu Verma <k.v.suneelu.verma@...> wrote:
Hi ovsdb devs,
I would like to understand how we deal with ovsdb connection flap.
The following are the requirements.
When a client connection gets disconnected, That particular node should be removed from operational topology.
When a client gets connected again, Pull its tables and put the node in operational topology.
The following scenarios needs to be addressed.
1. client got disconnected from controller1 and connected to controller2
2. client got disconnected from controller1 and connected back to controller1 again
3. The same client got connected to controller1 & controller2, but got disconnected and connected back to controller1.
The node creation should wait for previously created node deletion before proceeding , otherwise we may end up deleting the node from operational datastore.
I have raised the following gerrit review to understand this better.
https://git.opendaylight.org/gerrit/65400
Thanks,
Suneelu
_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
--
Thanks
Anil