pipermerriam
commented
3 months ago Some additional thoughts.
- Census
- Probably useful to have both "homogeneous" and "heterogeneous" census results. Aka, census taken from the view of many clients and census taken from the view of a single client.
- Audits
- Default behavior should round-robin across different client types.
- Failures should potentially be re-attempted using a different client type than the original audit.
- Passive Monitoring (listening for inbound OFFER)
- Seems fine to do round-robin or be generally client agnostic here.
It has been mentioned/talked about several times that it would be beneficial to have multi-client support and it was again a topic (https://hackmd.io/mdclhYDYR6qZVqXXSyEJNA?view#2-What-do-we-want-in-Glados) on the Portal summit, so I'm creating an issue here to keep track of this.
Multi-client support here means that audits (and census / network explorer) should be able to be run on several nodes and different supported clients and be visible in the glados web UI.
For a client to be glados supported it should have:
portal_historyTraceRecursiveFindContentimplemented (see json-rpc spec)Having this deployed for multi-client on https://glados.ethdevops.io/ is useful for seeing difference in results between different clients or client versions. This allows for more quickly identifying whether issues are client related or network related. It also allows to see differences in behavior of clients in complex/large networks that are not easily discoverable in small scale tests (client CI, hive, etc.).
EF infrastructure also typically tries to include every supported client in such testing setups. And it would be good to have only one entry point to the results of all recognized (as supported) clients there.
If it is required that the multi-client glados deployment requires a separate issue and doesn't belong here, let me know where to create that.