You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Services need Quality of Service for relay information on a running blueprint back to it's User. There can be varying levels of information in these Quality of Services:
What is being built?
Quality of Service crate/library that is used for sending heartbeats and metrics on running Blueprints. Additionally, a UI for viewing the metrics and data on running Blueprints.
Motivation
Users need a way to receive information on running blueprint instances, verify uptime of the services they are paying for, and ensure operators who are not maintaining their instances are slashed for their unreliability.
Deliverable
The deliverable, in its simplest form, is a system that sends info/messages from a running blueprint to the user/chain. A heartbeat is the most basic level of information that would be sent, but it should allow any level of configuration for blueprints that need more data to be sent to the user.
Checklist
Blueprint
QOS crate/client that runs in the Blueprint Runner
Custom Heartbeat logic defined per-blueprint (defined when building the runner)
Interface for displaying metrics with Grafana and Loki, up-time, etc.
Tangle
Retrieves expected heartbeat interval from Blueprint
Gets a blueprint's missed Heartbeat threshold for slashing
Heartbeat processing/validation logic in Services pallet
Heartbeat information in storage
tnt-core
Heartbeat hook
Logic for handling metrics collected in heartbeat
Setting heartbeat interval
Setting slashing threshold for missed heartbeats
Examples
If a service entails running a website, it might be "up" but it might not be accessible due to a cloudflare issue or a DNS problem. A QoS update might include actual website connectivity latency from different regions.
If a service is running a data indexer, it might include metrics about how far behind the data indexer is from the chain tip, or the state of the database.
Overview
Services need Quality of Service for relay information on a running blueprint back to it's User. There can be varying levels of information in these Quality of Services:
What is being built?
Quality of Service crate/library that is used for sending heartbeats and metrics on running Blueprints. Additionally, a UI for viewing the metrics and data on running Blueprints.
Motivation
Users need a way to receive information on running blueprint instances, verify uptime of the services they are paying for, and ensure operators who are not maintaining their instances are slashed for their unreliability.
Deliverable
The deliverable, in its simplest form, is a system that sends info/messages from a running blueprint to the user/chain. A heartbeat is the most basic level of information that would be sent, but it should allow any level of configuration for blueprints that need more data to be sent to the user.
Checklist
Blueprint
Tangle
tnt-core
Examples
If a service entails running a website, it might be "up" but it might not be accessible due to a cloudflare issue or a DNS problem. A QoS update might include actual website connectivity latency from different regions.
If a service is running a data indexer, it might include metrics about how far behind the data indexer is from the chain tip, or the state of the database.
References
Coder: https://coder.com/docs/user-guides
The text was updated successfully, but these errors were encountered: