Currently it is not easy to interact with history archives hosted on Azure, GCP blob stores. Most users choose to sync from an existing history archive to their local file system and then use Cloud specific tools to push to blob stores but even this does not allow for stellar-archivist scan or stellar-archivist status.
What would you like to see?
Ideally stellar-archivist is able to read a put and get command from a configuration file which would enable users to configure stellar-archivist read/write using external tools or shell scripts.
This would be inline with how stellar-core manages history.
What alternatives are there?
Currently there are 2 alternatives, the first is to sync stellar-core from the genesis ledger on a full validator (>15 days) and the second is to use stellar-archivist to sync from http://history.stellar.org/ to a local file system and then push from local file system to cloud based blob stores manually using provider specific tooling.
Both of these solutions are cumbersome and neither allow monitoring of history archives via the status and scan sub commands.
What problem does your feature solve?
Currently it is not easy to interact with history archives hosted on Azure, GCP blob stores. Most users choose to sync from an existing history archive to their local file system and then use Cloud specific tools to push to blob stores but even this does not allow for
stellar-archivist scan
orstellar-archivist status
.What would you like to see?
Ideally stellar-archivist is able to read a
put
andget
command from a configuration file which would enable users to configure stellar-archivist read/write using external tools or shell scripts.This would be inline with how stellar-core manages history.
What alternatives are there?
Currently there are 2 alternatives, the first is to sync stellar-core from the genesis ledger on a full validator (>15 days) and the second is to use stellar-archivist to sync from http://history.stellar.org/ to a local file system and then push from local file system to cloud based blob stores manually using provider specific tooling.
Both of these solutions are cumbersome and neither allow monitoring of history archives via the
status
andscan
sub commands.