Add MyMDC check_connection action

Description

MyMDC now features a check to ensure that the webservice is up and running, before sending a job request.
The motivation for this is to stop littering the job tables with timed-out requests in errors, and to provide nicer feedback to MyMDC users (rather than waiting, seeing the timeout, and exploring a bunch of logs to figure out what the issue might be).

How Has This Been Tested?

This was tested on maxwell17 with the test MyMDC installation, see the screenshots below.

Relevant Documents (optional)

In this screenshot, the webservice process was stopped.
You can see that the job request was not sent, because MyMDC could not establish that the webservice was running.

Here, however, the job request was sent (and running as can be seen at the bottom of the image), after checking that the webservice is up and running:

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I added tests where appropriate: as suggestions in !491

Reviewers

@calibration @maial

changed milestone to %3.4.0

added 1 commit

• 11de51cc - Add support for check_connection action

Compare with previous version

LGTM, spoke to Cyril about it earlier

mentioned in merge request !491

So I guess myMdC will make a request to this with a relatively small timeout? AFAIK, ZMQ has no specific way to indicate 'no-one there' (because it allows for the client starting before the server).

LGTM. Thank you, Cyril.

@kluyvert - Configured timeout when triggering Calibration from myMdC is currently 1 second.

Cheers,

I'm a bit confused how this helps, then - won't it be the same error whether you get a timeout checking the connection or trying to make the request?

I think having some kind of 'ping' message is a good idea anyway, just a bit puzzled how myMdC would actually use it.

merged

mentioned in commit 7acf1828

@kluyvert, I got your doubt... because we had to change this on Friday. :P

In short, Calibration Service expects to get the DarkRun id (to later send updates), therefore myMdC can only trigger Calibration Service request (python server) on an after_create callback (otherwise there wouldn't be any id to send). This method will be called to avoid that myMdC creates a DarkRun entry (and respective after_create callback) in case the service is down.

I hope this is a bit more clear. Cheers,

That makes sense, thanks Luis!

This should tell us that ZMQ is not really well suited for critical services with a certain sense of reliability

But nifty workaround.