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

Support local=true as a configurable option for the proxy endpoints (:9095) #1292

Closed
rryter opened this issue Jan 15, 2021 · 2 comments
Closed
Labels
effort/hours Estimated to take one or several hours exp/novice Someone with a little familiarity can pick up good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up

Comments

@rryter
Copy link

rryter commented Jan 15, 2021

Hello 😄

As per discussion, the rest api /add endpoint (:9094) supports the setting local=true.

This will just add on the node receiving the request (and not all nodes at the same time), and cluster-pin when finished. The rest of the nodes will copy the content via pubsub, much faster.

We would like to run a public IPFS-Cluster and therefore plan to allow users to use the IPFS-Proxy API (:9095).

It would be awesome if the setting "local=true" would be a configurable option.
I assume the default would be local=false but we could set it to true for our cluster.

Does that make sense?

I'm new to IPFS / IPFS-Cluster so I don't know if this would be applicable to other enpoints too?

👋

@rryter rryter added the need/triage Needs initial labeling and prioritization label Jan 15, 2021
@hsanjuan hsanjuan added exp/novice Someone with a little familiarity can pick up effort/hours Estimated to take one or several hours good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked and removed need/triage Needs initial labeling and prioritization labels Jan 15, 2021
@hsanjuan hsanjuan assigned ghost Feb 4, 2021
@hsanjuan hsanjuan added status/in-progress In progress and removed status/ready Ready to be worked labels Feb 4, 2021
@hsanjuan
Copy link
Collaborator

hsanjuan commented Feb 4, 2021

hi @sergeiudris , go ahead! thanks!

@hsanjuan hsanjuan removed the status/in-progress In progress label Feb 9, 2021
@hsanjuan
Copy link
Collaborator

hsanjuan commented Feb 9, 2021

oh, it's true... it's done already because the code path is the same.

creates BlockAdder with empty dests ( []peer.ID{""} )

No, dests are not empty. It has 1 dest, which is "". This is the local peer. The BlockPut rpc calls get executed in the same peer (bypassing the rpc request/response - this is in go-libp2p-gorpc).

In the end adding "locally" is the equivalent of adding with 1 destination. I think the codepaths there are hopefully well-tested (and tried).

Thanks a lot for looking into this, though. Probably best to spend time on some of the other open issues. I'm very sorry that I did not realize this was there already.

@hsanjuan hsanjuan closed this as completed Feb 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/hours Estimated to take one or several hours exp/novice Someone with a little familiarity can pick up good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature P1 High: Likely tackled by core team if no one steps up
Projects
None yet
Development

No branches or pull requests

2 participants