After updating to 26.29.0 I seem to have lost the proxy kernels to all services except for the device service. Is this intentional?
I am still able to communicate with the services via the API provided by the Client.
We like to use the proxy kernels in our workflow. Is there a way to get the proxy kernels back?
2 Likes
Hi Tim,
This is due to this change which came with version 26.24.0. The relevant change is the addition of the install_proxy boolean in a services’s entry in the orchestration.toml. This determines whether or not a proxy kernel appears in the jupyterlab interface.
To have your services appear as selectable in the jupyterlab interface, you need to set install_proxy=true, as is done in the snippet below
[services.system-monitor]
entrypoint = "orangeqs.juice.system_monitor._service:SystemMonitorService"
install_proxy = true
Hope that helps!
I am also quite intrigued by the services you have instantiated. Would you be willing to share more on what you use each service for?
Hi Wiggert, yes of course!
These services are to interact with quantum inspire (QI) as a hardware backend. We use the broker to manage access to the device service. When a user of QI submits a job to one of the backends that we host, the qi_receiver locks the broker such that the user can run their job without me interfering. The qi_publisher publishes the status of the backend (IDLE, EXECUTING, OFFLINE, CALIBRATING or BENCHMARKING) back to QI. The calibration_coordinator automatically runs graph-based recalibrations of the device such that the performance stays up to spec.
I’m sure this can be done a lot more efficiently in the current implementation of juice. All these services were needed considering the juice implementation before juice-core. Not enough time in a PhD week to do so, though 
Feel free to check out the Tuna-9 and Tuna-17 backends and the dashboards where we publish the current status and latest performance of the QI hardware backends.
1 Like
This worked, thank you very much!