Implement Qibo Client

[scarrazza]

I have tried something very simple like:

from qibo import Circuit, gates
from qibo_tii_provider import QiboTiiProvider
p = QiboTiiProvider('my_key')
c = Circuit(1)
c.add(gates.H(0))
c.add(gates.M(0))
p.run_circuit(c, device='sim')

however I am getting this:

 {'error': "An error occurred: HTTPConnectionPool(host='localhost', port=8010): Max retries exceeded with url: /run_circuit/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f5a37056750>: Failed to establish a new connection: [Errno 111] Connection refused'))"}

[scarrazza]

Another quick comment, I think we should call TIIProvider instead of TIIQProvider because the package name is qibo-tii-provider.

[scarrazza]

Thanks @marcorossi5, I have quick tested this and it seems to work with some minor issues.

• could you please apply to all files the convention of calling this package "qibo-tii-provider" (no tiiq), rename the class TIIProvider (capital TII, no Q). Ideally we should also update the user in the cluster to tiiprovider instead of tiiq.

• there is a docker image in the cluster, I believe this can be removed for the time being.

• I have noted a substantial delay between the job execution and download, can we reduce this delay?

• When executing a second circuit I get this crash:

[marcorossi5]

I have noted a substantial delay between the job execution and download, can we reduce this delay? This is controlled by the intervals in seconds between daemon's checks and clients checks. This configuration can be changed of course.

When executing a second circuit I get this crash: It can be that the attributes do not get updated correctly when posting the second job. It can also be that the new directory download directory does not get created the second time. Let me check. In any case, we want the client to be able to post multiple circuits in sequence (synchronously with the server execution), right?

[scarrazza]

Thanks, yes, synchronously.

[marcorossi5]

The error was given if trying to access the results even if the job exited with error as was in your case.

I fixed it by passing the job exit status in the headers of the get_result request

[marcorossi5]

@scarrazza, could you please check again your tests? They should run as expected now.

[scarrazza]

Thanks @, I am flying back this night, tomorrow I will review all your changes.

[scarrazza]

Thanks @marcorossi5, indeed now it does not crash. I will open a PR later with some changes and requests to you.