2021-01-19 Indy Contributors Call
Summary
Planned:
Status of indy-node CI/CD progress
Status of upcoming indy-sdk release
GitHub Actions for the Indy SDK
Recording from the call: 20210119 Indy Contributors Call Recording
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
|---|
Welcome and Introductions
Attendees
@name (Employer) <email>
Stephen Curran (Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>
Richard Esplin (Evernym) <richard.esplin@evernym.com>
Robin Klemens (DB Systel GmbH) <Robin.Klemens@deutschebahn.com>
@Alexander Jonsson (Laniakea Health) <alex@seropass.me>
Related Calls and Announcements
Release Status and Work Updates
Indy Node
Next release in progress, same content as the last release, but using a revised CI/CD process for at least indy-plenum and indy-node
Indy SDK
Next release in progress, led by @Ian Costanzo
Indy Monitoring - https://github.com/hyperledger/indy-node-monitor
Indy/Aries Shared Libraries - donated to Hyperledger (indy-vdr, indy-shared-rs, aries-askar)
Ursa
Meeting Topics
Indy SDK Release - @Ian Costanzo
RC published and being tested – w00t!! – 1.16, Build 170
No tag yet – it's in the RC branch
Ready for release?
Indy Node Release
Process:
Fix Jenkins so that we have a build to compare with (Evernym)
Setup Github Actions / Azure CI pipeline (Kevin, Wade)
Plenum CI – unblock some of the tests – PR this morning
Node CI portion - complete
Node CD progress - being worked on, working on the tests in Kevin's repo
Plenum CD side – Ian has started to work on that, but not much to report yet.
Issue:
Build containers are used in the flows – currently in Wade or Kevin's personal repo.
How to manage the images and where to put them? Push the images to Hyperledger's Docker Hub, or GitHub Packages. Wade to check on this, leaning to Hub.
Base core CI and images are from Hyperledger and are from 16.04 at this point – which is appropriate for our first goal.
Question is who else is using those. Kevin to check with Ry on that.
Show that a release through Github is the same as through Jenkins
Start releasing from Master instead of Stable (Wade)
Goals (ranked):
Release using CI / CD on GitHub Actions
Update from Ubuntu 16.04 to Ubuntu 18.04 / Ubuntu 20.04
When updating validator nodes, note that there is a bug that prevents catch up from an empty ledger. Must copy data to the new machine then catch-up.
During the upgrade, it's better to have different versions of Ubuntu with same version of Indy Node then run for an extended period of time with different versions of Indy Node.
PR in flight for Ubuntu 18.04 with some debate as to whether it is complete or not. Some suspect that getting that PR completed vs. getting to 20.04 is the same effort.
New branching model to release from Master with tags
Promote Stable to Master, then deprecate Stable
Release work in Master
Using a feature flag to prevent usage of new Rich Schemas transactions.
Switch from Indy Crypto to Ursa
Potential features to assist with removing token from Sovrin networks
Stub unused ledgers from removed plugins
Fees as a Node concept
Potential releases:
CI / CD Change, released from Stable
indy-crypto: use existing artifact
indy-plenum: generate from new GitHub CI / CD
indy-node: generate from new GitHub CI / CD
token-plugin: generate from Jenkins
sovrin-node: generate from Jenkins
ursa-crypto: exclude
Upgraded Ubuntu, release from Stable
indy-crypto: use existing artifact / release from Jenkins / exclude from release (if necessary)
indy-plenum: generate from new GitHub CI / CD
indy-node: generate from new GitHub CI / CD
token-plugin: generate from Jenkins/use existing artifact
sovrin-node: generate from Jenkins
ursa-crypto: excluse from release / use existing artifact (if necessary)
Release without Stable (move what is Master today into a branch)
Same components/sources as previous release
Remove Token, released from Stable (There is not agreement this is desirable now vs. other priorities)
indy-crypto: use existing artifact
indy-plenum: generate from new GitHub CI / CD
indy-node: generate from new GitHub CI / CD
token-plugin: stub or exclude
sovrin-node: generete from Jenkins
ursa-crypto: exclude
Release New Features (merge former Master branch back to Master)
indy-crypto: exclude
indy-plenum: generate from new GitHub CI / CD
indy-node: generate from new GitHub CI / CD
token-plugin: stub or exclude
If necessary, could try to release with existing token-plugin
sovrin-node: maybe new Github CI / CD
ursa-crypto: existing artifacts
GitHub Actions for the Indy SDK – ABSA contribution
Community request – what is needed to replace Jenkins with this
LibIndy and postgres plugin only
Publish binaries for mobile only
Wrappers, plus some additional ones
A new container image based on Alpine with precompiled LibIndy and plugins.
Drop LibVCX, Token, Windows, RedHat, and Ubuntu
People who want this support can contribute on top of this GitHub actions work.
Plan: Fork to ABSA, 2 weeks implementing GHA and then a PR to Indy
Default runners in GHA
But could be done with Hyperledger's Azure Pipelines if necessary.
Doesn't look to be needed, as the Indy Node pool is working fine in GHA.
GHA supports cached containers, so the same Indy Node image can be reused.
Conversation about documenting the new branching model for Indy.
It isn't currently documented.
@Richard Esplin 's understanding of the current plan:
1. Create a branch with everything in Master
2. Revert Master back to the last release from Stable
3. Merge everything from Stable into Master
4. Then merge from the branch that used to be Master back into Master
This will probably happen over multiple releases.
Then going forward, each release will come from Master with a release Tag that could be used to create a branch if needed.
@Stephen Curran 's goal for branching – slightly different from Richard's:
Rename Master to Main
Set Main to be the contents of Stable -- identical to the last release of Indy Node (same for plenum).
Evolve from there, starting with the Ubuntu upgrade.
Only add things from the "old Main" as needed -- e.g. indy-crypto to ursa-crypto.
Anything that was not in Stable as of Aug. 30 would have to be re-added as PR.
Rational for that is that there wasn't too much in that, with the main content being Rich Schema, which is generally considered to be obsolete in the community.
Where should it be documented?
Historically, we have released Indy and Sovrin simultaneously, so the documentation on the current branching model is here:
https://github.com/sovrin-foundation/sovrin/blob/master/docs/release.md
and here:
https://github.com/sovrin-foundation/sovrin/blob/master/docs/acceptance.md
It would be good to move the Indy specific stuff into the Indy repos describing the new branching model (releases from tags in Master).
Traditionally, the stable branch was needed to coordinate builds of Indy and the Sovrin Token. But we expect that to go away quickly. And Indy development has slowed, so Master should be more stable.
Future Calls
Next call:
Future: