Hi Robert / Vratko, 

Going through Vratko's gerrit, I noticed following 

"Prefix-based shards do not even support "non-chained" transactions"

I assume that this caveat is applicable only for the prefix-based sharding and 
does not necessarily hold good for those who continue to use module-based 
sharding. Am I correct ?
The reason why I ask is we wanted to run Netvirt CSIT with tell-based protocol 
enabled to have a basic sanity cleared with this change and then do more 
focused testing with HA and scale scenarios. 


-----Original Message-----
From: Muthukumaran K 
Sent: Thursday, August 03, 2017 10:51 AM
To: 'Robert Varga'; controller-dev
Cc: odl netvirt dev
Subject: RE: [controller-dev] Testing the FE BE separation of Datastore 

Thanks Robert. With Tom's response on 'use-tell-based-protocol' config, I 
started taking a peek at the changes required. 
Was not aware of Vratko's gerrit. Will take a look at that too to sink it in 


-----Original Message-----
From: Robert Varga [mailto:n...@hq.sk]
Sent: Wednesday, August 02, 2017 11:29 PM
To: Muthukumaran K; controller-dev
Cc: odl netvirt dev
Subject: Re: [controller-dev] Testing the FE BE separation of Datastore 

On 24/07/17 17:28, Muthukumaran K wrote:
> Hi Robert,

Hello Muthu,

sorry for the late response, this email got left behind in my drafts folder.

> This is in context of the changes for  BZ-5280. We would like to test 
> the changes on master branch. Have some clarifications on the same
> a)      Since this change had been major, as I recollect, there was a
> discussion earlier on isolating the changed code-path and old code path.
> Is the new code-path enabled by default on master ? To utilize changed 
> code-path,

As Tom already responded, this work is not active by default for the APIs 
currently used by our downstreams. It is used for fine-grained shards.

> a)      any specific configuration changes in any cfg files (eg.
> Datastore cfg) required or

Just uncomment


in datastore.cfg before you start the controller. You should get an INFO 
message when it is enabled.

> b)      a new type of Databroker to be used to use the changed codepath
> ? In case of new databroker type, if there is any sample usage, can we 
> get some pointer for the same ?

This is an internal DS implementation detail, so no changes to wiring are 

> b)      Can the changes be tested for specific AskTimeout scenarios -
> encountered earlier, like
> a)      scaled transactions with and without Transaction Chain (if Txn
> Chain is used, do we still have to use pingpong broker for better 
> results ?) of course with appropriate heap-sizing and using G1GC

Yes. I would suggest testing both, though.

> b)      split-brain healing with medium volume of config-data -
> specifically , full split (eg. Downing node interfaces and bringing 
> them back up after brief period) and heal of cluster with and without 
> ongoing transactions. For completion sake, we can also test partial 
> split and heal
> Any other specific variances of above scenario which could put the 
> changes to test ?

Idle split-brain recovery should not be affected. With tell-based protocol 
enabled, ongoing transactions should recover seamlessly if the partition heals 
reasonably quickly (2 minutes by default).

Vratko is writing up the test scenarios that are being executed somewhere. A 
progress report is at https://git.opendaylight.org/gerrit/56454. It would be 
nice if the test cases could be executed in an environment more stable than our 
CSIT substrate.


controller-dev mailing list

Reply via email to