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

February 1 - configuration parameters for node operators running 3.2 and beyond #114

Open
Tracked by #37
chillsauce opened this issue Feb 1, 2023 · 2 comments
Open
Tracked by #37

Comments

@chillsauce
Copy link
Member

chillsauce commented Feb 1, 2023

Antelope Node Operator Roundtable

Antelope Node Operators, community members and Antelope core developers meet every Wednesday at 14:00 UTC to discuss opportunities to improve the Antelope protocol for node operators.

💬 Join us in Telegram
🗂 See all meeting summaries

🗓 February 1 - 14:00 UTC

🎥 Watch the recording
Passcode: d5=N6S^X

Summary

🟢 Leap Software Status

  • DUNE v1.1.0 has been released
  • Ubuntu 18.04 support will be removed in advance of Leap 4.0.0 (targeted for March release)
    • Leap 4.0 will not be a consensus upgrade, so node operators running Ubuntu Linux 18.04 don't need to upgrade immediately
    • Leap will officially continue to support Ubuntu 22.04 and 20.04

Technical roundtable for Antelope Node Operators

  • Matthew presented an issue that came up due to some changes made in Leap 3.2 that can cause issues for node operators who don't update their configuration.
    • Documentation for Leap 3.2 will be improved to address these changes
    • Node operators who are upgrading to 3.2 should increase max HTTP response time to be equal to or greater than your max serialization time.
    • More detailed notes will follow.

Next week's topic: Nodes that are dedicated to a specific purpose

- Aaron: Read-only nodeos instances
    - On Steem there was a flag you could set when launching a node so that it would be read-only
    - Read-only to the state
    - Prevents syncing and push transactions
    - The read only nodeos instance would read from the state file of another nodeos instance
    - Greymass has servers that run many nodes instances and each needs it’s own state file
    - This would alleviate pressure off of nodes that are syncing/writing
    - More radical alternatives
        - Could the state itself be streamed into some other solution? DFuse, The Graph
    - Matthew and Thiago adds me too
- Matthew: Relay only nodes don’t need any state
    - We’ve discussed this idea some before
    - Would allow for more efficient block propagation
    - Kevin: Relevant PRs
        - [Propagate block after header validation #590](https://github.com/AntelopeIO/leap/pull/590)
        - [Parallelize Read-only Transaction Execution Design Document #130](https://github.com/eosnetworkfoundation/product/pull/130/files)

Participants (20)

  • Virginia Glass
  • Kevin Heifner
  • Denis 🚀
  • Max_Cho :: KOREOS Owner-South Korea
  • Stephen Diesel
  • Matthew Darwin
  • Daniel Keyes | EOS Nation
  • '@I_Seth |Boid|Animus BlockBase
  • Patrick | Aloha EOS (Patrick)
  • Ted Cahall
  • [email protected]
  • EOSUSA Michael
  • Aaron Cox
  • J.P. | Detroit Ledger Tech
  • Tony Licavoli
  • MachnBird Sparo
  • Brian Hazzard
  • junhank | NodeONE
  • J.P. | Detroit Ledger Tech
  • Dario | EOSsupport.io
@stephenpdeos
Copy link

@chillsauce one correction: Ubuntu 18.04 support will be removed in advance of 4.0.0 vs deprecated in release.

@chillsauce
Copy link
Member Author

@chillsauce one correction: Ubuntu 18.04 support will be removed in advance of 4.0.0 vs deprecated in release.

Thanks for clarifying. I've updated the notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants