-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support migration of the FireFly contract from one location to another #820
Conversation
Codecov Report
@@ Coverage Diff @@
## main #820 +/- ##
===========================================
+ Coverage 99.98% 100.00% +0.01%
===========================================
Files 299 301 +2
Lines 19457 19612 +155
===========================================
+ Hits 19455 19612 +157
+ Misses 1 0 -1
+ Partials 1 0 -1
Continue to review full report at Codecov.
|
I think this will now need to slot in after #826 |
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Now rebased on mainline after the merge of #826 |
Send a specially formatted "BatchPin" transaction to signal that all members should migrate to a specific version of the contract from their config. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
I think I'm right interpreting this as:
|
@peterbroadhurst In the situation that multiple local namespaces are actually pointed at the same remote namespace, I think they would still get multiple instances of the blockchain plugin (because each instance would map incoming events to its own local namespace). So they might "share a single blockchain plugin" in the sense that they'd each have an instance of the same plugin, but they wouldn't share a single instance of the plugin. |
k - feel like we need to net that out in FIR-12. Some of it might be terminology, but if you really have to define an individual plugin for each namespace and those configurations can't be re-used... it feels odd that you don't just define them directly in the namespace. |
@peterbroadhurst yea I think it's mostly terminology here. From a configuration perspective, you can reuse a plugin configuration in many namespaces. From an internal instantiation perspective, there may actually be a separate plugin instance+event loop created for every one of those namespaces. |
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
This is already covered by tracking of the current subscription ID, which will filter out events from unrecognized/old subscriptions. Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
|
||
chaincode := termination.Info.GetString("chaincodeId") | ||
f.fireflyMux.Lock() | ||
if chaincode != f.fireflyChaincode { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an observation about us having added quite a bit of extra code duplication of logic here. At some point it feels like we need a base plugin/framework for the common code between ethereum
and fabric
. However, I have no objection to this going in as is - as I'm expecting you were thinking about this duplication as you went through, and how interleaved the logic is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, my gut said it wouldn't improve overall readability to factor out utilities, because so many little details are just slightly different ("address" vs "chaincodeId", for instance). It's probably an exercise worth doing at some point just to see what's possible, but I've punted (again) for now.
if f.contractConfSize > 0 || contractIndex > 0 { | ||
// New config (array of objects under "fireflyContract") | ||
if contractIndex >= f.contractConfSize { | ||
return "", "", i18n.NewError(ctx, coremsgs.MsgInvalidFireFlyContractIndex, fmt.Sprintf("blockchain.fabric.fireflyContract[%d]", contractIndex)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth talking to @jimthematrix about the Fabric side of this, and whether in practice we use this feature you've added for jumping chaincode names, vs. just upgrading the Fabric chaincode in-place. Not a blocker to this merging, but something to think about in the next step when developing the v.next contract code, and testing this journey end to end with a Fabric environment.
db/migrations/postgres/000090_add_namespace_contractindex.up.sql
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking great @awrichar - a couple of (hopefully small) changes requested before we merge, along with a bunch of additional musings.
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
Signed-off-by: Andrew Richardson <andrew.richardson@kaleido.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 - really pleased this all worked through, and we have an upgrade path in place to adopt the new per-namespace contracts.
In a chain with #821.Depends on hyperledger/firefly-common#8 being merged and integrated here.Summary of changes:
fireflyContract
key.New config example (for Ethereum):
This means deprecation of the previous keys
ethconnect.instance
andfabconnect.chaincode
.fireflyContract
field added to namespaces.Records the config index and address of the active contract, as well as the final event for all previously-terminated contracts. New namespace example:
Currently there is only one globally active FireFly contract, and its info is recorded against the "ff_system" namespace. In a future PR as part of hyperledger/firefly-fir#12, each namespace will have its own blockchain plugin and therefore its own contract.
/network/operatoraction
API, with a single supported action type ofterminate
.Sends a specially formatted "BatchPin" transaction to signal that all members should terminate listening to the current FireFly contract and migrate to the next one configured.
Note that this is all separate from migrating the "network rules" of a namespace (which is also in scope for FIR-12). This first step just allows migrating from one contract to another. In a future PR we can introduce the capability for a new contract to expose a "network version", so that a contract migration may also cause a rules migration (such as changing the signature of BatchPin or the rules for resolving identities).