Can you please rebase against current master, or a similar measure (it might be easier to just cherry-pick the new commits onto a new clean branch)? The PR is currently showing a lot of changed files.

This is great! I love moving from callback based async approach to a future based async approach!!

If we have a backend method for job should it return instance or string? Alternatively it could be returned in the status method dictionary.

I think instance, since these are qiskit components talking to each other.

@atilag The use case for a job id is if the user wants to retrieve a job in the future and this would be a backend unique identifier for that job. Also this will go into the results data structure and so be a way for users to link results back to a specific execution.

@atilag The use case for a job id is if the user wants to retrieve a job in the future and this would be a backend unique identifier for that job. Also this will go into the results data structure and so be a way for users to link results back to a specific execution. (reply to this one)

Is is too much of a constraint from a general backend to provide a unique id? It doesn't seem like it would be.

@ajavadia If we have a jobs method for basebackend then should it return job instances instead of strings?

@ewinston i think so. this is similar to provider.available_backends() which returns Backend instances

*(btw i think that method should be provider.backends()... available_backends might imply the backend is not offline, which it might be)

@ajavadia @ewinston If .backends returns backend/job instances does that imply all backends/jobs are instantiated when qiskit is started? In particular for the .jobs for a remote object that could be a lot of overhead.

I think there should be some string type id to uniquely label all backends and jobs separate from the apparatus of objects (?), but in particular for jobs.

@dcmckayibm I think returning objects avoids the overhead of translating between string names and instances by the user. Objects are easier to work with. You get it and call .status() or whatever on it.

1- For backends, it is safe to assume there aren't hundreds of them. So if you look at the current implementation, the list of backend instances is created at the time of provider authentication, and maintained thereafter (the API call to _discover_remote_backends is made during provider __init__).

2- You might be right that for jobs, we may not want to carry this list of job instances through. In that case:
a) I think the API call to get jobs should be made inside .jobs() itself, and not during the backend __init__, contrary to 1.
b) We can return a generator, which is evaluated lazily. But I would do this only if returning jobs turns out to be prohibitive (avoid premature optimization!). See #371 for an example of when this is really useful.

@ajavadia I guess I'm more thinking from a data structures perspective. Consider I have a qobj or result structure (and have lost the objects,e.g., these are from disk) and in those I only have string identifiers to the backend and/or job how do I "grab" those objects again?

Maybe the thing I'm advocating isn't' necessarily that .jobs .backends return strings or objects, but that that at least there is still a .get_backend(id) .get_job(id)

@dcmckay

The use case for a job id is if the user wants to retrieve a job in the future

Sure, but for me the job_id is an implementation detail that we could totally abstract from the user, so he doesn't need no know anything about IDs. We abstract it through the Job class interface. A user would only use one interface, the one from the Job class, to play with all the possible backends without knowing anything about their internals, and we can provide them with methods to serialize/deserialize the entire Job instance.
For example:

job = ibmqx4.run(qobj)
if not job.done(): # <-- this will internally use the ID to check the status of the Job
    # Is not ready yet! So I could for example, serialize and persist it on disk
    user_function_save_to_disk(qiskit.utils.serialize(job), '/path/to/result-serialized.json')
else:
    # Is ready! Let's print the results
    print(job.result.get_counts('Bell'))

So let's say that the job was not ready and we have serialized it to disk, we can load it from disk again and rebuild an instance of our Job instance, by deserializing:

job = qiskit.utils.deserialize(user_function_load_from_disk('/path/to/result-serialized.json'))
if job.done():
    print(job.result.get_counts('Bell'))

The benefits of this approach are:

• Users don't have to worry about backend implementation details: No matter how the backend manage jobs internally, they can use IDs, URLs, or whatever other method they may use to query jobs. The Job implementation will take care of it.
• Homogeneous interface for local and remote jobs: As local jobs don't have an ID.

Is is too much of a constraint from a general backend to provide a unique id? It doesn't seem like it would be.

I'd say that you are right, and sounds legit to me, but I wouldn't like to make assumptions without having any other experience on backend implementation aside from our own backends.

As time is a constraint, and we don't have a serializer/deserializer in place, my suggestion would be to move the id() method to our Job implementation, instead of having it on the BaseJob one.

@ewinston Thanks Erick, I think this is very close to being done. I only have a couple more comments:

1. When I run a job on local simulator, the job.status always seems to be 'QUEUED', even when the result is ready. Can you check if this is really the case, and if it can be fixed?
2. As part of BaseJob, can we have self._backend and a method to get the backend it is running on as well? It should be straight forward to populate this field at the time of backend.run(), and I think it is useful to know the backend that the job is running on.
3. I have a comment above about some remaining timeout fields in the QuantumJob, that should be cleaned up.

Awesome. It looks ready to merge to me!

@ewinston: just a minor thing: when i submit a job to ibmqx4, and monitor job.status.. it goes from QUEUED to None before returning result. Is this an API issue? It might be in the QISKit code, because I think this morning I was seeing RUNNING before completion.

Also my queue position seems to be constant. I don't know if you see a similar thing.

@ajavadia The temporary status of None you saw could have been related to a case I didn't think was possible and didn't catch.

When I monitored the queue position of a job it seemed to be not changing but was actually changing really slowly.

Also, I'm working on another branch of this one which allows submitting ibmq jobs faster. It's on my fork on "ibmq_future" branch. What caveat of it is that an ibmq job can briefly not have a job id.

@ewinston I think maybe None is supposed to be RUNNING actually? Because I just see QUEUED, None and COMPLETED. Here is one output I just got... I query the status every 3 seconds:

Status @ 0 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'queue_position': 3, 'status': <JobStatus.QUEUED: 'job is queued'>, 'status_msg': None}
Status @ 3 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'queue_position': 3, 'status': <JobStatus.QUEUED: 'job is queued'>, 'status_msg': None}
Status @ 6 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'queue_position': 3, 'status': <JobStatus.QUEUED: 'job is queued'>, 'status_msg': None}
Status @ 9 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'queue_position': 3, 'status': <JobStatus.QUEUED: 'job is queued'>, 'status_msg': None}
Status @ 12 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'queue_position': 3, 'status': <JobStatus.QUEUED: 'job is queued'>, 'status_msg': None}
Status @ 15 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'status': None, 'status_msg': None}
Status @ 18 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'status': None, 'status_msg': None}
Status @ 21 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'status': None, 'status_msg': None}
Status @ 24 seconds
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'status': None, 'status_msg': None}
{'job_id': 'c58ca262b54d480b128435d0c315a34f', 'status': 'COMPLETED', 'result': [{'data': {'time': 19.651577949523926, 'counts': {'00': 479, '01': 53, '10': 59, '11': 433}, 'date': '2018-05-09T00:37:44.323Z'}, 'status': 'DONE'}], 'name': 'nwHnKuOEo7pen52Xfo1u7lUp4xtx9C', 'backend': 'ibmqx4'}

Thanks for the much needed tests, @ewinston ! For the rest of the team: please note that the tests are not run on travis and they need to be launched manually - and are currently failing, unfortunately. The good news is that at least one of the remaining issues that is causing seems to be easy to fix with the proposed fix by @ajavadia - and the other failing test seems also tiny.

Thanks @ewinston , and basically all team that was involved in this PR - merging! 🎉