Add block explorer to net up --kubernetes #4582
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
ndr-ds
force-pushed
the
09-16-add_block_explorer_to_net_up_--kubernetes
branch
from
db6ed13 to
dd746df
Compare
ndr-ds
force-pushed
the
09-16-add_support_to_multiple_proxies_on_net_up_--kubernetes
branch
from
4b8ce28 to
305a656
Compare
| tokio::spawn(listen_for_shutdown_signals(shutdown_notifier.clone())); | ||
|
|
||
| let num_block_exporters = if with_block_exporter { | ||
| num_block_exporters |
There was a problem hiding this comment.
We could assert here (or earlier) that num_block_exporters is non-zero.
| - "--port" | ||
| - "{{ .Values.indexer.port }}" | ||
| - "--database-path" | ||
| - "{{ .Values.indexer.databasePath }}" |
There was a problem hiding this comment.
for the future: Can we make it so that the SQLite file is replicated automatically?
There was a problem hiding this comment.
We could! Keep in mind that regular PVCs are zonal deployments, so only if the entire zone goes down for some reason we would lose the data. It's very unlikely. If we want extra protection, we could do regional PVCs, that replicate the data across different zones of the same region.
But yeah, I agree it's more of a follow up for the future
There was a problem hiding this comment.
To complete the question: we have sqlite db which is file-based. We should be set up some syncing/fallbacks in case the machine is wiped or lost.
There was a problem hiding this comment.
Like I said, it's currently in a PVC. PVCs are over the network disks. They already don't live in the actual indexer VM. So if the machine is moved or something (like in a maintenance event), we won't lose the data.
I think we should be ok here for now, losing this data should be a very low probability thing (our ScyllaDB for example uses the same over the network disks for testnet). Of course there's more we can do in the future to add more safeguards for it like I mentioned (replicated PVC, backups, etc)
There was a problem hiding this comment.
ok cool. Do we have metrics for latency there?
| kind = "Indexer" | ||
| tls = "ClearText" | ||
| port = {{ .Values.indexer.port }} | ||
| endpoint = "linera-indexer" |
There was a problem hiding this comment.
This works only in docker-compose. In real deployment this will have to be an address of an actual indexer endpoint.
There was a problem hiding this comment.
Actually on kubernetes this will be the actual internal hostname of the indexer endpoint :) so this works
ndr-ds
force-pushed
the
09-16-add_block_explorer_to_net_up_--kubernetes
branch
from
dd746df to
54b0aa9
Compare
ndr-ds
force-pushed
the
09-16-add_block_explorer_to_net_up_--kubernetes
branch
from
54b0aa9 to
6881c43
Compare
ndr-ds
force-pushed
the
09-16-add_block_explorer_to_net_up_--kubernetes
branch
from
6881c43 to
234fd10
Compare
## Motivation We're working on adding the Indexer/Explorer/Exporter into our deployments. ## Proposal This adds them to `linera net up --kubernetes` as a starting point. Next, adding to the actual GCP deployment. ## Test Plan Started a local k8s network, sent some transactions to it, and managed to see the information in the block explorer:   ## Release Plan - Nothing to do / These changes follow the usual release cycle.
## Motivation We're working on adding the Indexer/Explorer/Exporter into our deployments. ## Proposal This adds them to `linera net up --kubernetes` as a starting point. Next, adding to the actual GCP deployment. ## Test Plan Started a local k8s network, sent some transactions to it, and managed to see the information in the block explorer:   ## Release Plan - Nothing to do / These changes follow the usual release cycle.
Motivation
We're working on adding the Indexer/Explorer/Exporter into our deployments.
Proposal
This adds them to
linera net up --kubernetesas a starting point. Next, adding to the actual GCP deployment.Test Plan
Started a local k8s network, sent some transactions to it, and managed to see the information in the block explorer:
Release Plan