This repository has been archived by the owner on Mar 9, 2023. It is now read-only.
Feature Request: Enable indexers to be able to keep one allocation open at all times to serve queries whilst manually closing #273
Labels
The default setup is to have 2 parallel allocations so that when queries are closed automatically the system will keep one allocation open at all times so queries can still be served. However, if an Indexer wishes to manually close their allocations they are not able to do so without disrupting their ability to serve queries.
There are two broad ways to tackle this problem and it may be sensible to implement both:
1) Provide fine-grained control of individual allocations.
Each allocation for a subgraph could be assigned an identifier, eg. A,B,C etc.
Running the
indexer status
command could return the identifier for each allocation that is open, the amount and the Epoch it was opened.To close a specific allocation users could pass the identifier as an argument to a closing command eg.
indexer allocation close --subid QmRhYzT8HEZ9LziQhP6JfNfd4co9A7muUYQhPMJsMUojSF --allocid A ........
It should also be possible for Indexers to specify the identifier they want whenever they open a new allocation (though it should default to the next unused idenitifier if none is provided).
2) Provide automation of some common Indexer procedures.
One of the most common procedures is for an Indexer to rebalance their allocations periodically.
An optimal procedure with 2 parallel allocations is for a single allocation on each Subgraph to be closed, then a new single allocation opened on every desired Subgraph (the new Subgraphs do not need to be the same as the original ones). When this has been successfully completed, the original remaining allocations should then be closed and a second set of new allocations opened.
Indexers could provide a yaml or json file that lists all Subgraphs for which they want to close allocations and all Subgraphs they want to form part of their new allocation distribution along with updated allocation amounts. The agent could then automatically process these when it is initiated with the relevant command. It should perform some sort of sanity-checking, for example ensuring that the total allocations to be closed plus any unused allocation exceeds or matches the new allocations requested.
The text was updated successfully, but these errors were encountered: