Rethink oasis-node access

[Yawning]

The current intended way of accessing oasis-node 100% does not support archive nodes, for the same reason why oasisprotocol/oasis-web3-gateway#286 exists.

Before this hits production this should be rethought and re-evaluated as this likely impacts storage strategy (while oasis-node is the best at storing oasis-node's data, when you can't connect to multiple versions of oasis-node simultaniously reliably, other options need to be considered).

[aefhm]

I think the current strategy (which will be further outlined) is to run multiple instances of the Indexer, per each upgrade.

[gw0]

I thought that only analyzers would access oasis-nodes, process what is needed and write the results into a database? The front-end of the Indexer would then just read from this database?

Architecturally analyzers should be more or less stand-alone components where each one supports its own oasis-node version and is backed by an archive oasis-node with that version. To improve the robustness of the system and solve the Go package importing issue this means each analyzer should be compiled separately and a coordinator service should spawn analyzers that are needed.

The configuration of analyzers in the config file supports this (name = analyzer compiled for specific oasis-node version, rpc = connect to which archive node, from/to = block height boundaries):

• https://github.com/oasisprotocol/oasis-indexer/blob/main/config/local-dev.yml

[aefhm]

I thought that only analyzers would access oasis-nodes, process what is needed and write the results into a database? The front-end of the Indexer would then just read from this database?

Ah, to be more specific, I should say multiple analyzers 🤔.

[mitjat]

The current thinking is still that the current approach will work out OK. Each analyzer (probably instantiated in a separate k8s deployment, though not technically necessary) will connect to a separate node (oasis-3, oasis-4, etc) and write to a separate set of tables (namescoped by chain id) in the DB. How both sets of tables are merged is up for debate; my early bet is on a one-time migration of the oasis-3 content to the oasis-4 schema during the node upgrade window. But that's a larger question and is to be fully addressed in scope of #161 .