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

refactor: P2P client interface #1924

Merged
merged 37 commits into from
Oct 16, 2023

Conversation

nasdf
Copy link
Member

@nasdf nasdf commented Oct 3, 2023

Relevant issue(s)

Resolves #1883

Description

Blocked by #1927

This PR moves the client.P2P implementation from client.DB to net.Node. This fixes the problems mentioned in the issue above and should increase test coverage of the HTTP and CLI clients.

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

make test

Specify the platform(s) on which this was tested:

  • MacOS

@nasdf nasdf self-assigned this Oct 3, 2023
@nasdf nasdf added area/api Related to the external API component refactor This issue specific to or requires *notable* refactoring of existing codebases and components area/p2p Related to the p2p networking system labels Oct 3, 2023
@nasdf nasdf added this to the DefraDB v0.8 milestone Oct 3, 2023
@codecov
Copy link

codecov bot commented Oct 4, 2023

Codecov Report

Attention: 225 lines in your changes are missing coverage. Please review.

Comparison is base (5c1b21e) 74.77% compared to head (580f016) 74.24%.

❗ Current head 580f016 differs from pull request most recent head 40b2603. Consider uploading reports for the commit 40b2603 to get more accurate results

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1924      +/-   ##
===========================================
- Coverage    74.77%   74.24%   -0.53%     
===========================================
  Files          240      236       -4     
  Lines        23644    22879     -765     
