-
Notifications
You must be signed in to change notification settings - Fork 0
Deploying the Hub Router
The Hub Router is a spec-compliant WebDriver intermediate node which routes tests between multiple hubs.
The Hub Router should be hosted as a single server, either on-premises or on a cloud provider, by running the binary or the container image.
The binary can be built from the source in hub_router_warp/, or the container image can be found on the GitHub container registry
Here is the one-liner to get started with docker:
docker run -it ghcr.io/fire833/capstone/hub_router_warp:latestYou can run the same command with your runtime of choice and the effect should be the same.
The Hub Router needs no configuration when initially deployed. A web frontend and configuration API is deployed by default on port 8080, which has an interface for configuring a number of parameters for the Hub Router, including the healthcheck frequency, and ip/port pairs to bind the test router and the frontend server to.
Individual configuration values can be set by their corresponding API endpoint, or can be updated from the configuration modal on the frontend.
NOTE: When making updated to configuration values such as the API/Proxy bind ports/IPs, healthcheck_thread_interval, or reaper_thread_interval you will need to restart the process/container for the changes to take effect. This is because those values are read in at startup and the logic to update them dynamically within memory does not currently exist. Updates to Hubs will take effect immediately with no restart.
On first launch, the Hub Router will have no registered hubs, and will reject all tests. First, add a hub as specified in the configuration section, then tests can be directed to port 6543 on the Hub Router, which will be routed to all registered hubs. This port is configurable from the web frontend or the configuration API.