forked from lightningnetwork/lnd
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Multinode #154
Closed
Closed
Multinode #154
Conversation
This file contains 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
Pull reviewers statsStats of the last 30 days for lnd:
|
ellemouton
force-pushed
the
moveGraphDBCode
branch
3 times, most recently
from
November 1, 2024 12:06
8568ef5
to
5ae0c8a
Compare
ellemouton
force-pushed
the
moveGraphDBCode
branch
2 times, most recently
from
November 3, 2024 07:18
3f8a1da
to
a0b23a6
Compare
We'll move these to the new graphdb package later and import them from there.
In preparation for moving the graph related schema structs to the graph package in an upcoming commit, we move these methods to the graph package. The structs we will move make use of these methods but we still import them from channeldb so as to keep the ReadElement and WriteElement helpers working as they do today.
We have the same helpers for writing and reading a wire.Outpoint type defined separately in a couple places. We will want to use these from the graph db package soon though so instead of defining them again there, this commit unifies things and creates a single exported set of helpers. The next commit will make use of these.
Start using the single set of exported write/read functions for wire.Outpoint.
All the structs defined in the `channeldb/models` package are graph related. So once we move all the graph CRUD code to the graph package, it makes sense to have the schema structs there too. So this just moves the `models` package over to `graph/db/models`.
This is a pure refactor commit. It moves over all the graph related CRUD code from `channeldb` to `graph/db`.
We also now use the graph DB's own optional functions. An instance of the graph is currently still passed to the channeldb's `CreateWithBackend` function. This will be removed in a later commit once the two have been completely disjoint.
Our aim is to completely remove the `channeldb.DB`'s direct dependence on the `graphdb.ChannelGraph` pointer. The only place where it still depends on this pointer is in the `(DB).AddrsForNode(..)` method where it queries both the channel DB and the graph db for the known addresses for the node in question and then combines the results. So, to separate these out, we will define an AddrsForNodes interface in this commit which we will later let both the ChannelGraph and channeldb.DB both implement and we will merge these results outside of the channeldb package. All this commit does is to unify the `AddrSource` interface since this has been defined separately in a couple of places.
In this commit, we implement a version of the AddrSource interface which merges the results of a set of AddrSource implementations. This will later be used to merge the results of the channel db and graph db.
ellemouton
force-pushed
the
moveGraphDBCode
branch
3 times, most recently
from
November 3, 2024 09:59
5f726b8
to
b465402
Compare
Before this commit, the `(channeldb.DB).AddrsForNode` method treats the results from the channel db and the graph db slightly differently. It errors out if the channel db is unaware of the node in question but does not error out if the graph is unaware of the node. So this commit changes the logic slightly so that a "node-unknown" error from either backing source is not seen as an error.
Then use both to construct a multiAddrSource AddrSource and use that around the code-base.
Now that the channel.DB no longer uses the ChannelGraph pointer, we can completely remove it as a member of channeldb.DB.
and the same for ChannelStateDB.FetchChannel. Most of the calls to these methods provide a `nil` Tx anyways. The only place that currently provides a non-nil tx is in the `localchans.Manager`. It takes the transaction provided to the `ForAllOutgoingChannels` callback and passes it to it's `updateEdge` method. Note, however, that the `ForAllOutgoingChannels` call is a call to the graph db and the call to `updateEdge` is a call to the `ChannelStateDB`. There is no reason that these two calls need to happen under the same transaction as they are writing to two completely disjoint databases. And so in the effort to completely split untangle the relationship between the two databases, we now dont use the same transaction for these two calls.
So that this fails earlier on if the actual call to UpdateChannelPolicy fails.
Demonstrate CI passes if we persist graph data in a completely separate DB to other channel data.
ellemouton
force-pushed
the
moveGraphDBCode
branch
from
November 3, 2024 10:10
b465402
to
1504b31
Compare
This struct is only used by tests, so move it to a test file.
So that we can stop depending on kvdb.RTx directly.
Let ForEachNodeChannel always take the new graphdb.RTx.
Let FetchLightningNode take the new abstract graphdb.RTx and use this method everwhere.
In this commit, we defined a new `autopilot.GraphSource` interface which describes what the backing graph source for the autopilot agent needs to implement. Various methods that need the direct graph db pointer are moved to test files since these methods are only used in tests to populate the test graph.
Define a new GraphSource interface required by the invoicerpc server and remove its access to the graphdb.ChannelGraph pointer.
Since this will be used to create any read transaction that can be used with other graph read calls (ie, not limited to path finding).
For any method that takes a call-back which takes a read transaction, it makese sense for the method itself to also take an optional read transaction.
Most call-sites of this method have a read transaction available to pass in. Note that this also means that calls to FetchNodeFeatures made from the router are made under the same read transaction as calls to ForEachNodeDirectedChannel which makes things cleaner.
When set, LND will not advertise the gossip queries feature bit and it will not initiate gossip syncing with any peer.
This is an interface that the LND can provide to other callers systems in the same process.
ellemouton
force-pushed
the
moveGraphDBCode
branch
6 times, most recently
from
November 8, 2024 09:23
a066df1
to
e017ccf
Compare
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.
No description provided.