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.
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
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,
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
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
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
controller-dev mailing list