Onboarding beta testers - #85
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #85 +/- ##
=======================================
Coverage 90.99% 90.99%
=======================================
Files 34 34
Lines 5683 5683
=======================================
Hits 5171 5171
Misses 512 512 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
randomir
left a comment
randomir
left a comment
There was a problem hiding this comment.
LGTM!
Minor note: onboarding content would probably make more sense in the Ocean SDK docs, under (perhaps) gate-model page. But I guess it's fine to temporarily host it here. 🤷
qci-amos
left a comment
qci-amos
left a comment
There was a problem hiding this comment.
i'm not really the right person to review all this, but the parts I am familiar with lgtm
| Features for real-time control, which are being phased into dual-rail | ||
| quantum computing systems, are already available on the simulator in the | ||
| |cloud|_ service for prototyping and learning. |
There was a problem hiding this comment.
I'm glad to see this mentioned somewhere
| You can see your ``dwave.conf`` file using the methods described in the | ||
| :ref:`cloud_configuration` or using the :ref:`D-Wave CLI <ocean_dwave_cli>` | ||
| section. |
There was a problem hiding this comment.
it would be nice if there was a cli way to do this
|
|
||
| >>> from dwave.gate.leap import LeapQCDLSimulator | ||
| ... | ||
| >>> simulator = LeapQCDLSimulator(profile="beta") # doctest: +SKIP |
There was a problem hiding this comment.
isn't there a way to configure a default in dwave.conf?
There was a problem hiding this comment.
dwave config create will update the default profile by default. That makes sense for new D-Wave users that are trying this out, but not for existing users. Now, I don't know who's going to be onboarding here.
There was a problem hiding this comment.
most of the examples that Trevor K and I are planning, he wouldn't specify profile= so ideally we could have a way to guide users to simply configure their dwave.conf appropriately instead of either encoding the profile in the examples or asking users to do that
There was a problem hiding this comment.
You can also specify the default profile in the DWAVE_PROFILE env var. That's the easiest way to "specialize" an environment. A shell, or a container.
$ DWAVE_PROFILE=beta python
>>> from dwave.gate.qcdl.leap import LeapQCDLSimulator
>>> simulator = LeapQCDLSimulator()
>>> simulator.properties
{'max_shots': 1000000, ...| [beta] | ||
| token = BETA-123456789123456789123456789 |
There was a problem hiding this comment.
my conf has leap_client_id and metadata_api_endpoint. Are these not needed for the beta testers?
There was a problem hiding this comment.
Not needed. The PROD values for these params are shipped with the client. You had to manually override/specify them if you ran in non-PROD envs.
There was a problem hiding this comment.
so "beta" is some sort of alias/subset of PROD?
There was a problem hiding this comment.
No, "beta" (token) here refers to a new project "D-Wave Gate Model Simulator Beta". It's a project in the PROD environment.
| The following are two simple ways to use the beta-tester project's API token | ||
| from your existing development environment. | ||
|
|
||
| * Add a section to your ``dwave.conf`` file. |
There was a problem hiding this comment.
is ti clear to users how/where to create this file? It hasn't been so for me and my team
There was a problem hiding this comment.
dwave config ls should list all available dwave.conf files, in order of preference.
There was a problem hiding this comment.
But you make a good point, @qci-amos, we should advise users explicitly to just run this:
dwave config create --profile beta
That command will locate the config file and/or create one if it doesn't exist; then it will create a new profile called beta (or update the existing one); and ask the user for the SAPI token.
There was a problem hiding this comment.
Perhaps we should provide a fully automated flow example.
- Authorize Ocean to access Leap:
$ dwave auth login
Please visit the following URL to authorize Ocean: https://cloud.dwavesys.com/leap/openid/authorize?...
Authorization completed successfully. You can now use "dwave auth get" to fetch your token.
- Configure your
betaprofile:
$ dwave config create --profile beta --auto-token --project "D-Wave Gate Model Simulator Beta"
Using the simplified configuration flow.
Try 'dwave config create --full' for more options.
Updating existing configuration file: /home/radomir/.config/dwave/dwave.conf
Creating new profile: beta
Fetched SAPI token for project 'D-Wave Gate Model Simulator Beta' (R4zH) from Leap API.
Configuration saved.
Or as a one-liner:
dwave auth login && dwave config create --profile beta --auto-token --project "D-Wave Gate Model Simulator Beta"
Note I used the full project name for clarity, but it can be shortened to R4zH:
dwave auth login && dwave config create --profile beta --auto-token --project R4zH
3 participants
@randomir, see if there's more needed or worth changing.