-
Notifications
You must be signed in to change notification settings - Fork 410
feat(registry): add merge_subnets endpoint #11366
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
base: master
Are you sure you want to change the base?
Changes from 8 commits
ef25fc8
76ecda4
d8126dc
4b43061
155414e
42a48c1
7c8fe64
7d6ae68
c189291
6a8dd69
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,13 @@ on the process that this file is part of, see | |
|
|
||
| ## Added | ||
|
|
||
| * Added a new `NnsFunction` variant `MergeSubnets`, which proposes to merge a | ||
| subnet into another subnet: the canister ID ranges of the source subnet are | ||
| merged into the canister ID range set of the destination subnet, so that all | ||
| canisters that used to be hosted by the source subnet are routed to the | ||
| destination subnet. Only the routing table is updated: neither subnet record | ||
|
alin-at-dfinity marked this conversation as resolved.
Outdated
|
||
| is modified and the source subnet is not deleted. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, basically, this migrates all canisters from one subnet to another, right? I don't think that's what "merge" calls to mind, at least, for me it doesn't. I mean, I do not hate the name, so it's probably not worth changing it at this point, but if you are willing to entertain suggestions, how about "migrate all subnet canisters", or "evacuate subnet", or something? This would make it clearer that the two subnets survive; it's just the contents of one are dumped into another.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The word "migrate" is already overloaded to refer to (i) subnet splitting via the registry key I suppose your confusion comes from the fact that the source subnet survives (it must be cleaned up by a separate proposal) so how about
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do as you see fit. Yes, the fact that the source subnet remains afterwards is what makes me think that "merge" is not so apt. When you merge two companies, the employees do not simply move from one to the other. Rather, you are left with just one company. The existing "migrate" operation moves a canister from one subnet to another, right? Isn't that what's going on here, just a different number of canisters? To me, that makes "migrate" an even better choice. I don't see it as conflation; I see it as consistency. There's also my other suggestion, "evacuate", which does not conjure images of the existing thing called "migrate". This more emphasizes that ALL canisters are moved out (but does not mention that they will all go to the same destination), which to me, is not as important as the fact that existing canisters are finding a new home, have an actual DESTINATION, not just left stranded in the middle of the street, as might happen if you evacuate a building due to fire. "migrate" is less chaotic. It implies a planned destination, not just a departure.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Keeping |
||
|
|
||
| ## Changed | ||
|
|
||
| ## Deprecated | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.