action #36613
closedcoordination #14818: [EPIC] Interactive mode is an usability disaster
action #36442: Access to running SUTs for System Developers
Implement WS connection from web UI to command server
Description
- AC1: Limit the use of the connection to one developer
- Save the current developer and display it somewhere in the web UI
- AC2: Allow to pause the execution at a certain test using the ws connection
Updated by mkittler over 6 years ago
Ok, so let's say a user clicks on 'Start developer mode' in the live view to enable certain controls (eg. set the test to pause at, resume, ...). What should happen under the hood? Maybe the following:
web browser <=ws or AJAX=>
web UI <=ws=>
os-autoinst command server
- The JavaScript does an AJAX call or opens a ws connection to the web UI server.
- If the job isn't running, this results in an error. Otherwise:
- The web UI server creates a new entry in the table
DeveloperSessions
to keep track of what happens in the following steps.- The entry is identified by the job id and contains further meta-data like the user id and maybe further status information.
- If the entry already exists, a specific error is returned and handled by the JavaScript.
- I wouldn't add the additional information for the developer session directly to the jobs table because the columns wouldn't be used most of the time and the jobs table is quite big.
- The web UI server opens a websocket connection to the os-autoinst command server.
- The connection is kept open as long as the developer session is open.
- Likely the connection can just be initialized in the controller callback. Eg.
my $cmd_srv_connection = $self->app->ua->websocket(...);
Or do I have to take special care because the life-time of the ws connection will exceed the execution of the controller callback?
- The JavaScript client sends further commands, eg. to pause the test at some step.
- The web UI server validates and passes the command to the command server.
- At some point the test is actually paused which is noticed by the web UI server through a message from the command server.
- To promote that info to the web UI, it would be convenient to choose a ws connection in step 1. Making it a web socket connection, wouldn't be that much effort. It would be very similar to the command server (https://github.com/os-autoinst/os-autoinst/pull/966/commits/1343ac9f8bc7d4cd667bd6f9308e6f49e22ca3a2#diff-7665723fe5fbdde573deb0bcb70ba6de).
- The developer mode is canceled or the test finishes.
- The web UI server closes the web socket connection to os-autoinst and removes the entry in the
DeveloperSessions
table.
- The web UI server closes the web socket connection to os-autoinst and removes the entry in the
Updated by mkittler over 6 years ago
The web socket connections browser <=> web UI <=> os-autoinst
are basically working now.
WIP branch: https://github.com/Martchus/openQA/tree/enhance_live_ws_connection (most relevant file so far: https://github.com/Martchus/openQA/blob/enhance_live_ws_connection/lib/OpenQA/WebAPI/Controller/Developer.pm)
So next step is to add the table mentioned in the previous comment.
Updated by mkittler over 6 years ago
Current problems so far:
- Test with multiple chromedriver instances to test behavior when multiple tabs open. In the first place I thought this works, but unfortunately this is not reliable and I haven't been able to change SeleniumTest.pm that it works.
- Not sure how to write unit tests for the websocket routes. I'm still reading the documentation for this. But I already noticed that the way I'm using to send errors to the JavaScript client doesn't work well.
Updated by mkittler over 6 years ago
- Status changed from In Progress to Resolved
The mentioned problems should be solved and the PR is merged.
Updated by szarate over 6 years ago
- Target version changed from Current Sprint to Done