In this section we’ll provide a few handy examples of common driver operations.
The intention is to grow this into a good source to copy paste common code from. Most of the examples are available in the DevGuide Examples repository under the common_driver_recipes folder. The following topics are reviewed in this article:
The password for logging into the device/app will be passed as an encrypted value to the driver
as a part of the context object. In order to be able to use it to log in you’ll most likely
need to decrypt it. To do that, you can use the CloudShellAPI function DecryptPassword.
The resource live status can be used to indicate the current state of the resource on the diagram.
CloudShell comes with a pre-built collection of statuses you can use, and this collection of icons can also
be extended if needed.
The following code will update the resource live status from offline to online:
The full list of statuses can be found in the ServerUniversalSettings.xml file which you can find on the Quali Server
machine under the %programdata%\QualiSystems\Settings\Global directory:
Sending a message to the sandbox console
Another way to update the sandbox regarding an operation progress is to use the WriteMessageToReservationOutput
function to display a message in the Sandbox console pane.
We can easily modify the previous code to do that instead:
When adding a new command that requires communication with a networking device, such as a switch or router, you need to open a session to the device. An easy way to do that is by leveraging Quali’s shell framework (cloudshell-cli package). The framework can provide a session from a session pool via Telnet, SSH or TCP, based on the configuration saved in the CLI Connection Type attribute on the root resource.
Starting with CloudShell 8.3, developers can map connections between sub-resources residing on deployed Apps. This applies to scenarios where you want to map the port connections between virtual devices residing in App VMs. For example, to map the connection between port 1 residing on a virtual switch and port 2 residing on another virtual switch. For details, see Mapping Connections using App Sub-resources.
Defining a connected command (which runs on another resource)
In some scenarios, a command that runs on a specific resource logically requires the use of a different resource. These types of commands are called connected commands. They are executed on a resource in CloudShell Portal but in reality run on the connected resource (for example, a power switch) that performs the action.
There are two types of connected commands:
Power commands: Let’s say you have a target resource that is controlled by a power switch (PDU). When you run a Power On command on the target resource, the user may think the command is running on that resource but it actually runs on the PDU that is connected to the resource.
Generic resource commands: A remote command is similar to a power command but is not limited to power commands only. For example, you could have a command, which modifies a target resource’s settings, but is actually running on the server that performs the modifications.
To create a connected command, you need to use a shell based on a standard that supports connected commands, currently, only PDU for power commands and the Generic Resource with Connected Commands. These commands need to be defined in two places, in the drivermetadata.xml and in the driver.py file.
In the driver’s drivermetadata.xml, you define which commands are connected, as follows:
For power commands, the command must include the Tags="power" flag and the driver must include all three power commands (Power On, Power Off and Power Cycle):
For generic connected commands, you must use a shell that is based on a supporting standard and include the Tags="remote_connectivity" flag on the command:
And finally, in the driver.py file, define the connected commands. In this case, PowerOn, PowerOff and PowerCycle:
To enable intellisense, on the driver.py, include the ResourceRemoteCommandContext context in the command’s definition, as shown above.
Connected command definitions must include a ports parameter. You don’t need to actually use it in your command. Just make sure it’s included as it allows the connected command to run on multiple resources at the same time.
Power commands only apply to unshared resources while generic resource commands can run on both shared and unshared resources.
In CloudShell, the resource containing the connected command and the target resource must be directly connected to each other. If you have a switch resource in between, the connected command will not show on the target resource.
You can use the CloudShell Automation API’s ExecuteResourceConnectedCommand and “power management” commands to add connected commands to other shells.
Example - power commands on a PDU shell:
SetPortState should be a driver helper function that implements the specific logic of how to change the power port state for the specific PDU.