Make vm_id assignment more robust #714
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #714 +/- ##
==========================================
+ Coverage 62.59% 62.64% +0.05%
==========================================
Files 69 69
Lines 6138 6131 -7
Branches 491 490 -1
==========================================
- Hits 3842 3841 -1
+ Misses 2152 2146 -6
Partials 144 144 ☔ View full report in Codecov by Sentry. |
Remove the counter way to assign a vm_id as it didn't work reliably Jira ticket: ALEPH-272 That method was broken when persitent instances were loaded at start up. Since the "new" feature that allow persistent instance across aleph-vm reboot if one was started then aleph-vm was stopped and restarted the counter method could reassign the ip and break the existing vm's. Secundary reason was that the feature wasn't working properly with the default settings, as `2**available_bits` returned 1. So that code path was only used if the node owner tweaked some undocumented settings making it hard to identify and debug in prod nodes.
olethanh
force-pushed
the
ol-272-make-ip-adress-assignment-more-robust
branch
from
0aca695 to
0da82f2
Compare
Psycojoker
approved these changes
Oct 29, 2024
nesitor
approved these changes
Oct 31, 2024
Antonyjin
pushed a commit
that referenced
this pull request
Nov 19, 2024
Remove the counter way to assign a vm_id as it didn't work reliably Jira ticket: ALEPH-272 That method was broken when persitent instances were loaded at start up. Since the "new" feature that allow persistent instance across aleph-vm reboot if one was started then aleph-vm was stopped and restarted the counter method could reassign the ip and break the existing vm's. Secundary reason was that the feature wasn't working properly with the default settings, as `2**available_bits` returned 1. So that code path was only used if the node owner tweaked some undocumented settings making it hard to identify and debug in prod nodes.
Antonyjin
pushed a commit
that referenced
this pull request
Nov 19, 2024
Remove the counter way to assign a vm_id as it didn't work reliably Jira ticket: ALEPH-272 That method was broken when persitent instances were loaded at start up. Since the "new" feature that allow persistent instance across aleph-vm reboot if one was started then aleph-vm was stopped and restarted the counter method could reassign the ip and break the existing vm's. Secundary reason was that the feature wasn't working properly with the default settings, as `2**available_bits` returned 1. So that code path was only used if the node owner tweaked some undocumented settings making it hard to identify and debug in prod nodes.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Remove the counter way to assign a vm_id as it didn't work reliably
Jira ticket: ALEPH-272
That method was broken when persistent instances were loaded at start up. Since the "new" feature that allow persistent instance across aleph-vm reboot if one was started then aleph-vm was stopped and restarted the counter method could reassign the ip and break the existing vm's.
Secundary reason was that the feature wasn't working properly with the default settings, as
2**available_bitsreturned 1. So that code path was only used if the node owner tweaked some undocumented settings making it hard to identify and debug in prod nodes.Self proofreading checklist