Plan for removing the sovrin token. #28
Conversation
Signed-off-by: Richard Esplin <[email protected]>
Signed-off-by: Richard Esplin <[email protected]>
esplinr
changed the title
Signed-off-by: Richard Esplin <[email protected]>
|
For reviewers: a convenient link to the PR for the Indy HIPEs that are linked in the SIP. |
Three more recently discovered concerns. Signed-off-by: Richard Esplin <[email protected]>
| * It has only been tested on Ubuntu 16.04, which will reach end-of-life in March 2021. The plugin could break while upgrading the Sovrin Networks to newer versions of Ubuntu. | ||
| * It has only been tested on Python 3.5, which reached end-of-life in September 2020. The rest of Indy has been difficult to upgrade, so it is unlikely the token plugin will work. | ||
| * It depends on the deprecated [Indy Crypto](https://github.com/hyperledger/indy-node), the predecessor to [Hyperledger Ursa](https://github.com/hyperledger/ursa). Indy Crypto has not received security updates or other improvements since October 2019. Because the rest of Indy uses Ursa, there is an additional risk of a dependency conflict. | ||
| * It’s build process depends on the Sovrin deployment of Jenkins for CI / CD, which has not been maintained since early 2020. It is likely that the unit tests and system tests won’t run. |
There was a problem hiding this comment.
The Jenkins CI/CD process(es) runs the tests in containerized environments. If the test run on a developer's machine, they will run on the equivalent containerized environment during the build process.
There was a problem hiding this comment.
I have no confidence that the tests will run on a developer's machine.
There was a problem hiding this comment.
Current test failures are due in whole to dependency issues, details provided in the RC channels. Once those are addressed the tests will function in the containerized environments under Jenkins, or on a developers machine.
| * It has only been tested on Python 3.5, which reached end-of-life in September 2020. The rest of Indy has been difficult to upgrade, so it is unlikely the token plugin will work. | ||
| * It depends on the deprecated [Indy Crypto](https://github.com/hyperledger/indy-node), the predecessor to [Hyperledger Ursa](https://github.com/hyperledger/ursa). Indy Crypto has not received security updates or other improvements since October 2019. Because the rest of Indy uses Ursa, there is an additional risk of a dependency conflict. | ||
| * It’s build process depends on the Sovrin deployment of Jenkins for CI / CD, which has not been maintained since early 2020. It is likely that the unit tests and system tests won’t run. | ||
| * It's testing process depends on [Indy SDK](https://github.com/hyperledger/indy-sdk/), which [has an uncertain future](https://github.com/hyperledger/indy-sdk/pull/2329) as development is focused on [Indy-VDR](https://github.com/hyperledger/indy-vdr/). |
There was a problem hiding this comment.
indy-sdk 1.16.0 was built 2021.02.21, moving forward, testing would need to migrate to the tools adopted by the community. This would be the same for indy-node.
There was a problem hiding this comment.
Agreed. But we have volunteers to do that work for indy-node, and no one to do that work for the token.
|
Without the plugin (once the ledger has been frozen and the plugin removed) how can the ledger history be validated when there have been transactions processed by it? |
|
Wade asks:
The SIP explains:
This policy is based on the Sovrin Steward Technical and Organizational Policies v2:
But per @WadeBarnes 's suggestion, I made it more explicit here:
Edit from @WadeBarnes: |
Signed-off-by: Richard Esplin <[email protected]>
I don't see how that is relevant to this SIP. Operation of the network is unaffected either way. We put in the extra effort to cleanly remove the data by dropping the ledger, because we want to leave the network in the best state for long term maintenance.
But it doesn't really matter either way. |
No description provided.