Refactor environment variables used by test cases

[rathishcholarajan]

What is the expected feature or enhancement?

We currently have the following environment variables after porting code from qiskit-ibm.
QISKIT_IBM_RUNTIME_API_URL
QISKIT_IBM_RUNTIME_API_TOKEN
QISKIT_IBM_RUNTIME_HGP
QISKIT_IBM_RUNTIME_PRIVATE_HGP
QISKIT_IBM_RUNTIME_DEVICE
QISKIT_IBM_RUNTIME_USE_STAGING_CREDENTIALS
QISKIT_IBM_RUNTIME_STAGING_API_TOKEN
QISKIT_IBM_RUNTIME_STAGING_API_URL
QISKIT_IBM_RUNTIME_STAGING_DEVICE
QISKIT_IBM_RUNTIME_STAGING_PRIVATE_HGP

Once we add support for IBM Cloud authentication we should have the below environment variables.

Cloud (Production)

QISKIT_IBM_CLOUD_API_LOCATOR
QISKIT_IBM_CLOUD_API_TOKEN
QISKIT_IBM_CLOUD_DEVICE

Cloud (Staging)

QISKIT_IBM_CLOUD_USE_STAGING_CREDENTIALS
QISKIT_IBM_CLOUD_STAGING_API_LOCATOR
QISKIT_IBM_CLOUD_STAGING_API_TOKEN
QISKIT_IBM_CLOUD_STAGING_DEVICE

Legacy (Production)

QISKIT_IBM_API_TOKEN
QISKIT_IBM_API_LOCATOR
QISKIT_IBM_HGP
QISKIT_IBM_PRIVATE_HGP
QISKIT_IBM_DEVICE

Legacy (Staging)

QISKIT_IBM_USE_STAGING_CREDENTIALS
QISKIT_IBM_STAGING_API_TOKEN
QISKIT_IBM_STAGING_API_LOCATOR
QISKIT_IBM_STAGING_HGP
QISKIT_IBM_STAGING_PRIVATE_HGP
QISKIT_IBM_STAGING_DEVICE

[jyu00]

Do we really need to add RUNTIME to it? Or can we just do QISKIT_IBM_API_TOKEN for all qiskit-ibm-nnn repos, and maybe QISKIT_IBM_CLOUD_TOKEN for cloud services?

[rathishcholarajan]

@jyu00 Yes, we can do that if we want to share env variables between packages.

[rathishcholarajan]

I've updated description as per the suggestion. Thanks @jyu00!

[daka1510]

We discussed this briefly in Slack before but I want to bring this up again in the right context. With the proposed approach the number of environment variables we need to support in our code scales with the number of supported test environments (currently: 2, planned: 4, future: ?). I am not sure if this is needed.

Alternative Proposal

To make sure we can handle additional test environments transparently, I propose to move to a single set of environment variables, i.e.

• not use QISKIT_IBM_CLOUD_API_..., QISKIT_IBM_CLOUD_STAGING_API_..., QISKIT_IBM_API_... , QISKIT_IBM_STAGING_API_...
• instead use QISKIT_IBM_API_... and set it to different values depending on the targeted environment

Example Usage

CI/CD

Local Development

VSCode also supports different run configurations and can be set up in a similar way.

[rathishcholarajan]

@daka1510 The environment variables are not just required for CI. There is another use case for internal users.
As an internal user who has access to both staging and production environments, I should be able to store my staging and production credentials as environment variables and then switch to using one vs the other using QISKIT_IBM_CLOUD_USE_STAGING_CREDENTIALS for cloud and QISKIT_IBM_USE_STAGING_CREDENTIALS for legacy. If we use the same env variables then I'd have to setup two different conda environments locally, one for staging and one for production, which is not the end of the world, but needs educating internal users. Also I don't know if everyone uses conda. Once we have the ability to save multiple credentials in qiskit-ibm.json (See #31), people can use that to store staging credentials as well. But again not sure if everyone would want to use this method to save the credentials vs just setting env variables.

Also I don't see us having more than these 4 envs in the near future.

@jyu00 Do you see anything for or for having a single set of env variables?

[daka1510]

As per discussions in Slack and during our daily, I plan to give it a try with a reduced set of environment variables:

# Legacy / Cloud
QISKIT_IBM_API_LOCATOR=<http://auth.quantum-computing.ibm.com/api> or <CRN>
QISKIT_IBM_API_TOKEN=<Legacy API Token> or <Cloud API Key>
QISKIT_IBM_DEVICE=...

# Legacy Only (differentiation between HGP and PRIVATE_HGP no longer needed)
QISKIT_IBM_HGP=...