tracking checks and criteria

[l-monninger]

Summary

The concept of tracking checks was proposed internally about a month before the time of writing.

The initial tracking premise contended with mirrored networks wherein--as the movement network continued to run--traffic was also forwarded to a migrated movement-aptos node. Then, properties of both networks w.r.t. to themselves and each other were checked for correctness. This tool war originally suggested primarily for ad hoc usage and team observability.

More recently a concrete possibility of running a structured tracking validation period has been raised.

Note

This more structured tracking validation period could potentially programmatically cut over traffic, if so desired.

This discussion is intended both to develop an understanding of the actual checks and to contend with complexities of tracking APIs--such as the notion of Environments which would capture network mirroring.

To begin, consider the following questions:

1. What do we want to track?
2. Where do we want to be able to run different tracking checks from?
3. Who will use these tracking checks?
4. What procedures might be triggered by a passing check? Failing?

[l-monninger]

@0xmovses @andygolay @sebtomba @franck44 @apenzk @sausagee

Let's discuss this. I'd like to have clear understanding by the following sprint.

Note

I am planning to have a lot of my work this upcoming sprint concern playing around with programmatically spinning up the network mirrors which correctly requires running a checked-migration upfront.

The understanding of Environments and plausibilities from the overall experience would be informed by this.