The sync service

[hacdias]

Hey y'all,

In the current state of Testground, the SDKs are connecting directly to Redis. We want to build an SDK for JavaScript that also works on the browser. However, we cannot connect to Redis directly from the browser as it does not provide a native HTTP interface. Thus, works on sdk-js are paused until this issue here is closed.

The goal is to create a sync service that can be used by Testground. The sync service provides an HTTP interface and it is a bridge to Redis - or virtually any other backend that we might want to use in the future. Due to the dimension of Testground, this needs to be well tested and we must make sure everything works flawlessly during the transition.

Required

• Implement the sync service (this repository)
• Review this repository code
  • @hacdias
  • @nonsense
• Setup auto builds for Docker: docker pull iptestground/sync-service
• Replace Redis by custom implementation:
  • PR: Replace Redis by custom implementation #7
  • Discussion Replace Redis by custom synchronization service testground#1229
• testground/sdk-go: feat: use new sync service sdk-go#37
• testground/testground: feat: http sync service testground#1187
• testground/infra: feat: add sync service infra#66

Work on after

• testground/sdk-js: feat: use new sync service sdk-js#17

A few months after release

• Remove backwards compatibility of Redis: Remove Redis backwards compatibility in 3 months #10

[hacdias]

I have been working on this feature since January and I feel like I have lost hold on it. Thus, I'm leaving a quick recap of everything that was developed and the current state.

Why is thing being built? When I started building the JavaScript, I quickly realized we couldn't use it in the browser mainly because we were connecting to Redis from the test instances directly. Redis does not provide a native HTTP interface and it is not recommended to use from a browser.

Thus, we decided to create a sync service: a service to which all test instances would connect and do the necessary sync requests: barrier, publish, subscription and entry signaling. I decided on using WebSockets because they are easy to use and allow for versatility as well as performance.

The sync service is implemented on this repository. The code must be reviewed by at least one other person. There are tests, but they are not extensive.

Both SDKs have ongoing implementations for connecting to the new sync service:

• The Go SDK is mostly finalized and only requires a bug fixing.
• The JS SDK I actually started a few days ago and is not working properly so needs to be investigated.

On the main side of Testground the PR is finalized and we just need to finish the other PRs in order to merge everything.

There will be the need to adapt the infra repository to the new sync service, which means that there will need to be a Pod running the image iptestground/sync-service, connected to a Redis instance, that will be accessible by the test cases.

/cc @jacobheun @nonsense

[raulk]

@hacdias thanks for the summary. Could you elaborate on the alternatives considered before deciding to go in the direction of introducing a new architectural layer? Concretely, did we evaluate https://webd.is? What made us build our own? Is there a technical design document or spec that I can read to understand the endeavour better? Thanks!

[hacdias]

Hey @raulk!

The initial idea was to test webd.is. However, we decided to build a new layer mostly because: (1) the official Redis advice is not to use it on the web, (2) in case we decide to replace Redis in the future - unlikely for now - we would need to rewrite all the SDKs; and (3) there was already an issue (or conversations) regarding separating the sync service into a different layer. However, I can't find the issue right now. /cc @nonsense

There is no technical design document, nor spec. If you want, we can have a call for me to explain better what happened so far and what is built.