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

[Feature Request]: allow external SP selection #378

Open
ze42 opened this issue Oct 11, 2023 · 0 comments
Open

[Feature Request]: allow external SP selection #378

ze42 opened this issue Oct 11, 2023 · 0 comments
Assignees
Labels

Comments

@ze42
Copy link

ze42 commented Oct 11, 2023

What is the problem you're trying to solve?

Sending and spreading data dynamically to different available SP.

From what I’ve seen, singularity schedule deals are made to send a whole source to a single provider, with a scheduled timeframe.

We would like to be able to automatically send to multiple SP, so probably having some external tool do the SP selection.

This could also help pushing deals to multiple SP and have a max replication factor, and instead of having SP pull deals, push some deals to different SP until reaching the proper replication factor.

Describe the workaround you currently have

Current work around: scripting around send-manual rather than using schedule deals.

Describe the feature you'd like

Current ideas:

  • a way to configure a schedule sending-deal, with target not being directly a SP, but an external script / plugin (and maybe some param that could help the script identify which targets to consider - like a SP pool name… anyway, just some param to pass along)
  • When schedule is triggered, and want to send a deal:
    • call the registered plugin with:
      • info about the deal-proposal (CID, client, price, size, duration, verified, keep-unsealed, …)
      • a list of SP not to consider (Those we just tried and failed, and - optionaly - known as already having a pending proposal, or already storing the CID)
    • The script should returns a SP
    • If no SP returned, consider we have no current valid target, and wait for next iteration
    • If a SP is returned, the deal-proposal should be send immediately to that SP (if it fails, a new selection must be made before trying to send the deal again)

Additional context

CIDgravity wants to enable on-line deals at a high success rate, a way for clients to onboard data in real-time.

@ze42 ze42 added feature request Feature Request triage labels Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants