Create a sidedb testcase using marbles02_private cc, simple and providing good functional coverage; (refer
FAB-10135); could use as interop test if desired with FAB-16719. Use as a basis for a test in the k8ssystest suite, using go test driver and operator functions and testInput file.
Provide a nice description of a min config required including number of peers/orgs that are in or out of the collection; endorsements required, dissemination policy parameter values, etc.
And with an eye on using with runPTE: List any prerequisite steps (install, instantiate, etc) required to be done by the tester before test execution (or if they could/should be specified as optional in the testInput file) - to ensure for example that a retest with runPTE won't try to rerun steps such as instantiation and cause a test failure.
See the "relates to" list of possible testcases to automate with this testcase.
(Note: Not sure if the newer marbles02_private cc may provide a way to use 2 private collections. If not, or if we prefer, then we could just start two separate traffic patterns in the channel: one with org1 and org2 in the priv collection, and the other using org3 and org4 in a different priv collection; later we even could add org5 to both and watch its peers reconcile both collections.)
Suggestion: run this in the raft/couchdb network, which has service discovery enabled.
Suggestion: use service discovery for sending the invokes proposals (and optionally also when sending TXs to orderers); it seems it would make verification easier once we add restarts too (during reconciliation)
The essential test is:
- use at least one private collection, require 2 endorsements (from diff orgs);
- invokes with minimum required pushes = 2 in a network with 8 or more peers to ensure some push and some pull
- validate the public and private data ledger heights on all peers.
- bonus for querying specific transactions such as the final one; query from peers who did not receive the invokes - both public and private data; query from a peer in member org, and query from a peer in nonmember org (which of course should reject the request for private data)
To cover the reconciliation portions (could do these steps with different Jira tasks), while invokes traffic is running:
- refer to 11772 (reconcile/catchup all data, public and private data, when join a new peer to channel in an org already in the priv collection)
- and refer to 11773 (on existing peer in channel in org that was not in collection, reconciles only private data when reconfig/upgradeCC to add that org to priv collection)
- restart each peer individually, including the reconciling peer, while a peer is in the reconcilliation phase
Note: we will need persistent storage set up in our test network for any test such as this which restarts peers and orderers.