-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
add remote pinning policy for mfs #7798
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
couple of minor comments
91f3cc0
to
3928faf
Compare
014cfd3
to
9864c13
Compare
53ec641
to
8315aa7
Compare
1d8ff71
to
07a4939
Compare
fix: replace pre-existing pins for MFS root
This refactors `ipfs config replace` commands to ensure pinning service section does not break WebUI: - allow tweaking Policies via WebUI - return an error if API credentials are modified - restore API credentials if missing from input file - make it impossible to add/remove pinning services via config replace - make it impossble to proble if API.Key is valid (we return error even if API.Key does not change)
I cleaned up Remaining TODO:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taking another look through the main part of this PR, but added some comments on config + API key scrubbing
' | ||
|
||
test_expect_success "'ipfs config replace' injects remote services back" ' | ||
test_expect_code 1 grep -q -E "test_.+_svc" show_config && | ||
test_expect_success "'ipfs config replace' injects Pinning.RemoteServices[*].API.Key back" ' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT about another test to make sure that we can change or add a policy in the config and the keys + endpoints stay the same?
cmd/ipfs/daemon.go
Outdated
pinErr := make(chan error) | ||
err = pinMFSOnChange(daemonConfigPollInterval, cctx, &ipfsPinMFSNode{node}, pinErr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect we can move all of this code into core/node and referenced in the Online group in groups.go. There's no reason we need to treat this much differently then whether to start up the DHT or not.
I'm not sure if this is painful or trivial. If it's painful we can refactor in a separate PR.
pinTime := time.Now().UTC() | ||
for ps := range lsPinCh { | ||
existingRequestID = ps.GetRequestId() | ||
if ps.GetPin().GetCid() == cid && ps.GetStatus() != pinclient.StatusFailed { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
} | ||
|
||
type ipfsPinMFSNode struct { | ||
node *core.IpfsNode |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we move into the constructor code then we may be able to take an interface here instead of the raw IpfsNode
} | ||
|
||
func pinMFSOnChange(configPollInterval time.Duration, cctx pinMFSContext, node pinMFSNode, errCh chan<- error) error { | ||
go func() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This goroutine seems to be the only thing we do. Any reason not to have the function be synchronous and then call go pinMFSOnChange
?
Also, this function seems pretty long/difficult to follow, perhaps we can separate out the timer + state polling logic from the update logic or separate out parts of the update logic. This may also help reduce the number of channels for us to consider at any given point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took it for a spin and works as expected with our reference pinning service implementation at rb-pinning-service-api. 👍
Found some minor issues around edge cases (not blockers, we can fix them in separate PRs/RC, but would be nice to include in this one if possible):
Swallowed errors from pinning service client
I also tested with Pinata and they had a small bug in message format (fix wip), which breaks our client with remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string
error, which makes it retry pin over and over again, which accumulates errors in memory until I exit the process.
Those pending errors are then returned in bulk when one exits the process :
2021-01-28T14:11:16.251+0100 DEBUG remotepinning/mfs pinning loop is awake, 1 remote services
2021-01-28T14:11:16.251+0100 DEBUG remotepinning/mfs pinning considering service pinata-test for mfs pinning
2021-01-28T14:11:16.251+0100 DEBUG remotepinning/mfs pinning MFS root QmebJqoF9hdcmr2XwfHHv6FjQxkWSvjN266E7PPu9aZboP to pinata-test
2021-01-28T14:11:17.489+0100 DEBUG remotepinning/mfs pinning to pinata-test: replacing existing MFS root pin with QmebJqoF9hdcmr2XwfHHv6FjQxkWSvjN266E7PPu9aZboP
^C
Received interrupt signal, shutting down...
(Hit ctrl-c again to force-shutdown the daemon.)
Error: 36 errors occurred:
* remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string
* remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string
* remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string
[...]
Pinata is working on a fix and this should not be a blocker, but I am not sure if silently swallowing this type of errors is a good idea in general.
👉 We should log those error responses via remotepinning/mfs
or remotepinning/client
logger to save a lot of time in debugging.
Bogus error on disabling MFS policy via ipfs config
This is cosmetic, but when I disable MFS policy I get this error (but it gets disabled just fine):
$ ipfs config --json Pinning.RemoteServices.rb-pinning-service.Policies.MFS.Enable true
$ ipfs config --json Pinning.RemoteServices.rb-pinning-service.Policies.MFS.Enable false
Error: failed to get config value: "Pinning.RemoteServices.rb-pinning-service.Policies.MFS key has no attributes"
Fixed the swallowing issue. |
# Conflicts: # core/commands/pin/remotepin.go # go.mod # go.sum
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 💚
config replace
works fine with http://127.0.0.1:5001/webui/ - 💚 logger
remotepinning/mfs
shows errors correctly now (but as debug – I think we should change this, see below)2021-01-28T20:45:07.412+0100 DEBUG remotepinning/mfs pinning MFS root QmdLUV2zPmXpZGyb3ASyxyFwP9fHJZom87KF9Lpr3bCVA9 to pinata-test error (remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string)
- 🤔 If there were pinning issues, I still see the accumulated errors when i interrupt
ipfs daemon
:I believe printing errors in realtime is better (see below)^C Received interrupt signal, shutting down... (Hit ctrl-c again to force-shutdown the daemon.) Error: 5 errors occurred: * remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string * remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string * remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string * remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string * remote pinning service returned http error 400: json: cannot unmarshal object into Go struct field FailureError.error.details of type string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢 RC2
* remote pinning service MFS policy * update go-ipfs-config * hardening secret sanitization in `ipfs config` commands Co-authored-by: Adin Schmahmann <adin.schmahmann@gmail.com> Co-authored-by: Marcin Rataj <lidel@lidel.org>
Needed for #7559 & ipfs/ipfs-gui#91
Needs ipfs/go-ipfs-config#116
Closes #7818