Skip to content
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 upgrades with different binary hashes #3579

Closed
ptrus opened this issue Dec 17, 2020 · 1 comment · Fixed by #3610
Closed

Support upgrades with different binary hashes #3579

ptrus opened this issue Dec 17, 2020 · 1 comment · Fixed by #3610
Assignees
Labels
c:breaking/consensus Category: breaking consensus changes

Comments

@ptrus
Copy link
Member

ptrus commented Dec 17, 2020

Currently the upgrade module supports a single upgrade type ("internal") which relies on binary hash to ensure correct node version for upgrade is used:

// Identifier is a hash of the binary to be used for upgrading.
// Upgrade methods other than "internal" may have differently formatted identifiers.
Identifier string `json:"identifier"`

We should stop using the hash of the binary to ensure correct version is running and instead use something like a software version. Otherwise upgrade will be hard to coordinate with people doing custom builds.

Can either create a new upgrade type or update (and rename?) the existing "internal" upgrade type to not rely on exact matching binaries - as that doesn't seem all that useful.

Should do after #3536 is merged, as that PR contains some significant changes to the upgrade module.

Also enforce unique upgrade descriptor names.

@ptrus ptrus added the c:breaking/consensus Category: breaking consensus changes label Dec 17, 2020
@kostko
Copy link
Member

kostko commented Dec 17, 2020

Can either update a new upgrade type or update (and rename?) the existing "internal" upgrade type to not rely on exact matching binaries - as that doesn't seem all that useful.

I would opt for reusing/renaming the existing upgrade type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c:breaking/consensus Category: breaking consensus changes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants