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

Addition of AWS S3 uploader #1276

Merged
merged 5 commits into from Oct 1, 2021
Merged

Conversation

martingallagher
Copy link
Contributor

No description provided.

Copy link
Contributor

@synzhu synzhu left a comment

Choose a reason for hiding this comment

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

Overall looks good! However, can we add some tests for the new uploader?

Another suggestion I have (which doesn't necessarily need to be addressed in this PR but perhaps in a future one @m4ksio), is that we should probably modify Upload() method to take in a context, instead of passing a context into the constructors of the uploaders as is done in this PR as well as the existing implementation.

As I've mentioned in various other places before, storing a context inside a struct is an antipattern which is specifically advised against by the developers of Go. Here is an example illustrating some of the problems it can cause.

Furthermore, passing a context to Upload() allows the caller to cancel the upload, which enables things like timeouts. Currently, the code in Manager.ComputeBlock may block indefinitely while waiting for the upload to complete, which is definitely not something we want. (AsyncUploader mitigates this, but at the expense of reduced control over error handling).

Comment on lines 231 to 233
if err != nil {
return nil, fmt.Errorf("failed to upload block result: %w", err)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: may be useful to output information on which specific uploader failed here. Using errgroup obfuscates this information, so I'd suggest maybe not using it and instead manually implementing some logic to capture each individual error from each uploader and creating a multierror out of them.

@m4ksio
Copy link
Contributor

m4ksio commented Sep 15, 2021

Another suggestion I have (which doesn't necessarily need to be addressed in this PR but perhaps in a future one @m4ksio), is that we should probably modify Upload() method to take in a context, instead of passing a context into the constructors of the uploaders as is done in this PR as well as the existing implementation.

As I've mentioned in various other places before, storing a context inside a struct is an antipattern which is specifically advised against by the developers of Go. Here is an example illustrating some of the problems it can cause.

Furthermore, passing a context to Upload() allows the caller to cancel the upload, which enables things like timeouts. Currently, the code in Manager.ComputeBlock may block indefinitely while waiting for the upload to complete, which is definitely not something we want. (AsyncUploader mitigates this, but at the expense of reduced control over error handling).

We explicitly don't want to pass context around, we decided to go with ReadyDoneAware model with own lifecycle. In this specific example we don't want ComputeBlock to manage lifecycle of uploads. That's other module problem, so to speak.
We want block upload to be as unobtrusive as possible, this would create unnecessary coupling. Maybe we should make it clear that uploader is rather expected to be seen as separate queue, not the direct uploading mechanism

Anyway, as you noted, this PR isn't the best place for this discussion.

cmd/execution/main.go Outdated Show resolved Hide resolved
@@ -199,7 +202,7 @@ func main() {
collector,
)

blockDataUploader = asyncUploader
blockDataUploaders = append(blockDataUploaders, asyncUploader)
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if maybe instead of slice of uploaders we should create a new uploader which calls multiple ones - MultiUploader of sort.

@huitseeker huitseeker marked this pull request as ready for review September 27, 2021 19:59
Copy link
Contributor

@huitseeker huitseeker left a comment

Choose a reason for hiding this comment

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

I'm OK with the tests of the Async block uploader as they stand. LGTM!

@codecov-commenter
Copy link

codecov-commenter commented Sep 29, 2021

Codecov Report

Merging #1276 (f8b2410) into master (28a6922) will increase coverage by 0.05%.
The diff coverage is 48.67%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1276      +/-   ##
==========================================
+ Coverage   56.25%   56.31%   +0.05%     
==========================================
  Files         500      503       +3     
  Lines       31162    31230      +68     
==========================================
+ Hits        17531    17587      +56     
- Misses      11262    11271       +9     
- Partials     2369     2372       +3     
Flag Coverage Δ
unittests 56.31% <48.67%> (+0.05%) ⬆️

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

Impacted Files Coverage Δ
consensus/config.go 0.00% <0.00%> (ø)
consensus/participant.go 15.95% <0.00%> (ø)
...gine/execution/computation/computer/uploader/s3.go 0.00% <0.00%> (ø)
model/flow/role.go 89.36% <ø> (ø)
network/p2p/middleware.go 0.00% <0.00%> (ø)
network/test/testUtil.go 94.90% <ø> (ø)
network/topology/helper.go 82.35% <ø> (-1.86%) ⬇️
network/p2p/libp2pNode.go 65.45% <30.76%> (-1.11%) ⬇️
network/p2p/subscription_filter.go 47.82% <47.82%> (ø)
network/topology/randomizedTopology.go 66.07% <50.00%> (ø)
... and 13 more

Continue to review full report at Codecov.

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

@huitseeker
Copy link
Contributor

bors merge

@bors
Copy link
Contributor

bors bot commented Oct 1, 2021

@bors bors bot merged commit db86bf5 into onflow:master Oct 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants