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 address of the resource or App, attributes such as username and password, and 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’s 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 CloudShell interface classes are provided in the cloudshell-shell-core package, which 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 that is deployed and lives inside the sandbox, whereas a physical resource, or as it’s sometimes called inventory_resource, is a type of resource that lives in the CloudShell inventory and is pulled into blueprints and sandboxes. Let’s 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, such as server address, ports, and so on. It also contains a token which can be used to log in to CloudShell API. As we’ll discuss later, 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 we’ll need about the App or resource to which the Shell driver is assigned. This is the key piece of information any driver will need in order to implement commands that work with the device/App. Let’s 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, and are required in order to communicate with it.
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’s attributes:
The reservation property contains information about the sandbox in which the command is running:
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: (1) the app_request_json property is a JSON string containing information about the app template which was requested in the blueprint, while (2) the deployed_app_json JSON contains information about the deployed application and where it’s running.
You can find JSON schema definitions of these two JSON objects here:
Custom sandbox metadata
Starting with CloudShell 9.2, it is possible to store and retrieve custom key-value data from the sandbox. For details, see Working with Custom Sandbox Metadata.
Custom Attributes and the Shell’s data model
In many cases, the Shell has specific information that is stored in attributes. For example, user credentials that are needed in order to connect to the resource. These attributes are part of the Shell’s data model. Their value can be easily retrieved by converting the ResourceCommandContext to an instance of the generated Shell’s data model.
In this example, you can see that the code imports the generated Shell’s data_model, and then uses the create_from_context function to convert the context parameter into an instance of DataModelExample, which is the Shell data model structure. Then, the code retrieves the attribute values by using properties such as resource.vendor and resource.model. The properties of the Shell’s model will match the data model definition in the shell-definition.yaml file.