HTTP connection warnings when using local_forest_runtime

[lacker]

Some simple code keeps printing warnings that appear to be unrelated to anything I'm doing:

WARNING - Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f4dea0aeb00>: Failed to establish a new connection: [Errno 111] Connection refused',)': /

This happens with some code that just solves some of the exercises in the docs:

def throw_octahedral_die():
    qvm = get_qc("3q-qvm")
    program = Program(H(0), H(1), H(2))
    ro = program.declare("ro", "BIT", 3)
    program += MEASURE(0, ro[0])
    program += MEASURE(1, ro[1])
    program += MEASURE(2, ro[2])
    result = qvm.run(program)
    a, b, c = result[0]
    return 1 + 4 * a + 2 * b + c


def main():
    print(throw_octahedral_die())


if __name__ == "__main__":
    with local_forest_runtime():
        main()

AFAICT these warnings are nonactionable and do not indicate any problem, so they should be suppressed.

[appleby]

I suspect this is because local_forest_runtime() doesn't wait for QVM to startup before returning, so the QVM probably isn't ready to accept connections yet.

You could try adding a time.sleep before the call to main() as a workaround.

Apparently this log message is coming from urllib3. You could also try something like the method suggested in this stackoverflow answer to disable the log message.

I'm ambivalent about disabling these urllib3 log messages globally in pyquil. On the one hand, they aren't really user-actionable as you note, but in general connection errors and retries should be rare, and these might be useful for diagnosing and debugging real issues, especially since raising the log level might silence other warnings as well.

Probably this should just be fixed in local_forest_runtime. There was some discussion in the PR that reworked this function about the possibility of adding some polling logic to ensure that the QVM is ready to accept connections before returning. In the end we decided it probably wasn't worth the additional complexity, but I don't think we realized these retry warnings would be logged in a user-visible way either. In light of this, we might decide to revisit the polling option.