Login using IBM Cloud API key

[rathishcholarajan]

What is the expected feature or enhancement?
A user should be able to login using their IBM Cloud API Key.

class IBMRuntimeService(RuntimeService):
    def __init__(self, auth=None, token=None, locator=None):
        """Initialize a new client to use the runtime service.
        
        Args:
            auth: Authentication type. `cloud` or `legacy`. If not specified, the saved default is used.
                If there is no default value, and both accounts were saved on disk, the cloud type is used.
            token: Token used for authentication. If not specified, the saved token is used.
            locator: The authentication url, if `auth=legacy`. Otherwise the CRN.
        """
        pass

When the user does

service = IBMRuntimeService(token="<apikey>", locator=<CRN>)

no API calls would be made but the passed in values should be stored in the RuntimeClient.
And then for subsequent calls made to the API like service.programs() or service.pprint_programs() the
Service-CRN: <paste-CRN-here> and Authorization: apikey <paste-apikey-here> headers should be sent with every request.

The URL for production vs staging should be automatically determined based on the cname in the CRN. staging for staging vs bluemix for prod.

Example curl to get programs:

curl --location --request GET 'https://us-east.quantum-computing.cloud.ibm.com/programs' --header 'Service-CRN: <paste-CRN-here>' --header 'Authorization: apikey <paste-API-key-here>'

[daka1510]

Took a look at the implementation details and see the risk to bloat or overload some of the function signatures if we stick with the plan to use the same class (IBMRuntimeService) to handle both cases in a fully transparent way.

Context

To my understanding there are different terms that end users are familiar with, i.e.

• familiar to users of http://cloud.ibm.com/ ("cloud")
  • API key
  • CRN
• familar to users of https://quantum-computing.ibm.com/ ("legacy")
  • API token
  • Authentication URL
  • Hub, Group, Project

Challenge / Risk

To map the above terms to the proposed common interface, additional overloaded terms like locator have to be introduced. This might come with an additional learning curve and/or confuse users.

cloud_service = IBMRuntimeService(auth="cloud", token=cloud_api_key, locator="crn:v1:bluemix:public:quantum-computing:us-east:...")
legacy_service = IBMRuntimeService(auth="legacy", token=legacy_api_token, locator="https://auth.quantum-computing.ibm.com") 

The same challenge will also become relevant when the save_account function is updated to serve both worlds.

# how to extend this
IBMRuntimeService.save_account(
    token: str, url: str,
    # how to design the interface to not mix and match parameters that are only relevant for legacy/cloud
    hub: Optional[str] = None,
    group: Optional[str] = None,
    project: Optional[str] = None,
)

Proposal

from abc import ABC
class IBMRuntimeService(ABC, RuntimeService):
    # implements common functionality across cloud / legacy but is not directly instantiated

class IBMCloudRuntimeService(IBMRuntimeService):
    # cloud users explicitly need to instantiate this class
    def __init__(self, api_key, crn):

class IBMLegacyRuntimeService(IBMRuntimeService):
   # legacy users explicitly need to instantiate this class
    def __init__(self, token, url):

[daka1510]

@rathishcholarajan, @jyu00 - added a few thoughts in my previous commment. Let me know what you think (or discuss on Monday). As always: I may be totally wrong with these concerns. If so, I'm happy to learn why.

[daka1510]

Discussed in during our daily sync meeting and agreed to move forward as initially planned for now (i.e. use a single IBMRuntimeService). This decision is heavily based on the assumption that the runtime APIs will be the same across Cloud/Legacy and not require users to supply different parameters (cc: @renier).