Getting Information from CloudShell
A typical Shell driver, will first get crucial information from the sandbox and then use that information to access the device it controls. Some common information would be the resource or app’s address, attributes such as username and password, as well as other information from other sandbox settings or components.
To provide easy access to such common information, each driver function has access to a special context object parameter, which is created by CloudShell for each driver command execution. If you’ve generated the default driver template, you may have noticed that the pre-generated functions already have some docstring code-hint annotation. This allows some IDEs like Pycharm to provide autocomplete for the class properties and make it a lot easier to user.
CloudShell Shell Core
The classes used for the command context parameters, as well as other interface classes CloudShell provides are provided in the cloudshell-shell-core package which you also may have noticed is imported in the sample driver class. The term Resource may be a confusing one for the context object. In the CloudShell platform there are really two types of resources, a deployed app is a resource which is deployed and lives inside the sandbox, whereas a physical resource or as its sometimes called inventory_resource is a type of resource that lives in the CloudShell inventory and is pulled into blueprints and sandboxes. Lets take a look at the ResourceCommandContext class to understand more about the information it provides:
The ResourceContextDetails object
The connectivity property contains information about how to connect to CloudShell, information like server address, ports and so on. It also contains a token which can be used to log in to the CloudShell API. As we’ll discuss, it is generally recommended to use the CloudShell API as little as possible in your Shell, with the exception of a few operations which we’ll cover later in the examples section of this guide. So while the connectivity information is readily available on the context, in most cases you should not have to use it.
The resource property contains most of the information you’ll need about the app or resource to which your Shell driver is assigned. This is the key pieces of information any driver will need to implement commands that work with the device/app. Lets examine the ResourceContextDetails class properties:
There is a lot of useful information in this object. Of special importance is The name of the resource, the address and the model. These provide the most basic details about the resource or app required to communicate with it. Other attributes, such as the user and password credentials, additional interfaces and other settings will be found in attributes property. The attributes property is a dictionary with the keys being the attribute names and the value being the current value.
The connectors property provides information about the resource or app’s connectors (visual or network connectors) in the sandbox. The property maps to a list of Connector objects, each provides information about the source and target resource. As well as the connector attributes:
The reservation property contains information about the sandbox reservation the command is running under. class ReservationContextDetails:
Additional information for apps and VMs
The resource property of the context object also contains the app_context property which is relevant to deployed app and virtual
machine drivers only. The app_context object has two separate JSON string properties nested under it: The app_request_json
property is a JSON string containing information about the app template which was requested in the blueprint. The deployed_app_json
JSON, to the contrary, contains information about the deployed application and where its running.
You can find a JSON schema definitions of the two JSON objects here:
More information and examples about the information in this JSON and how to use it will be provided in the deployed apps driver section of this guide.