Tips and Tricks
Managing the CloudShell session
Creating an instance of CloudShellAPISession can be expensive. Each time such an object is created a new login request is made, which can impact the performance of the driver/script. In theory it would be better to create the session once per command and then pass it in a convenient way to any internal function called in the execution flow.
For Shell drivers, the cloudshell-shell-core contains a convenient object to manage this scope. We pass this helper the context parameter of the driver command:
Any logging package can be used with CloudShell. Quali has a customized logging solution which is thread and process safe, and that organizes logs to different files according to resource and sandboxes. The Quali logging module is defined in the cloudshell_core package.
The simplest way to get a hold of a logger object is to use the get_qs_logger module:
For the default logger, the log_category parameter defines the folder under which logs will be grouped whereas the log_group defines the file. The CloudShell convention is to create a folder for each reservation id and a file for each resource name. For orchestration scripts, the file name is the environment name.
All logs will be saved on the Execution Server where the driver is running. The folder location will be relative to the driver in the virtual environment location at: %venv%\[drivername]\Lib\site-packages\cloudshell\Logs. (e.g. C:\ProgramData\QualiSystems\venv\Deployment_Orchestrator_5_2\Lib\site-packages\cloudshell\Logs.)
Under windows, [venv] will be located at %programdata%\qualisystems\venv.
You can then use the regular logging level syntax to write messages as a part of the driver package or script flow:
Only messages which are greater than the log level currently set for the driver will be saved to file. Typically, changing the log level to a more verbose value would be done only in order to debug an issue, as writing too much to the logs can be expensive. You can change the logging level on the ES or driver level.
To change the log level on the driver level, edit the following configuration file: [venv]\[drivername]\Lib\site-packages\cloudshell\core\logger\qs_config.init and change the log level value. Notice that this change will only be valid for that virtual environment, so if the driver is recycled due to inactivity the log level will revert to the default value.
To change the log level for the entire ES, without editing any files, add the following key to the ES customer.config (change ‘DEBUG’ to the log level you wish to set):
You will need to restart the ES following this change.
Similar to the CloudShell API session, its recommended to create a logger once per command and then pass it to any internal classes that require it. As with the CloudShell API we’ve added some helpers in the cloudshell-shell-core package which can reduce some of the repetition around creating a logger and create a more explicit scope for it:
Another repetitive task is to remember to log any exception raised during the driver execution. Here too, cloudshell-shell-core provides a handy scope:
Using this scope any exception raised within the ErrorHandlingContext will be logged, even if no code remembered to explicitly call the logger.
In addition, you can use this attribute to pass environment variables to shell drivers/scripts running on a specific Execution Server.
Finally, nesting the three helpers mentioned in this article makes a lot of sense as they’re not mutually exclusive. This syntax will also work well:
If the heavily nested code seems problematic its always possible to create a module that accepts the function to run as an input and applies these scopes behind the scenes.