===========================================
- Hits         17678    16985     -693     
+ Misses        4759     4738      -21     
+ Partials      1207     1156      -51     
Flag Coverage Δ
all-tests 74.24% <59.96%> (-0.53%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Coverage Δ
cli/p2p_collection_add.go 100.00% <100.00%> (ø)
cli/p2p_collection_getall.go 81.25% <100.00%> (ø)
cli/p2p_collection_remove.go 100.00% <100.00%> (ø)
cli/p2p_info.go 100.00% <100.00%> (+57.14%) ⬆️
cli/utils.go 44.29% <100.00%> (+1.64%) ⬆️
config/config.go 73.47% <100.00%> (+0.06%) ⬆️
db/db.go 74.10% <100.00%> (+11.69%) ⬆️
db/txn_db.go 55.35% <ø> (-2.55%) ⬇️
http/errors.go 66.67% <ø> (ø)
http/handler.go 96.84% <100.00%> (+0.03%) ⬆️
... and 15 more

... and 49 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5c1b21e...40b2603. Read the comment docs.

@nasdf nasdf marked this pull request as ready for review October 4, 2023 19:11
@nasdf nasdf requested a review from a team October 4, 2023 19:11
@AndrewSisley
Copy link
Contributor

remove GRPC API

I really really think that such a change deserves its own PR.

@nasdf
Copy link
Member Author

nasdf commented Oct 4, 2023

remove GRPC API

I really really think that such a change deserves its own PR.

It's not used in the current develop branch. I had deprecated it when refactoring the CLI and forgot to remove it.

I'm happy to pull those changes into a new PR if you'd prefer.

Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

I have a fairly major todo RE transactionality, I'll resume review once that conversation is resolved.

config/config.go Outdated
@@ -350,79 +349,38 @@ func (apicfg *APIConfig) AddressToURL() string {

// NetConfig configures aspects of network and peer-to-peer.
type NetConfig struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

praise: Nice 😁 Glad this is simpler now

var cmd = &cobra.Command{
Use: "delete <peer>",
Use: "delete [-c, --collection] <peer>",
Short: "Delete a replicator. It will stop synchronizing",
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Should this (and Long), not now read Delete replicators...? It looks like it can now delete multiple.

Copy link
Member Author

Choose a reason for hiding this comment

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

If you are referring to deleting multiple collections replicated to a single peer you are correct.

Copy link
Contributor

Choose a reason for hiding this comment

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

todo: Please change the short/long wording to reflect this :)

type P2P interface {
DB
Copy link
Contributor

Choose a reason for hiding this comment

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

todo: It took me a while to figure it out, but you have removed functionality here. client.P2P used to respect the transactionality of client.Store, but now it only works with implicit transactions.

I'm not sure we wish to lose this, and this change should be made very visible and open to discussion with the team.

Copy link
Member Author

Choose a reason for hiding this comment

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

I discussed this with @fredcarle and forgot to make a note. We came to the conclusion that peer operations only make sense when done implicitly. It would be pretty difficult to have the transaction also rollback the peer connections that happen during these operations.

Copy link
Collaborator

Choose a reason for hiding this comment

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

We are not losing functionality. We are removing the need for the Store interface to support P2P related actions. The functionality still exists but is handled all within the net package. However, whatever implements the P2P interface needs access to a db instance and thus support the DB interface. Action related to the P2P interface can still use transactions.

Copy link
Contributor

Choose a reason for hiding this comment

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

We came to the conclusion that peer operations only make sense when done implicitly.

I do disagree with this, with the obvious example being during an update to a new application version - there may be several of these operations (plus other stuff, like schema updates etc) and if any one of those operations fails, they should all fail so that the update is not partially applied.

I will not push back against the both of you on this, but I do think explicit transactions here are useful.

Copy link
Contributor

Choose a reason for hiding this comment

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

Fred and I spoke about this last week, currently (in develop), the P2P interface only looks like it supports explicit transactions - it doesn't actually respect them. This PR fixes this by making the interface reflect what is actually supported.

I'm happy with the change, it is better than what was before :)

@AndrewSisley
Copy link
Contributor

I'm happy to pull those changes into a new PR if you'd prefer.

I would prefer it, it is a big change, and should be in the commit history. It also clutters up this PR a fair amount making review harder.

@nasdf
Copy link
Member Author

nasdf commented Oct 4, 2023

I'm happy to pull those changes into a new PR if you'd prefer.

I would prefer it, it is a big change, and should be in the commit history. It also clutters up this PR a fair amount making review harder.

I'm working on this now and will update with a link when ready.

Update: added link to PR in description.

@nasdf nasdf requested a review from a team October 12, 2023 17:19
Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

Looks good, but I still have some small questions.

var cmd = &cobra.Command{
Use: "delete <peer>",
Use: "delete [-c, --collection] <peer>",
Short: "Delete a replicator. It will stop synchronizing",
Copy link
Contributor

Choose a reason for hiding this comment

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

todo: Please change the short/long wording to reflect this :)

@@ -244,57 +244,73 @@ When starting a node for the first time, a key pair is generated and stored in i

Each node has a unique `PeerID` generated from its public key. This ID allows other nodes to connect to it.

To view your node's peer info:
Copy link
Contributor

Choose a reason for hiding this comment

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

praise: Thank you for adding this!

README.md Outdated
Set *nodeA* to actively replicate the Article collection to *nodeB*:

```shell
defradb client p2p replicator set -c Article <peer_info_of_nodeB>
Copy link
Contributor

Choose a reason for hiding this comment

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

suggestion: I had to check the help text of defradb client p2p replicator set to be sure that <peer_info_of_nodeB> meant the full json object - it might be worth renaming this to reflect that.

Copy link
Member Author

Choose a reason for hiding this comment

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

I updated it to nodeB_peer_info_json to hopefully make it more obvious.

func (db *db) Close(ctx context.Context) {
log.Info(ctx, "Closing DefraDB process...")
func (db *db) Close() {
log.Info(context.Background(), "Closing DefraDB process...")
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Was this what prompted the attempted removal of the ctx from the log interface?

thought: This does feel incorrect, as context has been defined outside of this function, and whilst at the moment as far as I can see they are all untouched context.Background()s, the context is not owned by this function, and could be modified by those owning layers, at which point this function would become not just conceptually incorrect, but tangibly so too. It might be worth chatting about this - whilst a minor/unimportant part of the codebase, this kind of feels like a drop in standards and as such I was temped to mark this as a todo.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah this was the exact area where I ran into the log context. I plan on cleaning this up in the future when switching to the new log/slog go package.

Copy link
Contributor

@AndrewSisley AndrewSisley Oct 13, 2023

Choose a reason for hiding this comment

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

Okay, I'm happy enough then if it is left as-is in the short term then if others are :)

return peer.AddrInfo{}
}
var info peer.AddrInfo
if err := json.Unmarshal(data, &info); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

question: Here, and in the if above, we are ignoring the error. Other functions in this wrapper seem to return their errors. How confident are you on the safety of this? Could it not lead to the tests missing panics and errors that because of this only appear in the logs?

Copy link
Member Author

Choose a reason for hiding this comment

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

I could change the API signature to return an error here. My thought process was that an empty peer.AddrInfo struct represents an error and any function using that empty address should return an error.

Copy link
Contributor

Choose a reason for hiding this comment

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

It feels a bit wrong to change the production interface for the sake of a test wrapper (even if just to add an error return param). Maybe we could just panic here for now (instead of returning empty)?

@@ -0,0 +1,256 @@
// Copyright 2023 Democratized Data Foundation
Copy link
Contributor

Choose a reason for hiding this comment

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

praise: I like that this is being broken out of the main (and large) utils2.go file

suggestion: I think it might be worth splitting it up again, I do dislike 'setup' files in general, as they often reduce the cohesion of the codebase, moving stuff away from where it is used. However here we only really have two things, and they are independent. We could split this file up into clients.go and db.go (or similar names), this would keep the database stuff together, and the client stuff together, both out of the main utils.go, and avoid us creating a general purpose, lets shove everything in it, setup file that risks growing horribly in the future if/when we add more stuff that requires setup.

There is also an argument to be had that 'setup' here is misleading (particularly considering the large init func at the top of the file), as it doesn't actually setup up the database or clients, it hosts the functions that the utils2.go calls to set them up.

Copy link
Member Author

Choose a reason for hiding this comment

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

I like that idea. I split them into db.go and client.go and put the init back into utils2.go

Copy link
Contributor

@AndrewSisley AndrewSisley Oct 13, 2023

Choose a reason for hiding this comment

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

I think you forgot to add+push the new files :)

and put the init back into utils2.go

Why did you chose to return the init? I did picture that, and the declarations, being split up too (execution order didn't look like it mattered here).

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay I see what you mean. I split the init logic but left the mutation variables in utils since they are not db or client specific.

nasdf and others added 8 commits October 13, 2023 12:50
commit c8bde64
Author: Islam Aliev <[email protected]>
Date:   Sat Oct 14 00:26:22 2023 +0200

    feat: Make queries utilise secondary indexes (sourcenetwork#1925)

    ## Relevant issue(s)

    Resolves sourcenetwork#1555

    ## Description

    With this change the the secondary indexes are utilised during querying
    data.

    A dedicated `Indexer` fetcher is implemented to perform fetching of
    values of indexed fields.

    Now there is a separate `filter` package that houses a lot of methods
    for working with filters.

    A new metric `indexesFetched` is introduced into `@explain` to provide
    information about how many indexes has been fetched.

    It also includes an update to the testing framework to allow adding
    custom asserters.
    The new ExplainResultsAsserter is used with this new feature.
Copy link
Contributor

@AndrewSisley AndrewSisley left a comment

Choose a reason for hiding this comment

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

LGTM, thanks Keenan :)

@nasdf nasdf merged commit 25d4767 into sourcenetwork:develop Oct 16, 2023
26 checks passed
shahzadlone pushed a commit to shahzadlone/defradb that referenced this pull request Feb 23, 2024
## Relevant issue(s)

Resolves sourcenetwork#1883 

## Description

Blocked by sourcenetwork#1927 

This PR moves the `client.P2P` implementation from `client.DB` to
`net.Node`. This fixes the problems mentioned in the issue above and
should increase test coverage of the HTTP and CLI clients.

## Tasks

- [x] I made sure the code is well commented, particularly
hard-to-understand areas.
- [x] I made sure the repository-held documentation is changed
accordingly.
- [x] I made sure the pull request title adheres to the conventional
commit style (the subset used in the project can be found in
[tools/configs/chglog/config.yml](tools/configs/chglog/config.yml)).
- [x] I made sure to discuss its limitations such as threats to
validity, vulnerability to mistake and misuse, robustness to
invalidation of assumptions, resource requirements, ...

## How has this been tested?

`make test`

Specify the platform(s) on which this was tested:
- MacOS
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Related to the external API component area/p2p Related to the p2p networking system refactor This issue specific to or requires *notable* refactoring of existing codebases and components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

P2P database functions not calling peer logic
3 participants