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

feat: mine new overlay #4685

Merged
merged 13 commits into from
Jul 9, 2024
Merged

feat: mine new overlay #4685

merged 13 commits into from
Jul 9, 2024

Conversation

nugaon
Copy link
Member

@nugaon nugaon commented May 20, 2024

Allowing the overlay address mining even when nonce exists. That case, localstore and kademlia-metrics folders will be removed and statestore will be cleared to start a clean state in the new neighborhood. Before the wipe, 10 seconds wait time allows the user to change their mind.

Checklist

  • I have read the coding guide.
  • My change requires a documentation update, and I have done it.
  • I have added tests to cover my changes.
  • I have filled out the description and linked the related issues.

Description

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

Screenshots (if appropriate):

@nugaon nugaon force-pushed the feat/mine-overlay branch from 5e0468f to 8c57a37 Compare May 20, 2024 15:34
@nugaon nugaon changed the title feat: mine overlay feat: mine overlay to new neighborhood May 21, 2024
@nugaon nugaon changed the title feat: mine overlay to new neighborhood feat: mine new overlay May 21, 2024
@nugaon nugaon marked this pull request as ready for review May 27, 2024 13:24
Copy link
Member

@istae istae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in order to achieve overlay change during runtime, i think you have to save the previous target-neighborhood in the statestore and only nuke the dirs (and change the overlay) if the target-neighborhood of the config option is different from the statestore one.

pkg/node/node.go Outdated Show resolved Hide resolved
pkg/node/node.go Outdated Show resolved Hide resolved
pkg/node/node.go Outdated Show resolved Hide resolved
@ldeffenb
Copy link
Collaborator

save the previous target-neighborhood in the statestore

Couldn't you just check the saved overlay (if there is one) to see if it is already in the specified target neighborhood?

@istae
Copy link
Member

istae commented Jun 4, 2024

save the previous target-neighborhood in the statestore

Couldn't you just check the saved overlay (if there is one) to see if it is already in the specified target neighborhood?

You can also do this, yes.

@nugaon
Copy link
Member Author

nugaon commented Jun 6, 2024

Thanks for the comments regarding the missed use-case when user reloads the client with the mining param.

I corrected that and it also sets TargetNeighborhood with NeighborhoodSuggester only if nonce was not defined before.

Copy link
Member

@istae istae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some comments around the code changes would help
also let's post screenshots of the different test cases

@istae istae requested review from acha-bill and martinconic June 6, 2024 20:54
pkg/node/node.go Outdated Show resolved Hide resolved
pkg/node/node.go Show resolved Hide resolved
pkg/node/node.go Outdated
const (
localstore = "localstore"
kademlia = "kademlia-metrics"
statestore = "statestore"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TLDR The cleanest way is instead to remove directories, it would be better for these services to implement its own internal nuke methods (that handle file descriptors and internal storage reinitalizations) and call them here, instead to remove their files.

Statestore directory is removed, but a few lines bellow statestore is passed to the setOverlay function. I would assume that the statestore is no longer reliable after its files are removed. Special attention should be made to ensure when interfering with storage internals outside of the services that manage their state. In this case, statestore must be reinitialised (and passed again to all already initialized services that use statestore) or if possible initilizad after the data on disk is removed. Handling nuke on node startup is different than in a separate nuke cli command as the node continues to run.

Nuking buy removing data directories is a questionable operation as these paths are constructed locally by assumption that they will not change in other places of the code where services that store data in them are initialized. I know that this is a mistake taken from the nuke cli command, but it would be good to make new code better.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, I reinited statestore after the wipe as it is needed to fetch nonce before wipe.

Regarding the nuking, no service uses these databases before this point, all affected DB initializations happen in this function. It should have a separate clearDb method with options for sure if some of the data was required to be kept (please let me know if there is any).
so basically, this is the only place where databases should managed as files, shouldn't it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for fixing it.

The statestore as a general key/value store, is a tricky to clean. I believe that this is a good time to plan something like a consolidation of all keys (or key prefixes) that are stored. It would be good to remove only the required keys.

I would say that it would even better to have a Nuke function on the databases to cleanup internal storage, in this case leveldb and not to worry about the file management. This would require a few more changes, but I believe that would result in more reliable code, not to worry about the files, just databases as abstraction. This can be an improvement later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the statestore actually has a nuke function but it preserves keys related to maintaing the overlay addresses, it may be improved to remove those entries when called upon.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is much better to adapt StateStoreAdapter.Nuke for cleaning. I think that it would be the safer way, and maybe to have the list of preserved prefixes a bit more transparent.

pkg/node/node.go Outdated
time.Sleep(10 * time.Second)

const (
localstore = "localstore"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have seen this constants in some other places to. Shouldn't we move them in some constants file , or maybe in the util package so we are not hardcoding them every time?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, reasonable to make constants for that. I moved localstorage and kademlia path constants to ioutil within utils package.

pkg/node/node.go Outdated Show resolved Hide resolved
@nugaon nugaon force-pushed the feat/mine-overlay branch from c7db1f8 to bd0f590 Compare June 13, 2024 08:01

// DB folders paths from bee datadir
const (
DataPathLocalstore = "localstore"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does not feel right to put these consts here but i don't know a better place

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe swarm.go?

Copy link
Member

@janos janos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you for addressing the comments @nugaon.

@nugaon nugaon force-pushed the feat/mine-overlay branch from 526e629 to 633c1cc Compare July 9, 2024 09:09
@nugaon nugaon force-pushed the feat/mine-overlay branch 2 times, most recently from 52d8c45 to b8bcef0 Compare July 9, 2024 11:13
@nugaon nugaon merged commit 98eb3e0 into master Jul 9, 2024
24 of 26 checks passed
@nugaon nugaon deleted the feat/mine-overlay branch July 9, 2024 11:38
@nugaon nugaon mentioned this pull request Jul 9, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants